new bundle format: default value for num_units

[Mark Shuttleworth]

I think the absence of num_units is in fact an invitation to prompt the
user for this information. It corresponds to a shared description of the
*topology* independent of scale. With bundle composition, this allows us
to have a root bundle which describes the services and configuration and
relationships, and bundles that include it but map the topology to
specific scales (by adding the desired units).

Mark

On 15/05/15 09:41, roger peppe wrote:
> With the new bundle format [1] we recently discovered there is a problem
> with respect to the service num_units field - bundles migrated to the
> new format would always gain a num_units: 1 field which is wrong when
> the service uses a subordinate charm.
>
> We'd like to propose that when the num_units field is omitted from a
> service, it will imply 0 units (or n subordinate units when service is
> a subordinate).  This is a change from the original format where omitting
> num_units implies 1 unit for non-subordinate charms.
>
> Doing this means we can show an accurate non-subordinate unit counts
> for a bundle without needing to fetch the charms that it uses (in the
> old format, it's not possible to tell whether a service has 1 unit or
> an indefinite number).
>
> Theoretically it's possible for a charm to change from subordinate to
> non-subordinate between revisions so even if we fetch the charms, that
> does not necessarily imply the count remains the same in the future.
>
> It also simplifies a bunch of the code :)
>
> Note that when migrating from the old format, we would omit the
> num_units field for subordinate charms, and add it explicitly
> set to 1 for non-subordinates. Therefore, the proposed change of
> defaulting to 0 only affects usage of the new format.
>
> My question, for those of you that use bundles a lot, would it be a
> problem to have to be explicit about the number of units in a service?
>
>   cheers,
>    rog.
>
> [1] https://docs.google.com/document/d/1SF8hTBi6oVbki8V__beNij6wnQU-5cm6PZsy5gf0j_Y
>