| 2016-11-11 14:43:43 |
Aaron Bentley |
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://keystone.canonistack.canonical.com:443/v2.0/
regions:
lcy01: {}
lcy02: {}
Here is the minimum config that can be produced with add-cloud:
canonistack:
type: openstack
auth-types: [userpass]
endpoint: https://keystone.canonistack.canonical.com:443/v2.0/
regions:
lcy01:
endpoint: https://keystone.canonistack.canonical.com:443/v2.0/
lcy02:
endpoint: https://keystone.canonistack.canonical.com:443/v2.0/
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." |
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://keystone.canonistack.canonical.com:443/v2.0/
regions:
lcy01: {}
lcy02: {}
Here is the minimum config that can be produced with add-cloud:
canonistack:
type: openstack
auth-types: [userpass]
endpoint: https://keystone.canonistack.canonical.com:443/v2.0/
regions:
lcy01:
endpoint: https://keystone.canonistack.canonical.com:443/v2.0/
lcy02:
endpoint: https://keystone.canonistack.canonical.com:443/v2.0/
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. |
|
