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

Bug #1595330 reported by Brad Crittenden
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Low
Unassigned

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.

Revision history for this message
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)
Changed in juju:
milestone: 2.0.0 → 2.0.1
Curtis Hovey (sinzui)
Changed in juju:
milestone: 2.0.1 → none
Revision history for this message
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)
Revision history for this message
Tim Penhey (thumper) wrote :

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

Revision history for this message
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)
Changed in juju:
assignee: Vinodhini (vinu-b) → nobody
milestone: 2.4-beta1 → none
tags: removed: bitesize
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 1595330] Re: When deploying a bundle, num_units defaults to zero if not specified

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
>

Revision history for this message
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.

Revision history for this message
Canonical Juju QA Bot (juju-qa-bot) wrote :

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.

Changed in juju:
importance: Medium → Low
tags: added: expirebugs-bot
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.