blueprint planner: skip non-provisionable sleds #5003
Conversation
I think I missed this on #4959, but instead of tacking onto that I'm opening this as a separate PR to confirm the guard is in the right place. If a sled has been marked as non-provisionable by an operator, I'm pretty confident we should NOT choose that sled when we're picking sleds for additional service zones (e.g., Nexus). I'm less confident on what we should do about NTP and Crucible zones. The change in this PR will still attempt to add an NTP zone, but will not attempt to add any Crucible zones. Is that the right place for it? Or should we still add Crucible zones to a non-provisionable sled (if it has zpools that don't yet have Crucible zones)?
|
I think it makes sense to add zones that necessarily must exist on every sled. NTP makes sense -- do Crucible zones have that property? |
|
That Mac failure -- oh god xmlsec is such a pain. |
I mentioned this on the update call but for the record: my inclination is to continue provisioning the NTP and Crucible zones. My assumption here is that the Crucible zones should not be used for new allocations anyway because of the provision state. That needs to be true for us to handle sleds that already have Crucible zones on them being marked non-provisionable. The reason I suggest this is so that sleds converge to the same state regardless of whether (1) they're blank and non-provisionable or (2) they're fully in-service and then get marked non-provisionable. This way, in both cases, they'll wind up having NTP, time sync'd, and Crucible zones. I don't feel strongly about this -- one could also argue that if it's non-provisionable, we really shouldn't do anything with it. But it is still in the control plane in a lot of useful senses and it seems like it should have a correct clock. Also, it seems for now like an unlikely case to ever hit, to have a sled marked non-provisionable and not already have these zones, since I assume we'd add these zones as soon as a sled is added and before an operator has a chance to mark it non-provisionable. So I don't think the choice is probably that important, right? |
👍, thanks for summarizing the offline discussion. I moved the guard to after we've provisioned NTP and Crucible in bf5f64d. |
I think I missed this on #4959, but instead of tacking onto that I'm opening this as a separate PR to confirm the guard is in the right place.
If a sled has been marked as non-provisionable by an operator, I'm pretty confident we should NOT choose that sled when we're picking sleds for additional service zones (e.g., Nexus). I'm less confident on what we should do about NTP and Crucible zones. The change in this PR will still attempt to add an NTP zone, but will not attempt to add any Crucible zones. Is that the right place for it? Or should we still add Crucible zones to a non-provisionable sled (if it has zpools that don't yet have Crucible zones)?