-
Notifications
You must be signed in to change notification settings - Fork 26
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
>We can assume that catalogs being added here were built in a pipeline that ran opm validate <directory> --flags as the final step. #146
Comments
The crux of the question here is - we're unpacking an index and get a filesystem out of it. We'd like to serve the content from that FBC filesystem as-is. Any work we can do at index creation time to make this easier is well worth it. If we need to support an |
That's a possibility to explore, but also a breaking change in the FBC spec. FBC in catalog images is currently allowed to ship with The most obvious first step, IMO, is to export this function in operator registry and use it here: https://github.com/operator-framework/operator-registry/blob/56771f76adbefa30190c4199d1cc970299f3ef04/alpha/declcfg/load.go#L88 |
Is it possible for a user to rely on that side-effect of the implementation of today's FBC images? Who consumes other than OLM servers? What's the implication of "breaking" that? |
I'm not exactly sure what you're asking, but I think the answer is yes no matter what.
I'm absolutely not opposed to saying something like "Catalogd expects FBC filesystems to have been pre-stripped of ignored files" if we think that's the right choice to make. I think we should teach |
You wrote:
I am asking - it's "breaking" in the sense that it changed, but would it be possible for a user to notice and care? In what situations would it be possible for a user to have been depending on the fact that, today, the ignored files are in the image, such that the user is "broken" with this change? Or are you just noting that it is a change, but not one that would block us from being able to do it? |
I'm hesitant to add pushing to As I mentioned on the call, I'd prefer a flag for
And then obviously we continue to require that catalog images pass |
Revise: and then we can document that |
I think the validation route is bound to be problematic if we start adding flags to it willy-nilly (not saying that's what you're suggesting, just calling out that we need to be cognizant of the kind of validations that we might want to relax or make more strict in the future) One person's relax is another person's ... non-relaxed treasure? Basically, there are multiple, disparate, and orthogonal ways to relax validation (or make it more strict). |
The If we want a "minimal FBC" image that contains only FBC files, that is just a different thing than standard FBC, according to the FBC spec, which allows .indexignore files. I would envision an image label being added to the image that says, "hey, i promise its just FBC here. concatenate away". And then clients can look at image labels (or mediatype, or artifact type, etc.) to understand how to consume the image. |
I feel this is not a safe assumption to make. IIUC
opm validate ...
does not mean non-FBC content does not exist in the structure, but rather it follows the FBC directory structure and any non-FBC content files are properly listed in the.indexignore
file. I agree thedeclcfg.DeclarativeConfig
object makes this a bit more simplistic, but I would again vote for this being done in a follow up. I want to try and avoid us expanding the scope of this PR so we can make progress on this implementation. We should create follow up issues for optimizations like this.Originally posted by @everettraven in #144 (comment)
The text was updated successfully, but these errors were encountered: