Bug 1809353: Exclude Kubernetes control plane rules when running on IBM Cloud #705
Conversation
openshift-ci-robot
added
the
size/L
|
Alternate implementation to #687 |
|
/retest |
|
/test e2e-aws-operator |
|
/assign brancz ptal, this is the short-term solution that was ratified by @derekwaynecarr. |
openshift-ci-robot
added
the
do-not-merge/hold
|
/assign @brancz |
| schedulerRulesFound := false | ||
| for _, g := range r.Spec.Groups { | ||
| switch g.Name { | ||
| case "kubernetes-system-apiserver": |
There was a problem hiding this comment.
what about etcd? and what about the servicemonitors that are provisioned to monitor these in the first place, they will now show "down" targets?
There was a problem hiding this comment.
Service monitors that are part of control plane operators are skipped via annotation: https://github.com/openshift/cluster-kube-apiserver-operator/blob/4de583dffa47c25adde871e7361386b0d55c674a/manifests/0000_90_kube-apiserver-operator_03_servicemonitor.yaml#L7
Etcd rules are disabled because the etcd-metric-client secret is not placed in the openshift-config namespace:
cluster-monitoring-operator/pkg/operator/operator.go
Lines 418 to 421 in 207ec4e
| @@ -219,6 +220,10 @@ var ( | |||
| PrometheusTrustedCABundlePath = PrometheusTrustedCABundleDir + "ca-bundle.crt" | |||
| ) | |||
|
|
|||
| var ( | |||
| IBMCloudPlatformType configv1.PlatformType = "IBMCloud" | |||
There was a problem hiding this comment.
Don't redefine constant as vars, that's horribly dangerous.
csrwng
force-pushed
the
exclude_cp_rules_roks
branch
from
52285ea
to
f967450
Compare
openshift-ci-robot
added
the
needs-rebase
csrwng
force-pushed
the
exclude_cp_rules_roks
branch
from
f967450
to
7ef23af
Compare
openshift-ci-robot
removed
the
needs-rebase
|
/retest |
1 similar comment
|
/retest |
|
There is mostly a long term maintenance question here. The team is already way beyond full capacity, and this adds yet another dimension of bugs that are inevitably going to occur. Who takes care of that? |
|
Can we have a ROKS component in bugzilla for example that these types of bugs would be assigned to? |
|
also cc'ing @bparees to consult if existing components/repositories like cluster-monitoring-operator can be assigned to this type of initiatives like ROKS and not our team. I didn't find a ROKS component in bugzilla. |
i don't know that we need a ROKS BZ component, but it sounds like we need a ROKS-enablement cross-team intiative with an identified owner and tracking jira stories. imho this is similar to any other cloud provider enablement, though i realize there's significantly more structual differences in ROKS vs just another cloud provider. I don't view this change as a bug fix. |
|
@bparees see epic and jira tracking: https://issues.redhat.com/browse/CO-716 an agreed upon solution is required this week and needs backport to 4.3.z per our discussion last week. we are happy to improve testing in any form for any managed service as a follow-on to ensure regressions do not occur. this could include managed service specific testing scenarios in existing openshift e2e. |
|
Turns out there is a jira epic for this: https://issues.redhat.com/browse/CO-716 and i think this work is specifically tied to https://issues.redhat.com/browse/CO-756 but i'd reiterate that this is basically another platform so having its own BZ component doesn't make sense. |
Where do you think it should go then? Not under monitoring :) Note that we are not against this feature or merging this PR. We only want to ensure that we do not support this feature as we go onwards, or the backports and there is a component we can reassign any bugzillas we might potentially get. |
|
The problem from our side is long term maintainability. If, at any point in time, a BZ is opened that something doesn't work in a ROKS environment, we are effectively flying blind to fix it. Having a ROKS component owner/team would solve that specific concern. Someone who can verify and fix bugs in that environment. |
|
@lilic @s-urbaniak let's take this discussion offline |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: csrwng, s-urbaniak 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 |
openshift-ci-robot
added
the
approved
|
/retitle Bug 1809353: Exclude Kubernetes control plane rules when running on IBM Cloud |
openshift-ci-robot
changed the title
|
@csrwng: This pull request references Bugzilla bug 1809353, 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. 3 validation(s) were run on this bug
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. |
openshift-ci-robot
added
the
bugzilla/valid-bug
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
3 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
If the current cluster's platform is
IBMCloud, Kubernetes control plane rules are skipped.