You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're close to the point where we can start testing blueprint-driven upgrades, but there are way too many blueprints involved to do it manually. Here's a proposed MVP for automating this:
Create a new Nexus background task that runs, say, once/minute, does a planning run (same as what omdb nexus blueprints regenerate does today), and if the blueprint is different from the current target, saves it and attempts to make it the current target.
This background task would be disabled by default. (Presumably it'll run but do nothing.) It would be enabled by changing the Nexus config file.
This task should probably be activated automatically by a new inventory collection and any other operations that we know change the planning input (e.g., sled expungement, sled add, etc.).
Add a safety to prevent a runaway planner from generating infinite blueprints. e.g., maybe it should check and make sure there aren't more than, like, 200 blueprints before proceeding? Similar to what the inventory collector does. This relates to automatically archive old blueprints and inventory collections #7278 but it'd be nice to have a backstop even before we implement that.
It'd be very valuable to have this sooner rather than later so I don't think we should put those follow-on bits into the first PR.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
We're close to the point where we can start testing blueprint-driven upgrades, but there are way too many blueprints involved to do it manually. Here's a proposed MVP for automating this:
omdb nexus blueprints regenerate
does today), and if the blueprint is different from the current target, saves it and attempts to make it the current target.Follow on work would be:
It'd be very valuable to have this sooner rather than later so I don't think we should put those follow-on bits into the first PR.
The text was updated successfully, but these errors were encountered: