<div dir="ltr"><div>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.</div><div><br></div><div><token> := (<bundle-machine-spec> | <bundle-unit-spec>)=(<<wbr>existing-machine-spec> | <existing-unit-spec>)</div><div>--to (<token>[,<token>]+[,:] ) | :</div><div><br></div><div>Remap two, otherwise use existing:</div><div><br></div><div>--to 1=2,3=5,:</div><div><br></div><div>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):</div><div><br></div><div><div>--to 1=exapp/2,3=exapp/5,:</div></div><div><br></div><div>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)</div><div><br></div><div>--to exappplugin/2=exapp/2,3=<wbr>exappother/5,:<br></div><div><br></div><div>FWIW it may be a bundle without machine definitions and placement directives, so, still a valid case.</div><div><br></div><div>Remap two, otherwise allocate new:</div><div><br></div><div>--to 1=2,3=5<br></div><div><br></div><div>Use existing:</div><div><br></div><div>--to :</div><div><br></div><div>Allocate new:</div><div><nothing here></div><div><br></div><div>Another idea, albeit more complex, is to introduce ranges to that:</div><div><br></div><div>3:5=41:43</div><div><br></div><div>3:5=41:43,:<br></div><div><br></div><div>3:5=neutron-gateway/0:neutron-<wbr>gateway/2</div><div><br></div><div>Also have to be careful about the following (I haven't seen the feature code yet):</div><div><br></div><div>1. odd charm or app names during machine spec parsing:</div><div><a href="https://launchpad.net/charm-6wind-virtual-accelerator" target="_blank">https://launchpad.net/charm-<wbr>6wind-virtual-accelerator</a><br></div><div><br></div><div>2. endpoint -> network space bindings and storage bindings for existing apps in a given model that may be present in a newly deployed bundle.</div><div><br></div><div>Really appreciate the major changes coming to Juju 2.3 - thanks a lot!<br></div><div><br></div><div class="gmail_extra"><br clear="all"><div><div class="m_-1983882573423468977gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Best Regards,<div>Dmitrii Shcherbakov</div><div><br></div><div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="color:rgb(68,68,68);font-size:12.8px">Field Software Engineer</span><br style="color:rgb(68,68,68);font-size:12.8px"><span style="font-size:12.8px">IRC (freenode): Dmitrii-Sh</span><br></div></div></div></div></div></div></div></div></div></div> <br><div class="gmail_quote">On Thu, Nov 9, 2017 at 1:20 PM, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I still like the idea of overloading the --to flag rather than having<br> a new --map-machines flag. It's concise and fits well, I think - we<br> want the machines in this bundle to mapped *to* the machines we're<br> specifying here.<br> <br> I like the thrust of Tim's suggestion for "existing" but I'm not<br> entirely sure about that word - it's quite long and it doesn't quite<br> express the identity relationship that I see there. How about "same"?<br> <br> For example:<br> <br> juju deploy --to 1=2,2=3,same some-bundle<br> <br> Another possibility: use ellipses to imply the rest of the mapping:<br> <br> juju deploy --to 1=2,2=3,... some-bundle<br> juju deploy --to ... some-bundle<br> <div class="m_-1983882573423468977HOEnZb"><div class="m_-1983882573423468977h5"><br> <br> <br> On 9 November 2017 at 02:43, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote:<br> ><br> ><br> > On 09/11/17 13:06, Mark Shuttleworth wrote:<br> >> On 11/07/2017 03:11 PM, John Meinel wrote:<br> >>> ...<br> >>><br> >>><br> >>> > Perhaps just:<br> >>> ><br> >>> > juju deploy --map-machines A=B,C=D<br> >>> ><br> >>> > ... or some variant of that?<br> >>> ><br> >>> > Let's use the betas to refine and condense and clarify.<br> >>><br> >>> +1 to that. I'm wondering if use-existing-machines is ever appropriate<br> >>> on its own, as the machine numbers in a model are ephemeral but<br> >>> machine numbers in a bundle are static.<br> >>><br> >>><br> >>> Feedback from Admins that one of their big use case really is for<br> >>> bundle-a to lay down a definition/base charm across everything, and<br> >>> bundle-b to be meant as an exact overlay, and all of the machine-ids<br> >>> are exact matches. And having to specify 0=0,...50=50 is a lot of ugly<br> >>> boilerplate.<br> >><br> >> I would expect that --map-machines means that machine numbers correspond<br> >> UNLESS remapped. So your ugly boilerplate is not needed.<br> ><br> > Been thinking more... how about this as a proposal:<br> ><br> > I think we can combine both the --use-existing-machines and the<br> > --bundle-machine into the single --map-machines:<br> ><br> > So...<br> ><br> > To use the existing machines as is:<br> > --map-machines existing<br> ><br> > To only map two machines,<br> > --map-machines 1=2,2=3<br> ><br> > To use existing, and map two machines<br> > --map-machines existing,1=2,2=3<br> ><br> > Thoughts?<br> ><br> > Tim<br> <br> --<br> Juju-dev mailing list<br> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju-dev</a><br> </div></div></blockquote></div><br></div></div>