-
Notifications
You must be signed in to change notification settings - Fork 254
HIVE-2391: vSphere zonal support #2731
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
base: master
Are you sure you want to change the base?
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 |
|---|---|---|
| @@ -1,33 +1,25 @@ | ||
| package vsphere | ||
|
|
||
| import "github.com/openshift/installer/pkg/types/vsphere" | ||
|
|
||
| // MachinePool stores the configuration for a machine pool installed | ||
| // on vSphere. | ||
| type MachinePool struct { | ||
| vsphere.MachinePool `json:",inline"` | ||
|
|
||
| // ResourcePool is the name of the resource pool that will be used for virtual machines. | ||
| // If it is not present, a default value will be used. | ||
| // Deprecated: use Topology instead | ||
| // +optional | ||
| ResourcePool string `json:"resourcePool,omitempty"` | ||
|
|
||
| // NumCPUs is the total number of virtual processor cores to assign a vm. | ||
| NumCPUs int32 `json:"cpus"` | ||
|
|
||
| // NumCoresPerSocket is the number of cores per socket in a vm. The number | ||
| // of vCPUs on the vm will be NumCPUs/NumCoresPerSocket. | ||
| NumCoresPerSocket int32 `json:"coresPerSocket"` | ||
|
|
||
| // Memory is the size of a VM's memory in MB. | ||
| MemoryMiB int64 `json:"memoryMB"` | ||
|
|
||
| // OSDisk defines the storage for instance. | ||
| OSDisk `json:"osDisk"` | ||
| DeprecatedResourcePool string `json:"resourcePool,omitempty"` | ||
|
|
||
| // TagIDs is a list of up to 10 tags to add to the VMs that this machine set provisions in vSphere. | ||
| // Deprecated: use Topology instead | ||
| // +kubebuilder:validation:MaxItems:=10 | ||
| TagIDs []string `json:"tagIDs,omitempty"` | ||
| } | ||
| DeprecatedTagIDs []string `json:"tagIDs,omitempty"` | ||
|
|
||
| // OSDisk defines the disk for a virtual machine. | ||
| type OSDisk struct { | ||
| // DiskSizeGB defines the size of disk in GB. | ||
| DiskSizeGB int32 `json:"diskSizeGB"` | ||
| // Topology is the vSphere topology that will be used for virtual machines. | ||
| // If it is not present, a default value will be used. | ||
| // +optional | ||
| Topology *vsphere.Topology `json:"topology,omitempty"` | ||
|
Member
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. Previously we were getting the topology from the CD. I assumed this was:
IIUC by including this field you're providing a way for a specific MachinePool to override the topology settings for a given FD when producing the mset for that FD. Are there legit, supported use cases for that? Is it only to provide backward compatibility for ResourcePool and TagIDs? If that's the case, we would probably need to make this a map, keyed by zone...
Contributor
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. I was thinking the topology can be used to filter out all zones matched.
Member
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.
Assume this is a typo; one was Looking at the code, I think you would need to include FD.ZoneType: "HostGroup" for the VMGroup field to get a non-default value... but AFAICS HostGroup is only used day 0; it's ignored in the MachineSet generation paths.
Zones are always/only matched based on We need to dig deeper here and figure out if there are any fields in I think we've already seen that at least a subset of the fields can't be overridden; and the fact that they're required by the schema makes this awkward and annoying. I'm thinking for the sake of simplicity, we should
If we get customers asking for topology things to be per-mset tunable later on, we can add My guess: YAGNI :)
Contributor
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.
|
||
| } | ||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
I think it happens to be functionally irrelevant since this isn't a pointer, but adding
+optionalwould at least make this field disappear from therequiredlist in the schema, as well as being visually pro forma for a field we're deprecating.Since this CRD is only generated by hive, I would expect any external consumers would be read-only. I wonder if we should describe how new code will behave to give consumers a hint as to how to change their code when they see this. Namely, it looks like we're going to only use the new thing for new instances, but not try to convert legacy instances in the field. Thus consumers would need to check both, like we do.
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.
Does it means a test of hive upgrade is needed? I didn't do it yet.
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.
Oh, yeah, we should definitely have a test case where we
Other more "normal" upgrade-y scenarios would also be useful. Install CD with old hive, upgrade, and validate that MachinePool (auto)scaling and deprov flows all work as expected. This would have some functional overlap with your existing scenarios that use the legacy install-config and MP shapes, but is probably worth a separate test suite.
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.
I'll add these 2 test cases.