[RFE] availability zone constraints

[Dmitrii Shcherbakov]

I recall that there was an intention to implement availability zone constraints in the same way as spaces:

https://bugs.launchpad.net/juju/+bug/1706462/comments/2

Something like this + handling:
https://github.com/juju/juju/blob/develop/constraints/constraints.go#L37-L88
 Spaces *[]string `json:"spaces,omitempty" yaml:"spaces,omitempty"`
 Zones *[]string `json:"Zones,omitempty" yaml:"Zones,omitempty"`

pad.lv/1706462 is more like a bug rather than a feature request so I created this one with a clear name.

[John A Meinel (jameinel)]

Zones as a placement directive is something I'm interested in supporting. (IIRC we already support this in most places.)

Zones as a constraint feels like it is possible, but potentially violating layering and what zones are supposed to mean. And while it could lead to people fixing a specific issue, it ultimately causes muddy waters in the overall design of systems and how machines should be put into zones, and how bundles need to be defined. It leads to heavy coupling between bundle definitions and the location that they are being deployed into.

Its possible we actually need something more like "zones as a model config" to declare what zones should be treated as off-limits. Generally things like "tags" are a better fit for identifying a set of machines that should be treated as similar, rather than zones to group machines, but not actually intending them to be used as availability zones. (AZ as a concept is generally very useful, so muddying zones to have them not always mean AZ causes this sort of "I want you to treat *these* as an AZ, but not include this one".)

It is something that is technically feasible to do, but I'm quite concerned that it is layering a hack in Juju to overcome a hack in other software, thus making things more complex rather than more understandable.

[Dmitrii Shcherbakov (dmitriis)]

John,

The requirements the field team members and I have encountered:

1. AZ-specific charm configuration (doesn't have to be one AZ, may be a group of AZs with a common configuration). Same charm/application - different config;
2. Large deployments may have AZs used for particular purposes. Say, your MAAS would control the whole DC but you'd deploy OpenStack in AZ0, AZ1, AZ2 and Kubernetes in AZ3, AZ4, AZ5;
3. Large installations of MAAS have "implicit tenants" (like projects in OpenStack) - they may create their own zone and start working on machines that belong to that zone but those machines would not be used for deployment purposes just yet.

2 - as you mentioned, zones as a model-config would be interesting to explore, provided that this model config can be changed to add new zones to a model or remove them from a model.

3 - this is something I would talk about with the MAAS team as well because it would seem that we need a Keystone-like story with (identity, project, role) assignments to do RBAC and resource separation for a given user or user group. That would solve the resource isolation problem without creating unnecessary functionality in Juju.

~~

1 - I have a practical example for this related to Neutron and OpenVSwitch and I think I need to give the full context because it may not be apparent from the RFE description.

In this particular case there are different VLANs allocated to usage by SDN on physical switches (which MAAS is not aware about). Machines on each AZ are attached to a different switch fabric so even if the VLAN numbers used match, those VLANs are not identical because they reside on different L2 networks.

So per-AZ charm configuration is needed due to (potentially different) per-AZ switch fabric configuration - we have no awareness of that from MAAS because it does not control switches and cannot provide meta-data we need.

https://paste.ubuntu.com/26512589/

To interpret why the bundle is structured this way:

https://docs.openstack.org/ocata/networking-guide/deploy-ovs-provider.html (how this setup works in OpenStack - this is the one without neutron-gateway - VM instances are connected via an OVS bridge on a compute node to a physical network without VXLAN-ing to a gateway first).

Routed provider networks (VRFs) in OpenStack to model multi-segment provider networks:
https://docs.openstack.org/neutron/pike/admin/config-routed-networks.html#example-configuration
"Network or compute nodes
Configure the layer-2 agent on each node to map one or more segments to the ***appropriate physical network*** bridge or interface and restart the agent."

https://jujucharms.com/neutron-openvswitch/#charm-config-vlan-ranges
vlan-ranges charm config
(string) Space-delimited list of <physical_network>:<vlan_min>:<vlan_max> or <physical_network> specifying physical_network names usable for VLAN provider and tenant networks, as well as ranges of VLAN tags on each available for allocation to tenant networks.

* Per-AZ config includes a physical_network name and a vlan range;

    options:
      bridge-mappings: *bridge-mappings-az2
      vlan-ranges: *vlan-ranges-az2

* charm-neutron-openvswitch needs to be placed per-AZ but t...

[Launchpad Janitor (janitor)]

[Expired for juju because there has been no activity for 60 days.]

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.