Add MCONamespace constant

[mkenigs]

@cgwalters factoring this out per jkyros#1 (comment)

Is it worth replacing everywhere this is used with the constant?

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mkenigs
To complete the pull request process, please assign sinnykumari after the PR has been reviewed.
You can assign the PR to them by writing /assign @sinnykumari in a comment when ready.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@mkenigs: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-disruptive	ec7697b	link	false	/test e2e-aws-disruptive
ci/prow/e2e-gcp-op-single-node	ec7697b	link	false	/test e2e-gcp-op-single-node
ci/prow/okd-e2e-aws	ec7697b	link	false	/test okd-e2e-aws
ci/prow/e2e-aws-single-node	ec7697b	link	false	/test e2e-aws-single-node
ci/prow/e2e-aws-upgrade-single-node	ec7697b	link	false	/test e2e-aws-upgrade-single-node

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

[cgwalters]

Is it worth replacing everywhere this is used with the constant?

I don't have a strong opinion on this. There's a middle ground: not necessarily everywhere, but at least the places we plan to change soon.

Though mechanically speaking what I'd do here is two things:

• Start out PRs like this as draft, because we don't need to run all the CI for them to start until it's agreed to merge
• I tend to generate "prep" PRs which can contain multiple smaller cleanups, but still factored out into separate commits. An example is Preparatory patches for bumping fcct -> butane #2980 - so on this topic I'd assume there's other preparatory cleanups we could factor out that could be rolled in here too.

[mkenigs]

• I tend to generate "prep" PRs which can contain multiple smaller cleanups, but still factored out into separate commits. An example is Preparatory patches for bumping fcct -> butane #2980 - so on this topic I'd assume there's other preparatory cleanups we could factor out that could be rolled in here too.

Would that include something like this commit jkyros@930b9c6? Or should that one only be against layering?

[cgwalters]

Would that include something like this commit jkyros@930b9c6? Or should that one only be against layering?

That one seems reasonable to merge into main/master to me! But my PoV here is we should operate on "rough consensus and working code". If e.g. you and at least one other person think it's good for main/master, it probably is!

That said...I think it's worth looking at this from the other angle - what should only go on the layering branch? After considering this for approximately 37.2 seconds, one strawman proposal I have here is that (if it helps us, and I think it will) on the layering branch we disable all upgrade testing and assume we're doing a new install from a new bootimage that has the new rpm-ostree (which reminds me, we need to do an installer bootimage bump, I am not aware of anythig blocking that, will get someone to look).

[mkenigs]

Closing since this is too small of a PR and will roll this change into #2987