POC: Exclude featuregate.release.openshift/tech-preview=true manifests #546
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sttts The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
sttts
force-pushed
the
sttts-exclude-tech-preview
branch
from
42548de to
ac7b520
Compare
| } | ||
|
|
||
| func LoadUpdate(dir, releaseImage, excludeIdentifier, profile string) (*Update, error) { | ||
| func LoadUpdate(dir, releaseImage, excludeIdentifier string, includeTechPreview func() (bool, error), profile string) (*Update, error) { |
There was a problem hiding this comment.
I don't think this approach is going to work. Today we only call InitializeFromPayload when we launch the CVO, and the other LoadUpdate caller is when we have detected the admin requesting an update. So if someone sets the tech-preview feature gate after that load, the CVO will not notice or react to that change until the next load (after a pod reschedule or requested update). And we'd have to track the feature-gate-status as part of ClusterVersion's status.desired and/or status.history so the new CVO pod would be able to distinguish between "I'm continuing the work of my predecessor and can launch in reconciliation mode" and "tech-preview has changed since the last reconciled payload, so I should launch in update mode". That's... possible. But it seems like a lot of juggling vs. just deploying the tech-preview operator all the time, and having that tech-preview operator decide if it should enable its operands or not. For precedent, consider the registry operator, which the CVO always installs, but which can be configured to not deploy its registry operand.
|
@sttts: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
@sttts: PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci
bot
added
the
needs-rebase
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
cert-manager ended up being OLM-installed, and openshift/enhancements#922 is being considered with more generic knobs for opting in to or out of specific core-release-payload components. So closing this narrower annotation as obsolete. /close |
|
@wking: Closed this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
4 participants
No description provided.