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
slim down catalogs transferred to diconnected clusters #85
slim down catalogs transferred to diconnected clusters #85
Conversation
Feel free to add other reviewers, not sure who else needs to look at this. |
- *Catalog*: one or more indices serving content. | ||
|
||
Catalog invariants: | ||
- Bundles, channels, and packages have unique names within their parent type (bundle->channel->package->catalog). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another invariant which is that the csv name has to be unique in the entire catalog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(but we should definitely not use csv name as an identifier, as we want to create bundle formats that do not have csvs at all)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the ultimate invariant that a bundle will have a unique name within a catalog, or package name + bundle name will be unique?
/approve |
Going to whip up an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This EP would benefit from some tangible examples with sample catalog content, e.g.
- some fictional package, channel and bundle names
- their update graph between those bundles
- changes that are introduced over time in the upstream / online catalog as a result of operators getting published
- the output of the diff operation at the beginning of time and after some time when new operators have been published
- what actually gets mirrored
- how the initial catalog is registered in the disconnected environment
- how the updated catalog is transferred and registered/merged in the disconnected environment
- `output` and some catalog data (potentially an entire CatalogSource) | ||
can be placed in some directory being watched by a daemon | ||
that will perform any necessary catalog add/merge behavior, | ||
then create/update a CatalogSource in-cluster. | ||
- This may have security implications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be really nice to have this command create and push a merged catalog into a static location from which existing CatalogSource
objects get their image.
@dmesser will add a more robust example soon. Otherwise, comments addressed. |
- If `a` does not exist, `a'` is added to `B` because `A` does not have the newest bundle state `a'`. | ||
- If `a'` does not exist, `a` is not added to `B` because `A` has the newest bundle state `a`. | ||
|
||
The `headsOnly` mode is a special case of the above algorithm, because |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To supplement the user context here: the special case here is when a user mirrors for the first time: they just want the channel heads, not the entire history of all Operators ever released, since they are starting on a green field.
Then, for subsequently triggered mirroring runs they would use latest
to only download the difference between the initial mirroring run and whatever has been published in the meantime. Here we want to download the Operator history all the way back to the cannel heads of A
, because we need that for update graphs to be complete.
… diconnected clusters Signed-off-by: Eric Stroczynski <ericstroczynski@gmail.com>
Signed-off-by: Eric Stroczynski ericstroczynski@gmail.com