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
As of #5244, RSS generates a blueprint describing the service plan it produced and hands that off to Nexus, seeding the Reconfigurator with an accurate plan that doesn't require a support operator to generate one from an inventory collection. However, RSS's implementation of this is a little weird: we keep all the existing service-plan-creation logic, and then after it runs, we derive a blueprint from the plan. Once the Reconfigurator supports all control plane services, we could instead use it to generate the RSS plan.
Once Reconfigurator is automated, we could also consider having RSS set up a significantly reduced set of services (basically: the minimum set required to get Nexus+Reconfigurator up and running), and allowing Reconfigurator to flesh out the remaining services after rack initialization.
This is strongly related to #732, although many of the implementation details have been fleshed out since that issue was created, so possibly supersedes it.
The text was updated successfully, but these errors were encountered:
As of #5244, RSS generates a blueprint describing the service plan it produced and hands that off to Nexus, seeding the Reconfigurator with an accurate plan that doesn't require a support operator to generate one from an inventory collection. However, RSS's implementation of this is a little weird: we keep all the existing service-plan-creation logic, and then after it runs, we derive a blueprint from the plan. Once the Reconfigurator supports all control plane services, we could instead use it to generate the RSS plan.
Once Reconfigurator is automated, we could also consider having RSS set up a significantly reduced set of services (basically: the minimum set required to get Nexus+Reconfigurator up and running), and allowing Reconfigurator to flesh out the remaining services after rack initialization.
This is strongly related to #732, although many of the implementation details have been fleshed out since that issue was created, so possibly supersedes it.
The text was updated successfully, but these errors were encountered: