I think it's nice to reuse --to because we don't use it with bundles on juju deploy. A unified --map[-machines] would also be fine to me.
<token> := (<bundle-machine-spec> | <bundle-unit-spec>)=(<existing-machine-spec> | <existing-unit-spec>) --to (<token>[,<token>]+[,:] ) | : Remap two, otherwise use existing: --to 1=2,3=5,: The same with app names, but have to error out on lxd:1 or kvm:5 in a bundle if exapp/2 or exapp/5 are themselves in lxd or kvm "containers" (surely nested containers or VMs are possible to do by hand but insane in this case): --to 1=exapp/2,3=exapp/5,: This is kind of complex as there *may* be a conflicting placement directive in a bundle for exappplugin/2 or it may be a subordinate (in which case we ignore the mapping altogether) --to exappplugin/2=exapp/2,3=exappother/5,: FWIW it may be a bundle without machine definitions and placement directives, so, still a valid case. Remap two, otherwise allocate new: --to 1=2,3=5 Use existing: --to : Allocate new: <nothing here> Another idea, albeit more complex, is to introduce ranges to that: 3:5=41:43 3:5=41:43,: 3:5=neutron-gateway/0:neutron-gateway/2 Also have to be careful about the following (I haven't seen the feature code yet): 1. odd charm or app names during machine spec parsing: https://launchpad.net/charm-6wind-virtual-accelerator 2. endpoint -> network space bindings and storage bindings for existing apps in a given model that may be present in a newly deployed bundle. Really appreciate the major changes coming to Juju 2.3 - thanks a lot! Best Regards, Dmitrii Shcherbakov Field Software Engineer IRC (freenode): Dmitrii-Sh On Thu, Nov 9, 2017 at 1:20 PM, roger peppe <roger.pe...@canonical.com> wrote: > I still like the idea of overloading the --to flag rather than having > a new --map-machines flag. It's concise and fits well, I think - we > want the machines in this bundle to mapped *to* the machines we're > specifying here. > > I like the thrust of Tim's suggestion for "existing" but I'm not > entirely sure about that word - it's quite long and it doesn't quite > express the identity relationship that I see there. How about "same"? > > For example: > > juju deploy --to 1=2,2=3,same some-bundle > > Another possibility: use ellipses to imply the rest of the mapping: > > juju deploy --to 1=2,2=3,... some-bundle > juju deploy --to ... some-bundle > > > > On 9 November 2017 at 02:43, Tim Penhey <tim.pen...@canonical.com> wrote: > > > > > > On 09/11/17 13:06, Mark Shuttleworth wrote: > >> On 11/07/2017 03:11 PM, John Meinel wrote: > >>> ... > >>> > >>> > >>> > 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. > >> > >> I would expect that --map-machines means that machine numbers correspond > >> UNLESS remapped. So your ugly boilerplate is not needed. > > > > Been thinking more... how about this as a proposal: > > > > I think we can combine both the --use-existing-machines and the > > --bundle-machine into the single --map-machines: > > > > So... > > > > To use the existing machines as is: > > --map-machines existing > > > > To only map two machines, > > --map-machines 1=2,2=3 > > > > To use existing, and map two machines > > --map-machines existing,1=2,2=3 > > > > Thoughts? > > > > Tim > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
