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 > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
