[azure provider] Availability Sets are not set for multi-unit VMs

Bug #1892854 reported by Peter Jose De Sousa
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Wishlist
Unassigned

Bug Description

Hi,

[Problem]

When deploying a hyper-converged architecture on Azure, juju will not configure Availability Sets.

[Detail]

When deploying applications on Azure if applications are deployed on a machine with a 1:1 relation i.e. 1 application to 1 machine, Juju will configure Availability Sets, but if there are multiple units on a VM then this will not happen.

This causes issues when deploying hyper-converged architectures which require load balancing, e.g. Kubernetes Masters in Charmed Kubernetes.

[Resolution]

Potentially providing a configuration option to put certain machines into Availability Sets, e.g. contraints="availability-set=masters".

Cheers,

Peter

Revision history for this message
Pedro Guimarães (pguimaraes) wrote :

I propose we add this as a new machine-constraint, where the user can add one (or several?) availability-set entries.
Should we create those sets, if they don't exist?

Created a PR with this idea: https://github.com/juju/juju/pull/11938

Revision history for this message
Ian Booth (wallyworld) wrote :

A few thoughts...

constraints are intended to be provider agnostic. The supported constraint attributes are not supposed to be specific to any provider. Availability Sets are very much an Azure only construct needed because Windows can't apply updates without needing to reboot :-)

The existing algorithm for determining the availability set name is to pick one of the applications deployed to the machine. So it's not strictly correct to say that availability sets are not used if a machine has more than one unit placed on it.

Given machine constraints are applied prior to provisioning, I assume the workflow you are looking to use is something like:

$ juju add-machine --constraints availability-set=foo
Machine 3 added.

$ juju deploy somecharm --to 3

A better approach is to use placement. Placement can be used for provider specific behaviour. eg we already have

$ juju add-machine zone=us-east-1a (start a machine in zone us-east-1a on AWS)
$ juju add-machine maas2.name (acquire machine maas2.name on MAAS)

We would introduce a new placement directive for availability set on Azure:

$ juju add-machine availability-set=foo

Revision history for this message
Ian Booth (wallyworld) wrote :

Apparently this is less important now so marking as wishlist

Changed in juju:
milestone: none → 2.9-beta1
importance: Undecided → Medium
status: New → Triaged
importance: Medium → Wishlist
Changed in juju:
milestone: 2.9-beta1 → 2.9-rc1
Ian Booth (wallyworld)
Changed in juju:
milestone: 2.9-rc1 → 2.9.1
Ian Booth (wallyworld)
Changed in juju:
milestone: 2.9.1 → 2.9.2
Changed in juju:
milestone: 2.9.2 → 2.9.3
Changed in juju:
milestone: 2.9.3 → 2.9.4
Changed in juju:
milestone: 2.9.4 → 2.9.5
Changed in juju:
milestone: 2.9.5 → 2.9.6
Changed in juju:
milestone: 2.9.6 → 2.9.7
Changed in juju:
milestone: 2.9.7 → 2.9.8
Changed in juju:
milestone: 2.9.8 → 2.9.9
Changed in juju:
milestone: 2.9.9 → 2.9.10
Changed in juju:
milestone: 2.9.10 → 2.9.11
Changed in juju:
milestone: 2.9.11 → 2.9.12
Changed in juju:
milestone: 2.9.12 → 2.9.13
Changed in juju:
milestone: 2.9.13 → 2.9.14
Changed in juju:
milestone: 2.9.14 → 2.9.15
Changed in juju:
milestone: 2.9.15 → 2.9.16
Changed in juju:
milestone: 2.9.16 → 2.9.17
Changed in juju:
milestone: 2.9.17 → 2.9.18
Changed in juju:
milestone: 2.9.18 → 2.9.19
Changed in juju:
milestone: 2.9.19 → 2.9.20
Changed in juju:
milestone: 2.9.20 → 2.9.21
Changed in juju:
milestone: 2.9.21 → 2.9.22
Changed in juju:
milestone: 2.9.22 → 2.9.23
Changed in juju:
milestone: 2.9.23 → 2.9.24
Changed in juju:
milestone: 2.9.24 → 2.9.25
Changed in juju:
milestone: 2.9.25 → 2.9.26
Changed in juju:
milestone: 2.9.26 → 2.9.27
Changed in juju:
milestone: 2.9.27 → 2.9.28
Changed in juju:
milestone: 2.9.28 → 2.9.29
Ian Booth (wallyworld)
Changed in juju:
milestone: 2.9.29 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.