Tim,
Whichever works best in terms of code-base clarity and stability - it's
hard to debug spaghetti code with lots of overrides so fully agreed on --to.
"existing" sounds good to me. I only have to do it once and it's easy to
remember. Extra 3 characters to type are irrelevant when you type 300
characters per minute.
It's situations like the following that I am trying to avoid:
rabbitmq-server:
charm: cs:xenial/rabbitmq-server
bindings:
"": *oam-space
amqp: *internal-space
cluster: *internal-space
options:
source: *openstack-origin
min-cluster-size: 3
cluster-partition-handling: pause_minority
num_units: 3
to:
- lxd:0
- lxd:1
- lxd:2
serialized by hand to: juju deploy rabbitmq-server --config
../rabbitmq.yaml -n 3 --to lxd:0,lxd:1,lxd:12 --bind "space-oam
amqp=space-oam cluster=space-oam"
cat ../rabbitmq.yaml
rabbitmq-server:
source: cloud:xenial-ocata
min-cluster-size: 3
cluster-partition-handling: pause_minority
Which includes brain-parsing the definition, serializing it to
<appname>.yaml + -n <n> --to <placement> --bind <spaces>
Machine to unit mapping: not that important in my view.
Best Regards,
Dmitrii Shcherbakov
Field Software Engineer
IRC (freenode): Dmitrii-Sh
On Fri, Nov 10, 2017 at 1:49 AM, Tim Penhey <tim.pen...@canonical.com>
wrote:
> 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
