...
> > Perhaps just: > > > > juju deploy --map-machines A=B,C=D > > > > ... or some variant of that? > > > > Let's use the betas to refine and condense and clarify. > > +1 to that. I'm wondering if use-existing-machines is ever appropriate > on its own, as the machine numbers in a model are ephemeral but > machine numbers in a bundle are static. > > Feedback from Admins that one of their big use case really is for bundle-a to lay down a definition/base charm across everything, and bundle-b to be meant as an exact overlay, and all of the machine-ids are exact matches. And having to specify 0=0,...50=50 is a lot of ugly boilerplate. While a plethora of options isn't great, addressing a significant use case is. I think we need to keep in mind that there really are 2 distinct use cases for bundles: 1) Sharable snapshots of a particular application 2) Descriptions of an entire deployment, that people want to be able to reproduce. (Teardown, redo, understand the description of an existing deployment, etc.) For things like the charm store, (1) is common, and the use cases around machines being an abstract idea is common. For many customer engagements, we end up with bundles that are very specific to the site. The '--use-existing-machines' is meant to flip the logic around machine-identities are purely abstract, to machine identities are explicit unless otherwise changed. I agree that it would be good to expand upon the ability to have abstract identifiers for machines in bundles, so that you don't end up with 1=2,2=3,3=1 sort of scenarios. John =:->
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
