Juju 2.3 beta2 is here!

Thu Nov 9 23:12:28 UTC 2017

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.penhey at 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.peppe at canonical.com
> > <mailto: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
> >     <mailto: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 <mailto:Juju-dev at lists.ubuntu.com>
> >     Modify settings or unsubscribe at:
> >     https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >     <https://lists.ubuntu.com/mailman/listinfo/juju-dev>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20171110/84307d1e/attachment-0001.html>