-
Notifications
You must be signed in to change notification settings - Fork 37
Proposal to add run bundle subcommand. #19
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
Conversation
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.
Had a couple questions for the most part. Mostly this looks like it's in decent shape!
|
||
1. if image doesn't have bash, we can't modify the entrypoint | ||
1. if opm is building index images without bash, then there will be no index | ||
images we support |
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.
If we want to support redhat supported indexes, we should also check to see what their base image is. I know they are definitely doing some replacement there. @gallettilance
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.
Looking really good. A few comments.
* If `--index-image` is provided, use the provided value | ||
* `[--namespace=]` is an optional flag that specifies the namespace to install | ||
the operator. It will default to the `KUBECONFIG` context. | ||
* `[--install-mode=]` is an optional flag that specifies the |
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.
The installModes
are already defined by the bundle. I'm assuming this flag is for determining what OperatorGroup to generate - in that case, all we need is a --target-namespaces=[]
arg taking the set of namespaces to watch (which matches the terminology in the OperatorGroup)
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.
We want someone to select the install mode to test not interface with the operator group I think was the thinking
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.
My point is that flag may be confusing. The flag is called installMode
and the values are installMode
values, but it does not set the installMode
on the CSV (it can't, because that is already set in the bundle, and this command doesn't build the bundle).
What does this flag actually do?
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.
A user can set --install-mode=InstallModeType[=nsY]
. If a bundle's CSV supports that mode in installModes
by comparing type strings, run bundle
will either create an OperatorGroup in some namespace targeting nsY
, or use an existing and compatible OperatorGroup.
I see where this can create confusion: a supported mode in installModes
is only a statement about runtime availability, whereas --install-mode
mixes in OperatorGroup semantics.
I don't think it makes sense to pollute the CLI with two flags, one for installMode
and another for namespaces to target/watch. We definitely need the latter, and we want the former so users see a mapping between the way they're testing operator deployment and what their CSV/bundle encodes, even though we could infer mode from passed namespaces.
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.
The UX for this needs to focus on users who will eventually use our pipelines. We need to match all the choices for the index they are making.
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.
/lgtm
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.
LGTM
No description provided.