Namespaces for On-Prem Networking Services

When support for on-premise deployments on baremetal, OpenStack, OVirt, and
VSphere was added, some additional networking services were needed to provide
functionality that would come from cloud services on other platforms. These
services were added in namespaces called openshift-kni-infra,
openshift-openstack-infra, etc. There are two problems with this: 1) The
namespaces are created in all deployments, including ones on platforms other
than the one that uses the namespace and 2) The openshift-x-infra name scheme
does not match the existing pattern for OpenShift namespaces.

This enhancement proposes a solution to both of those problems.

enhancements/machine-config/onprem-namespaces.md

@@ -0,0 +1,178 @@
+---
+title: namespaces-for-on-prem-networking-services
+authors:
+  - "@cybertron"
+reviewers:
+  - "@smarterclayton"
+  - "@celebdor"
+  - "@mandre"
+  - "@rgolangh"
+  - "@patrickdillon"
+  - "@kikisdeliveryservice"
+approvers:
+  - Someone from MCO
+  - Someone from architecture
+creation-date: 2020-07-24
+last-updated: 2020-07-24
+status: implementable
+see-also:
+replaces:
+superseded-by:
+---
+
+# Namespaces for On-Prem Networking Services
+
+## Release Signoff Checklist
+
+- [ ] Enhancement is `implementable`
+- [ ] Design details are appropriately documented from clear requirements
+- [ ] Test plan is defined
+- [ ] Graduation criteria for dev preview, tech preview, GA
+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)
+
+## Summary
+
+When support for on-premise deployments on baremetal, OpenStack, OVirt, and
+VSphere was added, some additional networking services were needed to provide
+functionality that would come from cloud services on other platforms. These
+services were added in namespaces called openshift-kni-infra,
+openshift-openstack-infra, etc. There are two problems with this: 1) The
+namespaces are created in all deployments, including ones on platforms other
+than the one that uses the namespace and 2) The openshift-x-infra name scheme
+does not match the existing pattern for OpenShift namespaces.
+
+## Motivation
+
+The existence of namespaces not related to a given deployment is confusing to
+users. Additionally, the inconsistent naming of the namespaces is a further
+possible point of confusion.
+
+### Goals
+
+- Only create namespaces for networking services on deployments that need them.
+- Use names that are consistent with the rest of OpenShift.
+
+### Non-Goals
+
+## Proposal
+
+Instead of creating the namespaces at install time as is currently done, add
+them to the list of resources to be synced in the operator. This will allow us
+to add logic that considers the platform before creating them.
+
+For the naming, we propose `openshift-onprem` for all platforms that use these
+components. There is no need for a platform-specific name since only one
+platform can exist at a time anyway.
+
+### User Stories [optional]
+
+### Implementation Details/Notes/Constraints [optional]
+
+The services in question provide things like internal DNS resolution between
+nodes and loadbalancing for API and ingress traffic. In cloud platforms these
+would normally be provided by a service in the cloud, but for baremetal and
+our other on-premise platforms there are no such services available.
+
+### Risks and Mitigations
+
+The only significant risk should be the migration from the existing names
+to the new ones. We are already creating namespaces for these services.
+This proposal only changes how we do that and what those namespaces are
+called.
+
+## Design Details
+
+### Open Questions [optional]
+
+Is `openshift-onprem` an acceptable name? There has also been discussion of
+calling it `openshift-machine-config-something` since it will be deployed by
+the MCO, but since these components are not part of MCO that feels like an
+odd fit.
+
+### Test Plan
+
+**Note:** *Section not required until targeted at a release.*
+
+Consider the following in developing a test plan for this enhancement:
+- Will there be e2e and integration tests, in addition to unit tests?
+- How will it be tested in isolation vs with other components?
+
+No need to outline all of the test cases, just the general strategy. Anything
+that would count as tricky in the implementation and anything particularly
+challenging to test should be called out.
+
+All code is expected to have adequate tests (eventually with coverage
+expectations).
+
+### Graduation Criteria
+
+**Note:** *Section not required until targeted at a release.*
+
+Define graduation milestones.
+
+These may be defined in terms of API maturity, or as something else. Initial proposal
+should keep this high-level with a focus on what signals will be looked at to
+determine graduation.
+
+Consider the following in developing the graduation criteria for this
+enhancement:
+- Maturity levels - `Dev Preview`, `Tech Preview`, `GA`
+- Deprecation
+
+Clearly define what graduation means.
+
+#### Examples
+
+These are generalized examples to consider, in addition to the aforementioned
+[maturity levels][maturity-levels].
+
+##### Dev Preview -> Tech Preview
+
+- Ability to utilize the enhancement end to end
+- End user documentation, relative API stability
+- Sufficient test coverage
+- Gather feedback from users rather than just developers
+
+##### Tech Preview -> GA 
+
+- More testing (upgrade, downgrade, scale)
+- Sufficient time for feedback
+- Available by default
+
+**For non-optional features moving to GA, the graduation criteria must include
+end to end tests.**
+
+##### Removing a deprecated feature
+
+- Announce deprecation and support policy of the existing feature
+- Deprecate the feature
+
+### Upgrade / Downgrade Strategy
+
+On upgrade, we will want to clean up the old namespace after moving the static
+pods to the new one.
+
+Downgrade may be tricky. The old version of MCO won't have logic to re-create
+the old namespace, so I'm unsure how that will work.
+
+### Version Skew Strategy
+
+Version skew should not be a major concern. The pods may be running in
+different namespaces for a period of time, but that shouldn't affect their
+functionality.
+
+## Implementation History
+
+Major milestones in the life cycle of a proposal should be tracked in `Implementation
+History`.
+
+## Drawbacks
+
+The idea is to find the best form of an argument why this enhancement should _not_ be implemented.
+
+## Alternatives
+
+Similar to the `Drawbacks` section the `Alternatives` section is used to
+highlight and record other possible approaches to delivering the value proposed
+by an enhancement.
+