add-cloud produces config with redundant region endpoints
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Expired
|
Medium
|
Unassigned |
Bug Description
Region endpoints are optional, needed only when a region's endpoint differs from the cloud's main endpoint. add-cloud treats them as mandatory. I initially observed this behaviour in interactive add-cloud, but it seems to apply to non-interactive forms as well.
This produces config that violates "Don't Repeat Yourself" and is therefore harder to read and maintain.
For example, here is the canonistack config the QA team uses:
canonistack:
type: openstack
auth-types: [userpass]
endpoint: https:/
regions:
lcy01: {}
lcy02: {}
Here is the minimum config that can be produced with add-cloud:
canonistack:
type: openstack
auth-types: [userpass]
endpoint: https:/
regions:
lcy01:
endpoint: https:/
lcy02:
endpoint: https:/
For the latter, the user must enter the same URL three times instead of once, increasing the risk of typos and being less pleasant to use.
For vsphere, add-cloud uses the cloud endpoint as the region endpoint, making redundancy mandatory:
vsphere:
type: vsphere
auth-types: [userpass]
endpoint: 10.245.0.131
regions:
dc0:
endpoint: 10.245.0.131
There is no need for a region endpoint that matches the cloud endpoint. The QA team successfully uses configs without region endpoints many times a day, so we know that they can work. It is easier to read, because it is obvious that there are no discrepancies between cloud and region endpoint. It is easier to maintain because, should an endpoint need to change, only one change is needed.
For the interactive form, updating vsphere should be trivial. It just needs to stop adding region endpoints at all. For openstack, one way to handle it would be to accept "" (i.e. the user pressing Enter with nothing else on the line) as meaning "Do not specify a custom endpoint for this region."
For the non-interactive form, juju could validate the supplied YAML, and then use it as-is, rather than rewriting it.
description: | updated |
Changed in juju: | |
milestone: | 2.1.0 → 2.1-beta4 |
status: | Triaged → Fix Committed |
Changed in juju: | |
status: | Fix Committed → Fix Released |
Changed in juju: | |
status: | Fix Released → Triaged |
Changed in juju: | |
milestone: | 2.1-beta4 → 2.1.0 |
Changed in juju: | |
assignee: | Richard Harding (rharding) → nobody |
Changed in juju: | |
milestone: | 2.1.0 → 2.1.1 |
I talked about this with nate and I think the best experience is to have the endpoint provided become the default value for the future region endpoint value.
Enter the region endpoint url [10.245.0.131]:
In this way, you just hit enter and get a reasonable default value and still allow the user to change it if it's required to something unique.