-
Notifications
You must be signed in to change notification settings - Fork 417
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
Allow Ultra Disk Enablement for Persistent Volumes #1852
Comments
/help |
@CecileRobertMichon: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed In response to this:
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. |
@damdo has volunteered to look into this, though not a Kube-sigs member so I don't think I can assign him I'll take the responsibility for this for now |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
I'm now in the process of putting together a design proposal for this. |
Here is the API design and behaviour proposal for adding Azure Ultra Disks support via Persistent Volumes to CAPZ. As a note to this, the design choices behind this proposal and the reason why we are proposing an Enum field with string values rather than a boolean (or boolean pointer) has two roots:
Azure Ultra Disks via Persistent Volumes - ProposalTo allow the mounting of Persistent Volume Claims of StorageClass To give instances this ability an Azure Additional Capability ( Furthermore the So when coming up with a proposal for extending the API, the fact that the For this purpose a new field will be added to the
type AzureMachineSpec struct {
// Existing fields will not be modified
...
// UltraSSDCapability enables or disables Azure UltraSSD capability for a virtual machine.
// When omitted, the platform may enable the capability based on the configuration of data disks.
// +kubebuilder:validation:Enum:="Enabled";"Disabled"
// +optional
UltraSSDCapability AzureUltraSSDCapabilityState `json:"ultraSSDCapability,omitempty"`
}
// AzureUltraSSDCapabilityState defines the different states of an UltraSSDCapability
type AzureUltraSSDCapabilityState string
// These are the valid AzureUltraSSDCapabilityState states.
const (
// "AzureUltraSSDCapabilityTrue" means the Azure UltraSSDCapability is Enabled
AzureUltraSSDCapabilityTrue AzureUltraSSDCapabilityState = "Enabled"
// "AzureUltraSSDCapabilityFalse" means the Azure UltraSSDCapability is Disabled
AzureUltraSSDCapabilityFalse AzureUltraSSDCapabilityState = "Disabled"
) |
I want to push back a little bit on this. The API conventions do not discourage booleans, they just encourage being intentional about booleans and planning for future evolution of the fields: "Think twice about bool fields. Many ideas start as boolean but eventually trend towards a small set of mutually exclusive options. Plan for future expansions by describing the policy options explicitly as a string type alias (e.g. TerminationMessagePolicy)." In this particular case, do you foresee future options for Additionally, the design should take into account future "additional capabilities" that we might want to support for VMs, such as Hibernation (so far the only other exposed option AFAIK). Would we add a separate field in the AzureMachineSpec for each capability? What if Azure eventually supports 10+ "additional" capabilities? This might be a good reason to stay closer to the Azure SDK and add an "AdditionalCapabilities" field as such: type AzureMachineSpec struct {
// Existing fields will not be modified
...
// AdditionalCapabilities specifies additional capabilities enabled or disabled on the virtual machine.
// +optional
AdditionalCapabilities *AdditionalCapabilities `json:"additionalCapabilities,omitempty"`
}
// AdditionalCapabilities enables or disables a capability on the virtual machine.
type AdditionalCapabilities struct {
// UltraSSDEnabled enables or disables Azure UltraSSD capability for the virtual machine.
// Defaults to true if Ultra SSD data disks are specified.
// +optional
UltraSSDEnabled *bool `json:"ultraSSDEnabled,omitempty"`
...
// other capabilities can be added later
} |
In a previous discussion I mentioned the fact that the behaviour described in the second point I've quoted above should be behind a user facing option. The way I was looking at this, the UltraSSDCapability does indeed have 4 states already:
I'm not sure others felt so strongly about the auto on/off being a feature users should opt into though
This seems worthwhile to me |
@CecileRobertMichon thanks a lot for your feedback on this.
I agree and think it's a good idea to have an "AdditionalCapabilities" struct field to collect and support future additional capabilities.
The initial reasoning behind proposing it as a multi-state Enum is basically what @JoelSpeed said. To capture "automatic" behaviour of enabling/disabling the feature based on needs and status quo, which may be useful in situations like this one for example:
|
Yeah I think the Let's see what @CecileRobertMichon thinks :) |
Not sure I see the value in having both
|
Thanks for your suggestions @CecileRobertMichon, ok let's go with this design then 👍 |
/kind feature
Describe the solution you'd like
Further to #1134 which allows the Azure ultra disks to be attached to VMs as data disks, it would be useful to enable the ultra disk capability on the VMs when no data disks are attached.
The Azure CSI driver has the ability to provision ultra disk based persistent volumes, but for this to work, the VMs that the PVs are attached to must have the
AdditionalCapabilities.UltraSSDEnabled
set to true.When CAPZ creates a VM today, there is no way to explicitly enable this capability. This is only enabled when a ultra disk data disk is defined within the machine spec.
We should add a new field to the machine spec to allow this feature to be explicitly enabled, and possibly (based on suggestion from @alexeldeib) default this to true using a webhook when an ultra SSD data disk is defined on the machine.
CC @CecileRobertMichon @alexeldeib
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
kubectl version
):/etc/os-release
):The text was updated successfully, but these errors were encountered: