Skip to content

Start implementing upgrade status API #8320

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

andrewjstone
Copy link
Contributor

@andrewjstone andrewjstone commented Jun 11, 2025

Implements #8265

Still needs:

  • OMDB support
  • Testing

Support for artifacts other than zones will probably come in a follow up.

Still needs:

 -[] OMDB support
 -[] Testing

Support for artifacts other than zones will probably come in a follow up.
@andrewjstone andrewjstone marked this pull request as ready for review June 12, 2025 04:27
@andrewjstone andrewjstone changed the title WIP: Start implementing upgrade status API Start implementing upgrade status API Jun 12, 2025
Copy link
Contributor

@plotnick plotnick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this, both the code and the output look great!

I do have one (perhaps slightly annoying) suggestion: I think we should use the term "update" everywhere instead of "upgrade". We've been somewhat inconsistent on this point in the past, but we seem to be standardizing on the former (e.g., oxide update, API endpoints under /system/update). And especially for dev/user-facing commands I think it's important to use consistent terminology so that commands and endpoints are guessable.

@andrewjstone
Copy link
Contributor Author

Thanks for doing this, both the code and the output look great!

I do have one (perhaps slightly annoying) suggestion: I think we should use the term "update" everywhere instead of "upgrade". We've been somewhat inconsistent on this point in the past, but we seem to be standardizing on the former (e.g., oxide update, API endpoints under /system/update). And especially for dev/user-facing commands I think it's important to use consistent terminology so that commands and endpoints are guessable.

Not annoying at all! I anticipated some changes around the wording / endpoint location. @davepacheco @jgallagher Does this work for you? Any other changes you'd like to see in terms of naming?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants