Re: Juju 2.3 beta2 is here!

[roger peppe]

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  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
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

 := ( |
)=(
| )
--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
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:


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 
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  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
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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

Re: Juju 2.3 beta2 is here!

[Tim Penhey]

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.
> 
>  := ( |
> )=( | )
> --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
> 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:
> 
> 
> 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  > 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  > 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
> 

Re: Juju 2.3 beta2 is here!

[Tim Penhey]

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:
>       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
> .yaml + -n  --to  --bind 

I don't understand what it is you are trying to avoid here?

What is it you are trying to do?

Tim

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.3 beta2 is here!

[Dmitrii Shcherbakov]

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
.yaml + -n  --to  --bind 

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 
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.
> >
> >  := ( |
> > )=( | )
> > --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
> > 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:
> > 
> >
> > 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  > > 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  > > wrote:
> > >
> > >
> > > On 09/11/17 13:06, Mark Shuttleworth wrote:
> > >> On 11/07/2017 03:11 PM, John Meinel wrote:
> > >>> ...
> > >>>
> > >>>
> > >>> > 

how to bind to the default space in a bundle

[James Beedy]

Is it possible to accomplish the following using a bundle?

`juju deploy --bind "default-space db=db-space db-admin=admin-space" mysql`


thanks
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.3 beta3 is here!

[Chris Lee]

A new development release of Juju is here, 2.3-beta3. This is primarily a
bug fix release which addresses issues carried over from beta2.

## New and Improved

* A new command "remove-saas", aliased to "remove-consumed-application", is
added to remove a SAAS entry from a consuming model.

* Support for the new Google Cloud asia-south1 (Mumbai) region.

* Lots of papercut fixes for command help and other user facing text.

## Fixes

For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.3-beta3

Some notable fixes include:

* The issue of not a machine's public address not always being available
when deploying a cross model scenario from a script has been addressed.
Feedback welcome to ensure this has been fix in all scenarios.

## How can I get it?

The best way to get your hands on this release of Juju is to install it as
a snap package (see https://snapcraft.io/ for more info on snaps).

snap install juju --classic

Other packages are available for a variety of platforms. Please see the
online documentation at https://jujucharms.com/docs/stable/reference-install.
Those subscribed to a snap channel should be automatically upgraded. If
you’re using the ppa/homebrew, you should see an upgrade available.

## Feedback Appreciated!

We encourage everyone to let us know how you're using Juju. Send us a

message on Twitter using #jujucharms, join us at #juju on freenode, and

subscribe to the mailing list at j...@lists.ubuntu.com.

## More information
To learn more about juju please visit https://jujucharms.com.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev