new bundle format: default value for num_units
roger peppe
roger.peppe at canonical.com
Fri May 15 20:08:07 UTC 2015
I like this take on it - it fits well with my intuition in the matter too.
Unless I misunderstand, this "topology only" view would work well with a
zero unit count as a default, because that way you can deploy the services
to an environment, creating the topology, and then decide how many units of
each to add. Interactivity is always possible too.
cheers,
rog.
On 15 May 2015 17:56, "Mark Shuttleworth" <mark at ubuntu.com> wrote:
>
> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150515/86c9fc88/attachment.html>
More information about the Juju
mailing list