-
Notifications
You must be signed in to change notification settings - Fork 585
Add external topology mode #940
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -82,6 +82,8 @@ type InfrastructureStatus struct { | |
| // The default is 'HighlyAvailable', which represents the behavior operators have in a "normal" cluster. | ||
| // The 'SingleReplica' mode will be used in single-node deployments | ||
| // and the operators should not configure the operand for highly-available operation | ||
| // The 'External' mode indicates that the control plane is hosted externally to the cluster and that | ||
| // its components are not visible within the cluster. | ||
| // +kubebuilder:default=HighlyAvailable | ||
| ControlPlaneTopology TopologyMode `json:"controlPlaneTopology"` | ||
|
|
||
|
|
@@ -96,7 +98,7 @@ type InfrastructureStatus struct { | |
| } | ||
|
|
||
| // TopologyMode defines the topology mode of the control/infra nodes. | ||
| // +kubebuilder:validation:Enum=HighlyAvailable;SingleReplica | ||
| // +kubebuilder:validation:Enum=HighlyAvailable;SingleReplica;External | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we move this declaration up to the fields above, we can provide different enum values and prevent the infra topology from being set to external. We would want a comment here to explain why we're doing it that way, too.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dhellmann I like this suggestion. We can then make sure we don't set an invalid value for infra topology. Will submit a follow up PR |
||
| type TopologyMode string | ||
|
|
||
| const ( | ||
|
|
@@ -105,6 +107,12 @@ const ( | |
|
|
||
| // "SingleReplica" is for operators to avoid spending resources for high-availability purpose. | ||
| SingleReplicaTopologyMode TopologyMode = "SingleReplica" | ||
|
|
||
| // "External" indicates that the component is running externally to the cluster. When specified | ||
| // as the control plane topology, operators should avoid scheduling workloads to masters or assume | ||
| // that any of the control plane components such as kubernetes API server or etcd are visible within | ||
| // the cluster. | ||
| ExternalTopologyMode TopologyMode = "External" | ||
| ) | ||
|
|
||
| // PlatformType is a specific supported infrastructure provider. | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we actually consistent about infra?
in hypershift we have some infra components that run external (olm) and some that run on cluster (registry) right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct. From an operator point of view, I don't think the External value makes sense for infra topology (Unless we really externalize all of infra). It is meant to apply only to control plane topology for now. However, not sure that we can express that through the API as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So "external" will not be a valid value for status.infrastructureTopology ?
I guess can understand not creating another Type to split them, so i guess we can live with this but it is somewhat unfortunate that it confusingly implies it is valid, even if practice we'd never actually set it to that value.