Operator View: Updates - what's the impact of the update?

[smklein]

Provide a mechanism for Nexus to identify the scope of an update.

Updates may be disruptive, requiring instance to migrate, and changing workloads. Ideally, we'd be able to communicate this in a reasonable way to users (either as an ETA, part of asynchronously communicating the update plan, or something similar).

[david-crespo]

It's possible that in the short term, we will do this client-side by simply comparing the component versions in the update to the current component versions in the system as shown here in the design:

If we do it that way, there is no further API work required.

[smklein]

One minor caveat, this doesn't actually show the "impact on availability" - I think that's a piece of information that would need to come from the update planner.

The view you mention definitely shows impact on versions, but not necessarily on "does this increase my risk of an outage, or push me against capacity limits".

[benjaminleonard]

In terms of impact on availability we had proposed the following design:

I had imagined that the metadata of each update could take an array of something like:

type ImpactItem = {
  target: 'instances' | 'capacity' | 'rack' | etc
  description: string // markdown formatted
}

The description could be a little more constrained that references from a list of predefined impact descriptions.

That said, if the impact of updating a component is more or less the same every time, then we could hardcode the impact descriptions and include them based on the list of components being updated?