Skip to content
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

Drop code that expects the config map in openshift-config namespace to have policy-configmap name #268

Conversation

ingvagabund
Copy link
Member

@ingvagabund ingvagabund commented Jul 31, 2020

Copy pasting openshift-config/CMName to openshift-kube-scheduler/policy-configmap is already carried out in the config observer code. Also, resource sync controller only copy pastes the user specified config when it's policy-configmap named (SyncConfigMap has the first argument as a destination. the second one as a source).

To avoid tests passing due to the same name for the config map.
User may use a different name. Though, since the namespaces are different,
use different name to properly test the config map from openshift-config
namespace was properly copy-pasted.
@ingvagabund
Copy link
Member Author

@damemi FYI

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 31, 2020
Comment on lines -35 to -36
resourcesynccontroller.ResourceLocation{Namespace: operatorclient.TargetNamespace, Name: scheduler.Spec.Policy.Name},
resourcesynccontroller.ResourceLocation{Namespace: operatorclient.GlobalUserSpecifiedConfigNamespace, Name: "policy-configmap"}); err != nil {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree these lines are wrong (namespace/name are switched) but do we want to remove them?

Target config controller does basically the same copy, but only when the scheduler CR is updated. Do we have a test for when the user creates a custom policy configmap (in openshift-config), adds it to the scheduler CR, then later updates that custom policy configmap directly?

I am wondering if, without this, changes will only be synced between openshift-config and the target namespace when the scheduler CR is updated (so really only by changing the custom policy configmap name)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Target config controller does basically the same copy, but only when the scheduler CR is updated.

Are you sure about this? I tested it locally and the configmap got synced after I edited openshift-config one even without the lines.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually wasn't sure, sorry, meant to pose that as more "did we check this?" based on talking about it offline the other day. If it works then cool! But do we have a test for that case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

@damemi damemi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve
/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 31, 2020
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: damemi, ingvagabund

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit f6ee0ad into openshift:master Jul 31, 2020
@ingvagabund ingvagabund deleted the do-not-use-expected-policy-cm-name-in-tests branch November 27, 2023 21:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants