No we aren't going to reuse --to. The --to directive is just for placement directives. Trying to use that to overload machine mappings for bundles adds complexity for no real value.
We will use --map-machines. I'm a big proponent of explicit is better than implicit. While I'm not 100% fixed on using the term "existing", I don't think either '...' nor ':' make a lot of sense. They are not used elsewhere in juju anywhere, and aren't really intuitive. We also aren't looking to map machine placement directives to other bundle placement directive types. Tim On 10/11/17 10:39, Dmitrii Shcherbakov wrote: > 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 > <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 > <mailto: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 > <mailto: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 <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > <https://lists.ubuntu.com/mailman/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
