Feature Overview (aka. Goal Summary)

The SNO use cases where node IP changes impact API and etcd because of the hardcoded etcd configuration of the client IP information. The same configmap is used by the API server to contact etcd. By moving into using hostname, even when the node IP is updated, the SNO can resume operations. 

Goals (aka. expected user outcomes)

Recovery of SNO control plane components etcd & API, when the IP of the node changes.

Requirements (aka. Acceptance Criteria):

Recovery of SNO control plane components etcd & API, when the IP of the node changes. 

Use Cases (Optional):

SNO deployments on edge location may have dynamic IP assignment and the core control plane elements (etcd and API) need to continue working if the IP address changes after a reboot.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.

Out of Scope

Multi-node clusters are out of scope for this feature.

Background

Provide any additional context is needed to frame the feature. Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature. Initial completion during Refinement status.

Documentation Considerations

This is an internal platform capability, not a user-facing feature.

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.