Juju 2.3 beta2 is here!

[Dmitrii Shcherbakov]

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.peppe at 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.penhey at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20171110/1a2cfaf9/attachment.html>