When deploying a bundle, num_units defaults to zero if not specified

Bug #1595330 reported by Brad Crittenden on 2016-06-22
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

If a service/application in a bundle.yaml file does not specify a 'num_units' constraint, Juju 2 now defaults to zero units. The bundle deploys and relations are added but no machines are available for the affected services.

This behavior is incredibly confusing and unintuitive.

If those semantics are really what you want, you should at least print a message in the bundle deploy making it obvious what just happened. If a machine is created a message is currently printed like

added jem/0 unit to new machine

If a service is skipped because no units are specified the user should be informed.

Personally I think num_units should default to 1 because that is the most reasonable.

Cheryl Jennings (cherylj) wrote :

+1 to defaulting to 1 unit if num_units is not specified.

tags: added: bundles usability
Changed in juju-core:
status: New → Triaged
importance: Undecided → Medium
tags: added: juju-release-support
tags: added: bitesize
Changed in juju-core:
milestone: none → 2.0.0
affects: juju-core → juju
Changed in juju:
milestone: 2.0.0 → none
milestone: none → 2.0.0
Curtis Hovey (sinzui) on 2016-10-06
Changed in juju:
milestone: 2.0.0 → 2.0.1
Curtis Hovey (sinzui) on 2016-10-28
Changed in juju:
milestone: 2.0.1 → none
Ian Booth (wallyworld) wrote :

Not sure if Tim's recent bundle improvements have fixed this. Needs to be checked to see if problem still exists and fixed if it does.

Changed in juju:
milestone: none → 2.4-beta1
assignee: nobody → Vinodhini (vinu-b)
Tim Penhey (thumper) wrote :

This is non-trivial and behaviour we may want to change at the 3.0 time, not 2.4.

Tim Penhey (thumper) wrote :

It effectively means we have to double parse the YAML file, because the num_units is an integer, and zero is a valid number of units to specify. And in particular if you try to set non-zero for a subordinate, it is likely to have some problems.

This bug has prickly edges.

Ian Booth (wallyworld) on 2018-04-15
Changed in juju:
assignee: Vinodhini (vinu-b) → nobody
milestone: 2.4-beta1 → none
tags: removed: bitesize

Can't we just change the struct to have a pointer to an int in that field.
And then it will be 'nil' if it wasn't supplied, to distinguish it from
being supplied as a valid 0?

On Mon, Apr 16, 2018 at 3:01 AM, Ian Booth <email address hidden> wrote:

> ** Changed in: juju
> Assignee: Vinodhini (vinu-b) => (unassigned)
> ** Changed in: juju
> Milestone: 2.4-beta1 => None
> ** Tags removed: bitesize
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1595330
> Title:
> When deploying a bundle, num_units defaults to zero if not specified
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1595330/+subscriptions

Tim Penhey (thumper) wrote :

A key problem here is subordinates.

The current bundlechanges library handles this by having the default as zero, as you don't specifically have units of subordinates.

We would have to change the bundlechanges library so it also knew whether the charms were subordinates or not in order to correctly handle the missing case.

This involves both callsites getting access to the charms metadata.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers