Re: Juju 2.3 beta2 is here!

There is an edge case to that: when you remove a machine and add a new one an ID cannot be reused. I believe it's just auto-increment in the database: one does not reuse auto-incremented IDs for efficiency (otherwise you have to implement "find first available unused ID" functionality). So, if

Re: Juju 2.3 beta2 is here!

On 10 November 2017 at 10:40, Dmitrii Shcherbakov wrote: > This might not be an ideal example after all. However, I encountered > something else in this case - final model machine IDs are not the same as I > would expect while looking at the bundle. I'd've

Re: Juju 2.3 beta2 is here!

This might not be an ideal example after all. However, I encountered something else in this case - final model machine IDs are not the same as I would expect while looking at the bundle. This is Juju 2.2.6, MAAS 2.2.2. I am not sure there can be any guarantees about that due to parallelization of

Re: Juju 2.3 beta2 is here!

On 9 November 2017 at 22:49, Tim Penhey 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. As I see it, machine mapping *is*

Re: Juju 2.3 beta2 is here!

On 10/11/17 12:12, Dmitrii Shcherbakov wrote: > 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: >      

Re: Juju 2.3 beta2 is here!

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

Re: Juju 2.3 beta2 is here!

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

Re: Juju 2.3 beta2 is here!

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. := ( | )=( | ) --to ([,]+[,:] ) | : 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

Re: Juju 2.3 beta2 is here!

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

Re: Juju 2.3 beta2 is here!

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

Re: Juju 2.3 beta2 is here!

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

Re: Juju 2.3 beta2 is here!

... > > 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

Re: Juju 2.3 beta2 is here!

On 6 November 2017 at 17:24, roger peppe wrote: > juju deploy --to 3=0,4=3 Also, looking further forward, I'd like to see more informative machine names in bundles, because with a command line like the above, it's not clear what the purpose of the assigned machines

Re: Juju 2.3 beta2 is here!

On 2 November 2017 at 07:16, Mark Shuttleworth wrote: > On 11/02/2017 04:56 AM, Chris Lee wrote: > > A new development release of Juju is here, 2.3-beta2. > > > 2.3 is looking great, and is worth a test run for those of you with larger > models and an interest in cross-model

Re: Juju 2.3 beta2 is here!

> * Parallelization of the Machine Provisioner >> >> Provisioning of machines is now faster! Groups of machines will now be >> provisioned in parallel reducing deployment time, especially on large >> bundles. Please give it a try and let us know what you think. >> >> Benchmarks for time to

Re: Juju 2.3 beta2 is here!

On Thu, Nov 2, 2017 at 12:57 AM Chris Lee wrote: > A new development release of Juju is here, 2.3-beta2. > Woop woop! > * Autoconfiguration of FAN networking for EC2 and GCE providers > > When creating a model in a VPC environment on EC2 or on GCE FAN settings >

Re: Juju 2.3 beta2 is here!

>> >> * Parallelization of the Machine Provisioner >> >> >> Provisioning of machines is now faster!  Groups of machines will now >> be provisioned in parallel reducing deployment time, especially on >> large bundles.  Please give it a try and let us know what you think. >> > > This is great.

Re: Juju 2.3 beta2 is here!

On 11/02/2017 04:56 AM, Chris Lee wrote: > > A new development release of Juju is here, 2.3-beta2. > 2.3 is looking great, and is worth a test run for those of you with larger models and an interest in cross-model relations. > ## New and Improved > > * Deploying bundles can now target existing