Machine set creation fails if AZ is not selection with OpenStack Provider
What happened
When creating a Machine set (during initial cluster provision or adding to existing cluster), the creation fails if Availability Zone is not selected. Availability Zone field is not mandatory.
Expected behavior
Option1: Availability Zone field should be mandatory (preferably pre-selected as flavor) Option2: Availability Zone should be selected by the backend randomly
How to reproduce
Create a Machine set (during initial cluster provision or adding to existing cluster) without specifying Availability Zone (non mandatory field).
The creation fails in the last stage with the following error:
failed to create machine deployment: admission webhook "machine-controller.kubermatic.io-machinedeployments" denied the request: validation failed: failed to get availability zone "": not found
Environment
- UI Version: v2.25.5
- API Version: v2.25.5
- Domain:
- Others: OpenStack provider with 3 AZs.
Current workaround
Select Availability Zone
Affected user persona
Business goal to be improved
Metric to be improved
I would prefer to go with option 1, making the AZ field mandatory and pre-selected with the first AZ by default. What are your thoughts?
Option1 (Availability Zone field should be mandatory (preferably pre-selected as flavor)
The field can be changed to mandatory here: https://github.com/kubermatic/dashboard/blob/main/modules/web/src/app/node-data/basic/provider/openstack/component.ts#L167
Error is returned from getAvailabilityZone function of machine-controller: https://github.com/kubermatic/machine-controller/blob/main/pkg/cloudprovider/provider/openstack/provider.go#L537
Which specifically requires AZ to be selected. https://github.com/kubermatic/machine-controller/blob/main/pkg/cloudprovider/provider/openstack/helper.go#L109
Option2 (Availability Zone should be selected by the backend randomly)
However, for option2 there is AddDefaults function in machine-controller. It seems to select AZ automatically if there is only 1 AZ. The "random" AZ can be added here. https://github.com/kubermatic/machine-controller/blob/main/pkg/cloudprovider/provider/openstack/provider.go#L385
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Need to check in machine-controller first if it's consistent with the UI, if it is mandatory in MC? it should be too in the UI
If none is specified we could pick one from seed for example
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kubermatic-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
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-sigs/prow repository.