proposal(operator-config): initial proposal for persisting configuration #941
Conversation
openshift-ci-robot
added
approved
| - If the global proxy object is not set / api doesn't exist, do nothing different. | ||
| - If the global proxy object is set and none of `HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY` are set on the `Subscription` | ||
| - Then set those env vars on the deployment and ensure the deployment on the cluster matches. | ||
| - If the global proxy object is set and at least one of `HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY` are set on the `Subscription` |
There was a problem hiding this comment.
Is there a use case where the user wants to use the global proxy but wants to override NO_PROXY?
There was a problem hiding this comment.
There is, but my understanding from @shawn-hurley was that we won't support that. Correct me if I'm wrong.
There was a problem hiding this comment.
I think it probably will make everyone's lives easier if we don't try to collide the override and global configs.
I think it will be easier to reason through for a user and for the proxy code. WDYT? I am not tied to it
There was a problem hiding this comment.
I think it's fine to be conservative at first and change it if we need to later.
There was a problem hiding this comment.
yeah the path we took w/ the build component (which supports this same proxy information, specified at various levels of precedence) is "all or nothing." We take all the values from the highest level of precedence that the user configured.
so in @tkashem's scenario, if the user wants to override NO_PROXY, they'd have to also copy the global proxy values into the operator specific http/https proxy env vars.
|
|
||
| When reconciling an operator's `Deployment`: | ||
|
|
||
| - If the global proxy object is not set / api doesn't exist, do nothing different. |
There was a problem hiding this comment.
Question: If the global proxy object is not set - technically there can be N (N>1) CR instance(s) of Proxy type in the cluster. Will the global proxy object have a predefined name or will there be only one instance of Proxy? @ecordell @shawn-hurley
There was a problem hiding this comment.
There will be many proxy objects, but the one named cluster should be considered the global proxy config.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ecordell, tkashem The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test unit |
|
/retest |
|
|
||
| - `HTTP_PROXY` | ||
| - `HTTPS_PROXY` | ||
| - `NO_PROXY` |
There was a problem hiding this comment.
@knrc somewhat relevant to your socks proxy question for istio.....there's still no socks proxy field being added to the global proxy config today that i know of, but if one is added, this is how i'd expect the value to get passed down to your OLM operator.
|
Have you considered support for generic configuration options to configure the behavior of the operator, e.g. cli args and values? Or is that what the configMap option is for? I'm thinking this could be applicable to other types of controllers that could be installed through OLM (i.e. instead of having an operator manage those controllers, promote them and save the resources). |
of operators