THE FAN - what providers support "provider" type

[James Beedy]

@wpk very exciting stuff here, and nice work!

One question, which providers support "provider" type FAN container
networking?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

THE FAN - what providers support "provider" type

[James Beedy]

@wpk very exciting stuff here, and nice work!

One question, which providers support "provider" type FAN container
networking?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: "Attempting to connect to" takes a long time

[John Meinel]

We could use better progress information but once connected we also update
the packages installed on the machine and download and install a few
packages.
Having the latest Ubuntu image often means we have fewer packages to
install.

John
=:->

On Oct 6, 2017 7:00 AM, "fengxia"  wrote:

> Hi Juju,
>
> Boostrapping a local LXD controller, it sits at "Attempting to connect
> to..." for a good 5-10 minutes. Any idea what it is doing, and how to speed
> it up?
>
> _
>
> Host: Ubuntu 16.04
>
> Juju: 2.2.4-xenial-amd64
>
> CLI: juju bootstrap localhost devlocal
>
> Output:
>
> Please either create a new controller using "juju bootstrap" or connect to
> another controller that you have been given access to using "juju
> register".
>
> Creating Juju controller "c6k37aysz8" on localhost/localhost
> Looking for packaged Juju agent version 2.2.4 for amd64
> To configure your system to better support LXD containers, please see:
> https://github.com/lxc/lxd/blob/master/doc/production-setup.md
> Launching controller instance(s) on localhost/localhost...
>  - juju-4a20f8-0 (arch=amd64)
> Fetching Juju GUI 2.9.2
> Waiting for address
> Attempting to connect to 10.175.135.202:22
>
>
> --
> Feng Xia
>
> Advisory Engineer
> Datacenter Group (DCG), Lenovo US
> 8000 Development Dr, Morrisiville, NC 27509
> W: http://www.lenovo.com
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju 2.3 beta1 is here!

[Ian Booth]

After many months of effort, we're pleased to announce the release of the first
beta for the upcoming Juju 2.3 release. This release has many long requested new
features, some of which are highlighted below.

Please note that because this is a beta release (the first one at that), there
may likely be bugs or functionality that will be polished over the next betas
prior to release. But we encourage everyone to provide feedback so that we may
address any issues.

Also note that some of the documentation for the new features is also in beta
and undergoing revision and completion over the next few weeks. In particular
the cross model relations documentation is still in development.

## New and Improved

### FAN networking in containers (initial support)

A new "container-networking-method" model config attribute is introduced with 3
possible values: "local", "fan", "provider".
* local = use local bridge lxdbr0
* provider = containers get their IP address from the cloud via DHCP
* fan = use FAN

The default is to use "provider" if supported. Otherwise, if FAN is configured
use that, else "local".
On AWS, FAN works out of the box. For other clouds, a new fan-config model
option needs to be used, eg

juju model-config fan-config="= =

### Update application series

It's now possible to update the underlying OS series associated with an already
deployed application.

juju update-series  

will ensure that any new units deployed will now use the requested series.

juju update-series  

will inform the charms already deployed to the machine that the OS series has
been changed and they should re-configure accordingly. This requires charm
support and for the underlying OS to be upgraded manually beforehand.

For more detail, see the documentation
https://jujucharms.com/docs/devel/howto-updateseries

### Cross model relations

This feature allows workloads to be deployed and related across models, and even
across controllers. Note that some charms such as postgresql, prometheus (and
others) need to be updated to be cross model compatible - this work is underway.

For more detail, see the beta documentation
https://jujucharms.com/docs/devel/models-cmr/

*Note: this cross model relations documentaion is also still in beta and is
incomplete.*

### LXD storage provider

Juju storage is now supported by the LXD local cloud. The available storage
options include:
- lxd (default, directory based)
- btrfs
- zfs

For more detail, see the documentation
https://jujucharms.com/docs/devel/charms-storage#lxd-(lxd)

### Persistent storage management

Storage can be detached and reattached from/to units without losing the data on
that storage. The supported scenarios include:
- explicit detach / attach while the units are still active
- retain storage when a unit or application is destroyed
- retain storage when a model is destroyed
- deploy a charm using previously detached storage

The default behaviour now is to retain storage, unless destroy has explicitly
been requested when running the command.

Storage which is retained can then be reattached to a different unit. Filesystem
storage can be imported into a different model, from where it can be attached to
units in that model, or used when deploying a new charm.

For more detail, see the documentation
https://jujucharms.com/docs/devel/charms-storage


## Fixes

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

Some important fixes include:

* can't bootstrap openstack if nova and neutron AZs differ
https://bugs.launchpad.net/juju/+bug/1689683
* cache vSphere images in datastore to avoid repeated downloads
https://bugs.launchpad.net/juju/+bug/1711019
* juju run-action can be run on multiple units
https://bugs.launchpad.net/juju/+bug/1667213


## 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 --beta --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 juju@lists.ubuntu.com.


## More information

To learn more about juju please visit https://jujucharms.com.

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

Juju 2.3 beta1 is here!

[Ian Booth]

After many months of effort, we're pleased to announce the release of the first
beta for the upcoming Juju 2.3 release. This release has many long requested new
features, some of which are highlighted below.

Please note that because this is a beta release (the first one at that), there
may likely be bugs or functionality that will be polished over the next betas
prior to release. But we encourage everyone to provide feedback so that we may
address any issues.

Also note that some of the documentation for the new features is also in beta
and undergoing revision and completion over the next few weeks. In particular
the cross model relations documentation is still in development.

## New and Improved

### FAN networking in containers (initial support)

A new "container-networking-method" model config attribute is introduced with 3
possible values: "local", "fan", "provider".
* local = use local bridge lxdbr0
* provider = containers get their IP address from the cloud via DHCP
* fan = use FAN

The default is to use "provider" if supported. Otherwise, if FAN is configured
use that, else "local".
On AWS, FAN works out of the box. For other clouds, a new fan-config model
option needs to be used, eg

juju model-config fan-config="= =

### Update application series

It's now possible to update the underlying OS series associated with an already
deployed application.

juju update-series  

will ensure that any new units deployed will now use the requested series.

juju update-series  

will inform the charms already deployed to the machine that the OS series has
been changed and they should re-configure accordingly. This requires charm
support and for the underlying OS to be upgraded manually beforehand.

For more detail, see the documentation
https://jujucharms.com/docs/devel/howto-updateseries

### Cross model relations

This feature allows workloads to be deployed and related across models, and even
across controllers. Note that some charms such as postgresql, prometheus (and
others) need to be updated to be cross model compatible - this work is underway.

For more detail, see the beta documentation
https://jujucharms.com/docs/devel/models-cmr/

*Note: this cross model relations documentaion is also still in beta and is
incomplete.*

### LXD storage provider

Juju storage is now supported by the LXD local cloud. The available storage
options include:
- lxd (default, directory based)
- btrfs
- zfs

For more detail, see the documentation
https://jujucharms.com/docs/devel/charms-storage#lxd-(lxd)

### Persistent storage management

Storage can be detached and reattached from/to units without losing the data on
that storage. The supported scenarios include:
- explicit detach / attach while the units are still active
- retain storage when a unit or application is destroyed
- retain storage when a model is destroyed
- deploy a charm using previously detached storage

The default behaviour now is to retain storage, unless destroy has explicitly
been requested when running the command.

Storage which is retained can then be reattached to a different unit. Filesystem
storage can be imported into a different model, from where it can be attached to
units in that model, or used when deploying a new charm.

For more detail, see the documentation
https://jujucharms.com/docs/devel/charms-storage


## Fixes

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

Some important fixes include:

* can't bootstrap openstack if nova and neutron AZs differ
https://bugs.launchpad.net/juju/+bug/1689683
* cache vSphere images in datastore to avoid repeated downloads
https://bugs.launchpad.net/juju/+bug/1711019
* juju run-action can be run on multiple units
https://bugs.launchpad.net/juju/+bug/1667213


## 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 --beta --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

"Attempting to connect to" takes a long time

[fengxia]

Hi Juju,

Boostrapping a local LXD controller, it sits at "Attempting to connect 
to..." for a good 5-10 minutes. Any idea what it is doing, and how to 
speed it up?


_

Host: Ubuntu 16.04

Juju: 2.2.4-xenial-amd64

CLI: juju bootstrap localhost devlocal

Output:

Please either create a new controller using "juju bootstrap" or connect to
another controller that you have been given access to using "juju register".

Creating Juju controller "c6k37aysz8" on localhost/localhost
Looking for packaged Juju agent version 2.2.4 for amd64
To configure your system to better support LXD containers, please see: 
https://github.com/lxc/lxd/blob/master/doc/production-setup.md

Launching controller instance(s) on localhost/localhost...
 - juju-4a20f8-0 (arch=amd64)
Fetching Juju GUI 2.9.2
Waiting for address
Attempting to connect to 10.175.135.202:22


--
Feng Xia

Advisory Engineer
Datacenter Group (DCG), Lenovo US
8000 Development Dr, Morrisiville, NC 27509
W: http://www.lenovo.com


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

RE: Private Icons for a charm.

[Michael Van Der Beek]

Hi Francesco,

Yup looks like the bug.

Just to give you some details of my test openstack setup so for more test 
scenarios.
Openstack is setup based on packstack on a single 128G ram server. Running 
Centos7
Juju (cli) instance using ubuntu
Then juju creates the controller on this openstack.
I run simplestreams to load centos7 images and I'm writing centos charms.

The reason, is because I am porting my company products (running on centos) to 
cloud images.

juju version
2.2.4-xenial-amd64
OS=ubuntu 16.04

Thanks for your pointer.

Regards,

Michael



-Original Message-
From: Francesco Banconi [mailto:francesco.banc...@canonical.com] 
Sent: Thursday, October 5, 2017 7:55 PM
To: Merlijn Sebrechts 
Cc: Michael Van Der Beek ; juju@lists.ubuntu.com
Subject: Re: Private Icons for a charm.

> 
> On 5 Oct 2017, at 10:24, Merlijn Sebrechts  
> wrote:
> 
> If use this url in a browser it works it brings up the icon. But in the juju 
> webgui it shows up a generic icon.

Thanks for reporting this issue! This seems to be an instance of 
https://github.com/juju/juju-gui/issues/3067
It is possible to confirm that by trying to load the GUI with Firefox, for 
instance, as only Chrome is affected by the problem.
We are currently investigating possible solutions.

--
Francesco

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

Re: set_state not setting the state immediately

[fengxia]

" An assumption is being made that the state changes get committed
immediately, but these changes are actually transactional and
following the same transactional behaviour as the Juju hook
environment [1]."

To chip in my experience as 6-month into learning charms and writing a 
few simple charms.


1. The "transactional" nature of Juju hook needs better explained. To be 
honest I have no idea what this means, and what implication it has to a 
charm writer. Any reference would be helpful.


2. I like Mike Wilson's approach to provide a list of "set_state_xxx" 
functions so new writer can better guess what this function will do. 
Further, a different name calls for further study why they are 
different, thus learning important concept of whatever Juju thinks charm 
writer needs to understand.


Otherwise, I will expect "set_state" will set that state/flag asap. If 
there is a scanning cycle (which I heard there is some kind of 5-min 
cycle, which document has not sufficiently made it clear to a writer 
either), charm writer needs to have better doc to learn what it means 
for design. I came from embedded system world in which a timer loop is 
common. It calls for a different thinking than user space script user. I 
think such implication should be emphasized more.


3. idempotent

Again, this is a concept me (or many new writer) will fail to grasp. 
Looking at "apt install" as example, my reaction was that the package 
manager is taking care of "doing nothing" if called multiple times. But 
how this translate to my system in which charm is expected to "do 
something"? Does it mean I need a gatekeeper like the package manager so 
to guard these "multiple calls"?


Again, this feels like a work around because "set_state" will call the 
same function block multiple times, which is unintuitive to writer -- 
when I set a state, the action for that state is executed once, not over 
and over again until I turn it off. Further, even "remove_state" doesn't 
take effect immediately, so it feels arbitrary how many cycles a block 
of code is executed. This is a design pattern I'm afraid many are not 
familiar with, so some tutorial examples will be much appreciated.


Best,

Feng




On 10/04/2017 08:59 AM, Marco Ceppi wrote:
So, I've not actually checked the logs in a while, but if visibility 
is an issue, it seems reasonable that the reactive framework should 
print in the log that X flags are being reset due to hook failure. 
Things like set_flag_immediate has farther reaching consequences than 
simply stating that flags only get set on success of a hook run.


I know there are further reaching initiatives to alleviate this by 
decoupling the reactive state engine from the juju hooks system. In 
this case each successive loop of the reactive runtime could better 
snapshot state and make failures more granular.


* state is being renamed to flag in the next major version of reactive.

On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson > wrote:


So as a new charm writer coming to Juju I would first do this:

def get_ready():
    func0()
    func1_fails()

Then I would, hopefully, test and notice issues. I would
investigate and see that I needed to be idempotent. My next
attempt would be to wrap those functions inside state checks with
sets after they complete. This would also fail and now the charm
creator is left with nothing in the api that can help. They are
now off to their own devices to start doing random things to
attempt to make this work the way they want it to work. Hopefully,
the solution is as straight-forward as touching random files, but
we just never know.

I would expect the name of set_state to be something like
set_state_on_success and I would further expect some sort of
immediate state thing like set_state or set_state_immediate. This
would give the user the tools we know that they need in order to
create bug-free charms.

Now to compound that confusion, we have the issue of a hook can
call multiple functions inside the charm code and if any of those
functions have something that fails the whole thing is unwrapped.
I understand from a Juju perspective why this is the case, but as
a user, I would be completely taken by surprise here. The only
real fix here is documentation so that we can set expectations,
but people will most likely look at examples instead of
documentation. This means that we need to make sure to call out
any potential issues like this in the example charms we release.


On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop
>
wrote:

On 4 October 2017 at 00:51, Mike Wilson
>
wrote:
> So the best practice here is to touch a file and test for
the existence 

Re: upgrade-charm hook

[sheila miguez]

I'd like something like this.

The layer-snap's upgrade-hook cycle calls code[1] that checks for a
non-zero resource, and then checks whether that resource has changed. I bet
many charmers do this, and it would be useful to have a decorator that does
it for us.


[1]
https://github.com/stub42/layer-snap/blob/master/lib/charms/layer/snap.py#L53




On Tue, Sep 26, 2017 at 9:51 AM, James Beedy  wrote:

> That totally does! This sounds like a great path forward that would allow
> us to eventually migrate away from having 'upgrade-charm' fire when a
> resource is attached, while maintaining backward compat for the charms that
> use it until its deprecated.
>
> Well  I didn't mean to just imply that things should change to this ^
> way, but it seems sensible. Possibly we could have more of a conversation
> around this?
>
> ~James
>
>
>
> On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Does a `resource.changed` flag address your needs? That should be
>> possible to implement in charms.reactive, I think.
>>
>> 2017-09-24 17:53 GMT+02:00 James Beedy :
>>
>>> How do people feel about splitting the upgrade-charm hook into multiple
>>> hooks to facilitate better resource management?
>>>
>>> What I'm thinking would be super helpful would be to have the
>>> upgrade-charm hook still active for charm upgrades, and have separate hooks
>>> or flags that would indicate resource upgrades.
>>>
>>> I'm thinking something like:
>>>
>>> 'juju attach myapp myresource=myresource.file'
>>>
>>> Would cause the 'upgrade-resource-myresource'  hook to become active on
>>> instances of 'myapp'.
>>>
>>> I feel that having this affinity from resource ->
>>> resource-upgrade- hook would be a huge win for resource
>>> management.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


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

charms.reactive 0.5.0

[Cory Johns]

Greetings,

Today we released version 0.5.0 of charms.reactive.  The full changelog can
be found at https://charmsreactive.readthedocs.io/en/latest/changelog.html
with the changes from this release being:

  * Add flag triggers (#121)
  * Add integration test to Travis to build and deploy a reactive charm
(#120)
  * Only execute matching hooks in restricted context. (#119)
  * Rename "state" to "flag" and deprecate "state" name (#112)
  * Allow pluggable alternatives to RelationBase (#111)

We will be exclusively using the "flags" terminology going forward in place
of "states" as the former is more accurate to what they represent and how
they behave and is less confusing.  For the time being, all of the existing
"state" functions are still available, but they are deprecated.  See
https://charmsreactive.readthedocs.io/en/latest/charms.reactive.flags.html
for more info.

The "pluggable alternatives to RelationBase" is groundwork for the upcoming
Endpoints replacement, which should make writing interface layers
significantly less confusing.  Feedback welcome on
https://github.com/juju-solutions/charms.reactive/pull/123 and
https://github.com/juju/docs/pull/2207
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: vsphere support

[Andrew Wilkins]

On Wed, Oct 4, 2017 at 12:09 PM Serge E. Hallyn  wrote:

> Hi,
>
> I've inherited a few vsphere machines where I was hoping to use juju
> to fire off openstack etc.  I've been trying to use the vsphere
> provider (which I was excited to see existed), but am seeing a few
> inconsistencies, so had a few questions.
>
> The first blunt question - is this going to be a maintained driver,
> or am I in 6 months likely to find the vsphere driver dropped?
>

We are actively working on making the vsphere provider to be a great
experience in the Juju 2.3 release. There's some more work to be done for
mirroring VMDKs from cloud-images, but otherwise I think everything's
working well now.

I don't have any reason to believe that we would drop the provider, or to
reduce focus on quality. People seem to want it :)

The second is motivating the first - when I looked at
> https://jujucharms.com/docs/2.1/help-vmware it says hardware version
> 8 (ESX 5.0) should be sufficient.  But in fact juju has a ubuntu.ovf
> hardcoded in it that specifies 'vmx-10', which is ESX 5.5..  I currently
> have 5 ESX 5.1 machines and one 6.0.
>

To my knowledge, Juju has only been tested with ESXi 5.5 and 6.0. In terms
of hardware support, version 8 seems like it should be sufficient. I'm not
sure about the APIs we're using, but we don't use a lot, so it wouldn't
surprise me if ESXi 5.1 just works.

If you're able to tweak the OVF and build Juju from source, that would be a
great help. Otherwise I will check what we require in terms of APIs when I
return from vacation next week - and try it out and report back. If it
works, then we can look to update the OVF for Juju 2.3.

Even with a custom DC using only the 6.0 host, I have some (probably
> proxy) issues bootstrapping, which I'm sure are surmountable - but the
> answer to Q1 will decide whether it's worth pursuing that further, or
> whether I should spend my time elsewhere :)
>

Please file a bug if you're still having issues. Juju 2.3 beta 1 is
imminent, so please use that if you can.

Cheers,
Andrew

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

Re: Private Icons for a charm.

[Francesco Banconi]

> 
> On 5 Oct 2017, at 10:24, Merlijn Sebrechts  
> wrote:
> 
> If use this url in a browser it works it brings up the icon. But in the juju 
> webgui it shows up a generic icon.

Thanks for reporting this issue! This seems to be an instance of 
https://github.com/juju/juju-gui/issues/3067
It is possible to confirm that by trying to load the GUI with Firefox, for 
instance, as only Chrome is affected by the problem.
We are currently investigating possible solutions.

--
Francesco

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

Re: What is the best way to work with multiple models in a controller using the cli?

[Akshat Jiwan Sharma]

Thanks a lot Ian!

On Thu, Oct 5, 2017 at 1:22 PM, Ian Booth  wrote:

> Hey
>
> The -m argument is what you want. It accepts wither just a model name or a
> controller:model for when you have multiple controllers. eg
>
> $ juju status -m prod
> $ juju status -m ctrl:prod
>
> The first command above works on the prod model on the current controller.
> The
> second selects a specific controller regardless of the current one. The
> second
> way is the safest unless you really are only using one controller.
>
> Also, you can set the JUJU_MODEL env var. That's useful for when you open
> different terminal windows and want to work on a different model in each
> window
> without using -m each time.
>
> On 05/10/17 17:43, Akshat Jiwan Sharma wrote:
> > Hi,
> >
> > I have deployed a few models using the local juju controller and I want
> > to execute a bunch of commands on a particular model using the juju-cli.
> >
> > Lets say I have these three models defined on my controller
> >
> > - model1
> > - model2
> > - model3
> >
> > This is the sequence of commands I want to run
> >
> > 1. List all the machines in model1
> > 2. Add storage unit to model2
> > 3. Add a relation between applications in model3
> >
> > These operations may be run in any order. That is first I might run op 2
> > then op 3 and then op1.
> > The only constraint is that an operation must be run on a particular
> model.
> > Right now I go about this task like so:-
> >
> > juju switch model1 && juju machines
> >
> >  This works fine. I get all my machines listed for model1. The problem
> with
> > this  approach is that I'm not sure if
> > another command is executing a juju switch somewhere and suddenly the
> model
> > I'm operating changes from model1 to model2.
> >
> > For instance suppose that these two commands are run one after the other
> >
> > juju switch model1 && juju list machines
> > juju switch model3 && juju add-relation app1 app2
> >
> > Now how can I be certain that for second command I'm operating on model
> 3?
> > As far as I understand juju switches are global.
> > Meaning a `switch` makes a change "permanent" to all the other commands
> > that follow.
> >
> > My question is how do I "lock" the execution of a certain command to a
> > particular model?
> >
> > Thanks,
> > Akshat
> >
> >
> >
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What is the best way to work with multiple models in a controller using the cli?

[Ian Booth]

Hey

The -m argument is what you want. It accepts wither just a model name or a
controller:model for when you have multiple controllers. eg

$ juju status -m prod
$ juju status -m ctrl:prod

The first command above works on the prod model on the current controller. The
second selects a specific controller regardless of the current one. The second
way is the safest unless you really are only using one controller.

Also, you can set the JUJU_MODEL env var. That's useful for when you open
different terminal windows and want to work on a different model in each window
without using -m each time.

On 05/10/17 17:43, Akshat Jiwan Sharma wrote:
> Hi,
> 
> I have deployed a few models using the local juju controller and I want
> to execute a bunch of commands on a particular model using the juju-cli.
> 
> Lets say I have these three models defined on my controller
> 
> - model1
> - model2
> - model3
> 
> This is the sequence of commands I want to run
> 
> 1. List all the machines in model1
> 2. Add storage unit to model2
> 3. Add a relation between applications in model3
> 
> These operations may be run in any order. That is first I might run op 2
> then op 3 and then op1.
> The only constraint is that an operation must be run on a particular model.
> Right now I go about this task like so:-
> 
> juju switch model1 && juju machines
> 
>  This works fine. I get all my machines listed for model1. The problem with
> this  approach is that I'm not sure if
> another command is executing a juju switch somewhere and suddenly the model
> I'm operating changes from model1 to model2.
> 
> For instance suppose that these two commands are run one after the other
> 
> juju switch model1 && juju list machines
> juju switch model3 && juju add-relation app1 app2
> 
> Now how can I be certain that for second command I'm operating on model 3?
> As far as I understand juju switches are global.
> Meaning a `switch` makes a change "permanent" to all the other commands
> that follow.
> 
> My question is how do I "lock" the execution of a certain command to a
> particular model?
> 
> Thanks,
> Akshat
> 
> 
> 

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

What is the best way to work with multiple models in a controller using the cli?

[Akshat Jiwan Sharma]

Hi,

I have deployed a few models using the local juju controller and I want
to execute a bunch of commands on a particular model using the juju-cli.

Lets say I have these three models defined on my controller

- model1
- model2
- model3

This is the sequence of commands I want to run

1. List all the machines in model1
2. Add storage unit to model2
3. Add a relation between applications in model3

These operations may be run in any order. That is first I might run op 2
then op 3 and then op1.
The only constraint is that an operation must be run on a particular model.
Right now I go about this task like so:-

juju switch model1 && juju machines

 This works fine. I get all my machines listed for model1. The problem with
this  approach is that I'm not sure if
another command is executing a juju switch somewhere and suddenly the model
I'm operating changes from model1 to model2.

For instance suppose that these two commands are run one after the other

juju switch model1 && juju list machines
juju switch model3 && juju add-relation app1 app2

Now how can I be certain that for second command I'm operating on model 3?
As far as I understand juju switches are global.
Meaning a `switch` makes a change "permanent" to all the other commands
that follow.

My question is how do I "lock" the execution of a certain command to a
particular model?

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