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
Bug 1779933: set version to start for s390/ppc until we have actual samples #205
Bug 1779933: set version to start for s390/ppc until we have actual samples #205
Conversation
@gabemontero: This pull request references Bugzilla bug 1779933, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. In 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. |
@gabemontero: This pull request references Bugzilla bug 1779933, which is valid. The bug has been moved to the POST state. In 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. |
pkg/stub/handler.go
Outdated
@@ -588,6 +588,10 @@ func (h *Handler) Handle(event util.Event) error { | |||
// Every time we see a change to the Config object, update the ClusterOperator status | |||
// based on the current conditions of the Config. | |||
cfg = h.refetchCfgMinimizeConflicts(cfg) | |||
//TODO remove this setting of version once we start getting samples for z or ppc | |||
if len(cfg.Spec.Architectures) > 0 && cfg.Spec.Architectures[0] != v1.AMDArchitecture && cfg.Spec.Architectures[0] != v1.X86Architecture { |
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.
i'm a little confused as to why this is specifically checking array index 0?
- do we support multiple architectures being specified?
- if we do, what happens if x86 is listed first and Z is listed second?
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.
i'm a little confused as to why this is specifically checking array index 0?
1. do we support multiple architectures being specified?
at the moment, no ... we just have a place holder given this is an array to support it in the future
2. if we do, what happens if x86 is listed first and Z is listed second?
we hard code the entry at start up, and the first time through should set all the clusteroperator related bits
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.
adding validation type logic that handles a cluster admin replacing our boostrapping with incorrect choices is doable, but more complicated
where we compare what they set in the array with what the golang arch env vars reports, etc.
/cherrypick release-4.3 |
@gabemontero: once the present PR merges, I will cherry-pick it on top of release-4.3 in a new PR and assign it to you. In 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. |
1 similar comment
@gabemontero: once the present PR merges, I will cherry-pick it on top of release-4.3 in a new PR and assign it to you. In 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. |
/cherrypick release-4.2 |
@gabemontero: once the present PR merges, I will cherry-pick it on top of release-4.2 in a new PR and assign it to you. In 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. |
1 similar comment
@gabemontero: once the present PR merges, I will cherry-pick it on top of release-4.2 in a new PR and assign it to you. In 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. |
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.
Since we need to backport this change and don't have e2e CI for Z/power, is there an easy way for us to add unit tests to verify we're setting version correctly?
@@ -588,6 +588,10 @@ func (h *Handler) Handle(event util.Event) error { | |||
// Every time we see a change to the Config object, update the ClusterOperator status | |||
// based on the current conditions of the Config. | |||
cfg = h.refetchCfgMinimizeConflicts(cfg) | |||
//TODO remove this setting of version once we start getting samples for z or ppc | |||
if len(cfg.Spec.Architectures) > 0 && cfg.Spec.Architectures[0] != v1.AMDArchitecture && cfg.Spec.Architectures[0] != v1.X86Architecture { | |||
cfg.Status.Version = h.version |
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.
Shouldn't we always set this, and vary whether or not it is reported based on the Available
status?
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.
no we shouldn't ... all that was sorted out in 4.0/4.1 initial dev
only report the version once you have achieved it
7d93162
to
55bf486
Compare
Yes I believe so ... will start on that |
55bf486
to
6e00545
Compare
unit test added @adambkaplan |
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.
@gabemontero need to check that version is set if we're reporting Available=true; Progressing=false, Degraded=false
} | ||
|
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 doesn't look like validate
verifies that we've set version correctly. Needs to be updated.
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 setting of the version happens after the setup()
call ... it does not need to be in validate
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 don't need it everwhere
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.
nevermind ... I'll do it everywhere
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.
unit test updated
we don't test that in the unit tests ... we already do in the e2e's too big of a change to do in the unit tests |
6e00545
to
4a582ed
Compare
/test unit |
@@ -98,6 +107,7 @@ func TestWithArchDist(t *testing.T) { | |||
conditions, | |||
statuses, t) | |||
|
|||
|
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.
nit: why do we keep adding empty lines?
/test e2e-aws |
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
We have existing coverage to verify version is set via the current e2e suite. However we do not have CI infrastructure for non-X86 architectures at present.
Multi-arch team will be manually verifying our patch to 4.2.z (which cannot be cherry-picked).
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adambkaplan, gabemontero 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 |
@gabemontero: All pull requests linked via external trackers have merged. Bugzilla bug 1779933 has been moved to the MODIFIED state. In 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. |
1 similar comment
@gabemontero: All pull requests linked via external trackers have merged. Bugzilla bug 1779933 has been moved to the MODIFIED state. In 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. |
@gabemontero: failed to push cherry-picked changes in GitHub: pushing failed, output: "To https://github.com/openshift-cherrypick-robot/cluster-samples-operator\n ! [remote rejected] cherry-pick-205-to-release-4.3 -> cherry-pick-205-to-release-4.3 (cannot lock ref 'refs/heads/cherry-pick-205-to-release-4.3': reference already exists)\nerror: failed to push some refs to 'https://openshift-cherrypick-robot:CENSORED@github.com/openshift-cherrypick-robot/cluster-samples-operator'\n", error: exit status 1 In 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. |
@gabemontero: new pull request created: #208 In 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. |
@gabemontero: #205 failed to apply on top of branch "release-4.2":
In 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. |
1 similar comment
@gabemontero: #205 failed to apply on top of branch "release-4.2":
In 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. |
/assign @bparees
/assign @adambkaplan