Open cbgbt opened 3 months ago
One edge case to consider in the design and implementation of this is how to handle the seed
and ignore-waves
settings.
For the sake of API consistency, an apiclient update
interface should possibly have a host be unaware of an update image unless it has reached the appropriate wave. On the flip side, it would be a poor UX to have to enable ignore-waves
to perform a metadata query. Maybe an --ignore-waves
option to the command would be appropriate.
Alternatively, should apiclient update release-data
always ignores waves, since it's a simple informational lookup?
I've been investigating the implementation of this feature. Just recording what I've been thinking:
I think the interface should be something like:
apiclient update describe --version 1.20.1 [--ignore-waves]
There are some implementation challenges that need to be considered. Currently the callpath of apiclient update
is something like this:
apiclient -> apiserver -> thar-be-updates -> (fork) updog
This allows the single-threaded apiserver
to remain unblocked while updog
attempts to fetch and process the repository metadata.
The processed information is serialized to disk in the UPDATE_STATUS
file. Subsequent calls to the apiserver
use that file when handling GET
requests.
Some problems:
UPDATE_STATUS
file does not contain the repository metadata needed to handle a describe
call -- it is laser-focused on providing actionable status information that can be used to drive Bottlerocket's update state machine correctly via the API.updog
is currently responsible for handling "wave visibility" processing; however, we need this command to possibly subvert the system-defined wave visibility processing. Our work here may need to move this processing into a shared library to ensure the abstraction is upheld consistently.Possible path forward:
updog whats
command that involves a repository refresh could also emit the un-processed update metadata to an additional cache file.thar-be-update
/apiserver
level.
What I'd like: I'd like to programmatically be able to associate an updated Bottlerocket image with the datestamp when it was published.
One possible approach to this would be to query the wave schedule information for an update from the TUF repository. Maybe this could be exposed via
apiclient
, e.g.:Any alternatives you've considered: