Re: Juju 2.4.0 has been released

[Rick Harding]

Sorry, after hitting send I woke up some more and realized what you're
asking. Only the Juju client on your machine is in the snap. The controller
and models need to be manually upgraded. We don't deliver those and auto
upgrade them as a snap.

The proper upgrade doc for the 2.4.0 series is here:
https://docs.jujucharms.com/2.4/en/models-upgrade

Start with the controller and you should be good to go.

On Tue, Jul 3, 2018 at 7:34 AM Rick Harding 
wrote:

> On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
> bogdan.kowalc...@canonical.com> wrote:
>
>> Thanks Vinodhin
>>
>> I just installed juju from snap and wanted to test couple of deployments.
>>
>> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>>
>
> Is this on an existing deployment? If this controller was already up then
> you'll need to make sure to upgrade the controller.
>
> Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for
> assistance.
>
> Rick
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.4.0 has been released

[Rick Harding]

Sorry, after hitting send I woke up some more and realized what you're
asking. Only the Juju client on your machine is in the snap. The controller
and models need to be manually upgraded. We don't deliver those and auto
upgrade them as a snap.

The proper upgrade doc for the 2.4.0 series is here:
https://docs.jujucharms.com/2.4/en/models-upgrade

Start with the controller and you should be good to go.

On Tue, Jul 3, 2018 at 7:34 AM Rick Harding 
wrote:

> On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
> bogdan.kowalc...@canonical.com> wrote:
>
>> Thanks Vinodhin
>>
>> I just installed juju from snap and wanted to test couple of deployments.
>>
>> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>>
>
> Is this on an existing deployment? If this controller was already up then
> you'll need to make sure to upgrade the controller.
>
> Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for
> assistance.
>
> Rick
>
-- 
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.4.0 has been released

[Rick Harding]

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
bogdan.kowalc...@canonical.com> wrote:

> Thanks Vinodhin
>
> I just installed juju from snap and wanted to test couple of deployments.
>
> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>

Is this on an existing deployment? If this controller was already up then
you'll need to make sure to upgrade the controller.

Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for assistance.

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

Re: Juju 2.4.0 has been released

[Rick Harding]

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
bogdan.kowalc...@canonical.com> wrote:

> Thanks Vinodhin
>
> I just installed juju from snap and wanted to test couple of deployments.
>
> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>

Is this on an existing deployment? If this controller was already up then
you'll need to make sure to upgrade the controller.

Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for assistance.

Rick
-- 
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.4-rc2 has been released

[Rick Harding]

I want to make sure it's clear that this is the last exected RC release. If
no issues are found in testing from the community we plan on a final
release next week. Please give it a spin attempt to crush it for all your
worth!

Thanks!

On Mon, Jun 18, 2018 at 6:36 PM Chris Lee 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *A new development release of Juju is here, 2.4-rc2.## Fixes - A bug
> introduced in RC1 for the Oracle and Joyent providers has been
> corrected.For a list of all bugs fixed in this release,
> seehttps://launchpad.net/juju/+milestone/2.4-rc2
> ## 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). sudo snap install juju --classic --candidateOther 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 amessage on Twitter using #jujucharms, join us at #juju on
> freenode, and subscribe to the mailing list at juju@lists.ubuntu.com
> .## More informationTo learn more about juju please
> visit https://jujucharms.com .*
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.4-rc2 has been released

[Rick Harding]

I want to make sure it's clear that this is the last exected RC release. If
no issues are found in testing from the community we plan on a final
release next week. Please give it a spin attempt to crush it for all your
worth!

Thanks!

On Mon, Jun 18, 2018 at 6:36 PM Chris Lee 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *A new development release of Juju is here, 2.4-rc2.## Fixes - A bug
> introduced in RC1 for the Oracle and Joyent providers has been
> corrected.For a list of all bugs fixed in this release,
> seehttps://launchpad.net/juju/+milestone/2.4-rc2
> ## 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). sudo snap install juju --classic --candidateOther 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 amessage on Twitter using #jujucharms, join us at #juju on
> freenode, and subscribe to the mailing list at j...@lists.ubuntu.com
> .## More informationTo 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: adding nics to a vm in vmware built by juju deploy

[Rick Harding]

I'm not familiar if there's any way to unlock/force through VMWare but Juju
doesn't currently support the idea of adding nics to running instances at
this moment. It's something we're definitely looking for the future as
clouds do support things like hot plugging nics. It might be worth a test
to see if you can adjust the nics on the VMWare side. In some cases you can
work around Juju like adding storage to the root disk by upgrading the
instance through the cloud tooling.

On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell  wrote:

> I have a vmware server that I am using as the target for deploying vms
> with juju.  I have a set of vms that need multiple nics on different
> vlans/vmware networks.  I want the vm to be on the primary network, but
> also have nics for 4 other secondary networks.
>
> Once the vm is deployed, vmware considers it locked and will not let me
> add additional nics.  Is there a way to unlock it?  Or is there a way
> to deploy the vm with the nics installed from the start?
>
> I didn't see anything in the online docs about adding additional
> networks to the constraints clause of the deploy.  If this feature is
> not available at this time, could it be considered for the future?
> --
> Daniel Bidwell 
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: adding nics to a vm in vmware built by juju deploy

[Rick Harding]

I'm not familiar if there's any way to unlock/force through VMWare but Juju
doesn't currently support the idea of adding nics to running instances at
this moment. It's something we're definitely looking for the future as
clouds do support things like hot plugging nics. It might be worth a test
to see if you can adjust the nics on the VMWare side. In some cases you can
work around Juju like adding storage to the root disk by upgrading the
instance through the cloud tooling.

On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell  wrote:

> I have a vmware server that I am using as the target for deploying vms
> with juju.  I have a set of vms that need multiple nics on different
> vlans/vmware networks.  I want the vm to be on the primary network, but
> also have nics for 4 other secondary networks.
>
> Once the vm is deployed, vmware considers it locked and will not let me
> add additional nics.  Is there a way to unlock it?  Or is there a way
> to deploy the vm with the nics installed from the start?
>
> I didn't see anything in the online docs about adding additional
> networks to the constraints clause of the deploy.  If this feature is
> not available at this time, could it be considered for the future?
> --
> Daniel Bidwell 
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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

Re: How do you clean a juju disk or make it larger?

[Rick Harding]

Thanks for the added detail Daniel. Glad you got the resize worked out.

On Wed, Jun 13, 2018 at 9:36 AM Daniel Bidwell  wrote:

> My case was using VmWare as the cloud.  The controllers defaulted to
> 10GB.  I am running juju 2.3.8.  I have about 12 vm's on the controller
> with about 24 locally written charms.  /var/lib/juju/db is currently
> using 8.3GB.
>
> The simplest solution for me was to increase the root disk size and
> reboot the controller.  The cloud-init process resized the partition to
> fill the rest of the disk and then resized the file system to fill the
> enlarged partition.
>
> I am not concerned about the size so much as I needed to finish
> deploying my spread of servers.
>
> I did clean out a group of old kernels that had accumulated as well as
> old versions of juju that I had upgraded from, but those were
> incidental.
>
> I posted the question and solution to askubuntu.com so others could
> find the answer easily if they hit the same problem.
>
> On Wed, 2018-06-13 at 16:06 +0400, John Meinel wrote:
> > IIRC older Juju used the default EC2 settings, which gave 8GB hard
> > drives, but newer should default to 32GB disks. I'm not sure how that
> > varies across all providers, though.
> >
> > Note that you should always be able to bootstrap with a custom root-
> > disk constraint. eg "juju bootstrap --bootstrap-constraints root-
> > disk=32G"
> >
> > As for issues about the disk filling up, it would be good to have a
> > bit more information about what juju version, what types of workloads
> > you're deploying, etc. The data might be stale charm binaries that
> > are being cached by the server, or if it is Juju 1.X then it could be
> > image caches, or transaction log issues, etc.
> >
> > John
> > =:->
> >
> > On Tue, Jun 12, 2018 at 9:12 AM, Paul Gear 
> > wrote:
> > > On 11/06/18 01:47, Daniel Bidwell wrote:
> > > > My juju controllers appear to be defaulting to a 10GB root disk.
> > > I am
> > > > running out of disk space on the controller. I have 6.7GB in
> > > > /var/lib/juju/db. Is there a way to reduce the disk usage on
> > > this?
> > >
> > > I think perhaps this is worth logging as a wishlist bug. A long-
> > > running
> > > production juju controller should never be deployed with a disk
> > > that
> > > small (our largest production cluster is already a little
> > > uncomfortable
> > > with 50 GB), and juju doesn't really distinguish between "this is a
> > > CI
> > > controller that's only going to be up long enough to run my test
> > > suite"
> > > and "this is going to run all of my production OpenStack VMs for
> > > the
> > > next year". It would be nice if you could tell it "size the
> > > controller
> > > for N live models".
> > >
> > > > If not, can I make the root disk larger? What are my options?
> > >
> > > That all depends on your underlying cloud infrastructure.  I
> > > believe
> > > some providers (e.g. GCE) make this really easy.
> > >
> > > > I have already cleared out kernel updates.
> > >
> > > Not directly related to juju controller sizing, but relevant to the
> > > above: I've been working on a little tool that handles many of the
> > > common scenarios we encounter, including kernel updates and other
> > > tools
> > > you may or may not use.  It's alpha quality; feedback & patches
> > > gratefully accepted:
> > >
> > > https://code.launchpad.net/~paulgear/+git/cleanup
> > >
> > > --
> > > Regards,
> > > Paul Gear
> > > Site Reliability Engineer
> > > Canonical - Information Systems
> > >
> > >
> > > --
> > > Juju mailing list
> > > Juju@lists.ubuntu.com
> > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
> > > /listinfo/juju
> > >
> --
> Daniel Bidwell 
>
>
> --
> 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: Juju 2.4-rc1 Released

[Rick Harding]

Not yet. This enables bootstrapping on a clustered lxd that's also
localhost. It's a step toward making Juju aware of the clustering APIs but
does not yet enable the work of adding a remote lxd cloud. I showed this in
last week's Juju show.

https://youtu.be/CidoBy3iqUw

On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi  wrote:

> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>
>>
>>
>>
>>
>> *A new development release of Juju is here, 2.4-rc1.## New and Improved -
>> LXD functionality has been updated to support version 3 of LXD. Better
>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>> LXD by default if it is present. Initial support for LXD clustering is
>> available under constrained conditions:*
>>
>
> Does this mean that I can bootstrap a remote LXD cluster now?
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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

Re: Juju 2.4-rc1 Released

[Rick Harding]

Not yet. This enables bootstrapping on a clustered lxd that's also
localhost. It's a step toward making Juju aware of the clustering APIs but
does not yet enable the work of adding a remote lxd cloud. I showed this in
last week's Juju show.

https://youtu.be/CidoBy3iqUw

On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi  wrote:

> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>
>>
>>
>>
>>
>> *A new development release of Juju is here, 2.4-rc1.## New and Improved -
>> LXD functionality has been updated to support version 3 of LXD. Better
>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>> LXD by default if it is present. Initial support for LXD clustering is
>> available under constrained conditions:*
>>
>
> Does this mean that I can bootstrap a remote LXD cluster now?
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju 2.4-beta2 released

[Rick Harding]

A new development release of Juju is here, 2.4-beta2.

## New and Improved

* HA improvements and fixes

* New controller time added to status output

## Fixes

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

Some important fixes include:


#1764317 bionic LXD containers on bionic hosts get incorrect
/etc/resolve.conf files

#1765571 lxd container fails to launch on bionic host: No associated target
operation

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

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

Re: SSH to machines from add-user

[Rick Harding]

I worked with Tom on this in IRC and got to the bottom of it. We hit a
corner case of the superuser. The folks that own the controller themselves
are a bit special. While technically they're the boss and can juju status
any model in the controller, they don't see all the models by default in
juju models and the like. It'd make being the controller admins a real
pain.

Likewise, we don't auto add the ssh key of every superuser to every machine
in every model regardless of the owner. We take the tact that supserusers
can sudo around and do anything, but by default commands only allow them to
do things on models they've been given model level access to directly.

Tom was setting up a controller, adding a user, and granting them superuser
on the controller. However, as the user had no direct share/access to the
model in question it could not ssh to the machines in the model.

I think we can be more clear here around the error messaging as we know the
user is a superuser and why the request failed.

On Fri, May 11, 2018 at 6:11 AM Tom Barber  wrote:

> Hello folks
>
> IRC has failed me so lets try the wider world.
>
> We have a multinode manual cloud deployed. We have juju add-user 2 new
> users and also juju add-ssh-key for those users.
>
> We know the ssh key works because
>
> ssh ubuntu@
>
> works fine and we can sudo -i etc and do stuff.
>
> But
>
> juju ssh 
>
> says:
>
> ERROR permission denied (unauthorized access)
> 11:05:18 DEBUG cmd supercommand.go:459 error stack:
> permission denied (unauthorized access)
> github.com/juju/juju/rpc/client.go:149:
> github.com/juju/juju/api/apiclient.go:924:
> github.com/juju/juju/api/sshclient/facade.go:109:
> github.com/juju/juju/cmd/juju/commands/ssh_common.go:257:
> github.com/juju/juju/cmd/juju/commands/ssh_common.go:141:
> github.com/juju/juju/cmd/juju/commands/ssh.go:117:
>
> I've looked at the code and it claims we can
>
> juju ssh ubuntu@ -i 
>
> that fails with the same error.
>
> If I tail the target servers auth.log there isn't even a failed login
> attempt which strikes me as a little weird considering it says
>
> permission denied (unauthorized access)
>
> Which does make me question... what permission is denied?
>
>
> --
>
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
>
>
> All engagements
> are subject to Spicule Terms and Conditions of Business. This email and
> its
> contents are intended solely for the individual to whom it is addressed
> and
> may contain information that is confidential, privileged or otherwise
> protected from disclosure, distributing or copying. Any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Spicule Limited. The company accepts no
> liability for any damage caused by any virus transmitted by this email. If
> you have received this message in error, please notify us immediately by
> reply email before deleting it from your system. Service of legal notice
> cannot be effected on Spicule Limited by email.
>
> --
> 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

juju show k8s live upgrade and awesome postgresql blog posts

[Rick Harding]

I wanted to make sure folks saw the latest Juju Show [1] as we had Marco
doing a live upgrade of a Kubernetes cluster to 1.10 which was very cool.
It was great to see how smooth it is to keep your cluster up to date with
the smarts in the charms.

I also wanted to call out some really cool blog posts that Stuart's done
around operating Postgres in production. I had missed these and figured I'd
spread the word. He's got a few great posts on point in time backup and
recovery using the built in actions of the charm. [2] There's also a great
one about leveraging Juju storage to be able to redeploy Postgres and pick
back up those persistent disks to restore the data [3], and one on the
cross model relation support. [4]

Make sure to check out those posts and give them a try if you're using
Postgres anywhere. It's great to see more advanced operations being brought
into the charms and I think it's a great model for other folks that might
be looking for the next steps of their own charms beyond deploy and
configuration.

Rick

1: https://www.youtube.com/watch?v=cxAsJpmwDFE
2:
https://stubish.wordpress.com/2017/09/01/postgresql-point-in-time-recovery-with-juju/
3:
https://stubish.wordpress.com/2018/01/17/postgresql-redeploys-with-juju-storage/
4:
https://stubish.wordpress.com/2018/04/09/postgresql-charm-cross-model-support/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

The Juju Show #29 - jujushell in jaas beta, juju-upgrader, more.

[Rick Harding]

In the Juju Show yesterday [1] we talked about beta testing the JujuShell
[2] in JAAS. Please reach out to me with your launchpad username if you're
interested in giving it a spin as we test out the scale needs there.

I also wanted to link to the juju-upgrader tool we went over [3] and the
readme for it [4]. It really is a great tool for assisting in managing your
Juju upgrades across multiple controllers, especially when they contain a
lot of models.

Thanks for everyone that attended the show yesterday!

Rick

1: https://www.youtube.com/watch?v=Pkbp4VK8-vo
2:
https://blog.jujugui.org/2018/01/03/accessing-the-juju-cli-from-within-the-gui/
3: https://launchpad.net/juju-upgrader
4: https://git.launchpad.net/juju-upgrader/tree/README.md
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Statistics and metrics about Charm, layer and interface usage

[Rick Harding]

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the docs
for the API to the charmstore itself. As Adam notes, you can pull down any
file and there's manifest call that lists out the files in the charm. From
there you could probably check if the charm has a layers.yaml and if so
fetch that file, parse it, etc.

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idmetamanifest

On Thu, Jan 25, 2018 at 11:22 AM Adam Collard 
wrote:

> Hi Merlijn,
>
>
> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> I'm writing a Juju-related paper and I'd like to get statistics on Charm,
>> layer and interface usage. Are these publicly available?
>>
>> Related: is there a documented API to get the code of the charms that are
>> available in the charm store?
>>
>
> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/ will
> give you a .zip
> and
>
> GET
> https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/$PATH/$TO/$FILE
> will give you the 'raw' contents.
>
> e.g. curl
> https://api.jujucharms.com/charmstore/v5/postgresql/archive/hooks/install
>
> YMMV,
>
> Adam
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Statistics and metrics about Charm, layer and interface usage

[Rick Harding]

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the docs
for the API to the charmstore itself. As Adam notes, you can pull down any
file and there's manifest call that lists out the files in the charm. From
there you could probably check if the charm has a layers.yaml and if so
fetch that file, parse it, etc.

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idmetamanifest

On Thu, Jan 25, 2018 at 11:22 AM Adam Collard 
wrote:

> Hi Merlijn,
>
>
> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> I'm writing a Juju-related paper and I'd like to get statistics on Charm,
>> layer and interface usage. Are these publicly available?
>>
>> Related: is there a documented API to get the code of the charms that are
>> available in the charm store?
>>
>
> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/ will
> give you a .zip
> and
>
> GET
> https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/$PATH/$TO/$FILE
> will give you the 'raw' contents.
>
> e.g. curl
> https://api.jujucharms.com/charmstore/v5/postgresql/archive/hooks/install
>
> YMMV,
>
> Adam
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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

Re: Testing the mail list

[Rick Harding]

We're here. I think that the holiday break had a big quiet period. I know
there's an upcoming 2.3 update in the wings and I'm sure folks will be back
to doing great stuff with Juju as the break time wears off.

On Thu, Jan 11, 2018 at 11:56 AM Micheal B  wrote:

> Have not seen an email from the list for a while.
> --
> 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: Deploying a charm with t's & c's

[Rick Harding]

Just a heads up that the upgrade issues have been worked out and all of the
JAAS controllers are confirmed to be at 2.2.6. We'll be looking at updating
to 2.3.1 in the near future.

On Mon, Dec 4, 2017 at 1:20 PM Tom Barber <t...@spicule.co.uk> wrote:

> Thanks chaps,
>
> I'll try elsewhere.
>
>
> Tom
>
>
> On 04/12/17 18:17, Rick Harding wrote:
>
> Thanks for this Tom, for some reason the controller in the region there
> isn't running 2.2.6, we're looking into it and will try to get it updated
> as soon as possible.
>
> On Mon, Dec 4, 2017 at 9:22 AM Tom Barber <t...@spicule.co.uk> wrote:
>
>> mymodel  jaasaws/us-east-1  2.2.2unsupported
>>
>>
>> Tom
>>
>>
>> On 04/12/17 14:08, Matthew Williams wrote:
>>
>> Hi Tom,
>>
>> What version of the controller are you using (show in juju status). Is
>> this your own controller or are you using jimm?
>>
>> Thanks
>>
>> Matty
>>
>> On Mon, Dec 4, 2017 at 10:33 AM, Tom Barber <t...@spicule.co.uk> wrote:
>>
>>> Hi Casey
>>>
>>> https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB As you'll see here.
>>> #45 works for me also but #47 fails. I don't think we changed anything
>>> massively but clearly something in there is sad, the problem is that, the
>>> error thrown gives me no indication of where we've messed up.
>>>
>>> On a side note I wanted to grab the zip archive of #45 and #47 and do a
>>> diff to see if it was obvious but both give me a 404 from the charm store.
>>>
>>> juju list-agreements
>>> Term Agreed on
>>> isrg-lets-encrypt/2  2017-04-26 09:43:38 + UTC
>>> canonical/sla-terms/32017-08-31 21:19:16 + UTC
>>> spiculecharms/pdi-terms/12017-11-27 23:24:11 + UTC
>>>
>>> Tom
>>>
>>>
>>> On 04/12/17 02:54, Casey Marshall wrote:
>>>
>>> Tom,
>>> With 2.2.6, I cannot reproduce any problems with deploying your charm.
>>> See https://paste.ubuntu.com/26109617/
>>>
>>> Please send me more information about your installation:
>>>
>>> - How you installed Juju (snap, deb from PPA, compiled from source, etc.)
>>> - Platform information on the machine you're running the Juju client on,
>>> OS, etc. Is it on a physical host, in a VM, in a container?
>>> - What cloud you're trying to deploy into
>>>
>>> If you type `juju list-agreements`, does that show terms you've agreed
>>> to?
>>>
>>> -Casey
>>>
>>> On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber <t...@spicule.co.uk> wrote:
>>>
>>>> Just as a quick update, I get the same if I deploy the charm directly
>>>> and from the charm store ie not in a bundle.
>>>>
>>>> But removing the terms in the metadata.yaml removes the error.
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 28/11/17 18:36, Stephen Downie wrote:
>>>>
>>>> Thanks for looking into this Casey. The version of Juju I'm running is
>>>> 2.2.6-xenial-amd64
>>>>
>>>>
>>>> Spicule Ltd
>>>>
>>>> Tel: 01603 327762
>>>>
>>>>
>>>>
>>>> www.spicule.co.uk
>>>>
>>>> On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall <
>>>> casey.marsh...@canonical.com> wrote:
>>>>
>>>>> On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber <t...@spicule.co.uk>
>>>>> wrote:
>>>>>
>>>>>> hey Casey
>>>>>>
>>>>>> if you have no models and try and deploy a bundle with terms it shows
>>>>>> you the deploy screen them hangs. if you go back you see the model with 0
>>>>>> units deployed.
>>>>>>
>>>>>> this is a local bundle we were testing, just exported from the gui,
>>>>>> Ste can provide it if you need it.
>>>>>>
>>>>>
>>>>> Thanks for clarifying. One last question, what version of Juju was
>>>>> used on the command line when trying to deploy the exported bundle?
>>>>>
>>>>>
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> On 28 Nov 2017 6:00 pm, "Casey Marshall" <
>>>>>> casey.marsh...@canonical.com> wrote:
&g

Re: Juju 2.3.0 is here!

[Rick Harding]

Hey, how did you know I was working on a plugin for that :P

I just started poking at the problem of easier management of what version
your controller and models are on and a helper to maas upgrade. I'll reach
out for some testing once it's there.

On Fri, Dec 8, 2017 at 7:22 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Slightly related; is there a way to update _all_ models on a controller
> with one command?
>
> 2017-12-08 10:14 GMT+01:00 Andrew Wilkins :
>
>> On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
>> nicholas.ska...@canonical.com> wrote:
>>
>>> The Juju team are extremely pleased to announce the release of Juju 2.3.
>>> Juju is now more versatile, more efficient, and more configurable than ever.
>>>
>>> Cross Model Relations deliver a new way of organising your software
>>> stack. Deploy a database in one model and connect it to an application
>>> running another, even one running on a different controller, or even a
>>> different cloud.
>>>
>>> For containers at scale, Juju now integrates Canonical's Fan overlay
>>> network system. This allows containers to map network traffic to any other
>>> container on the fan network without distributed databases, consensus
>>> protocols, or any extra overhead.
>>>
>>> Juju's support for bundles has made it possible to quickly deploy
>>> connected sets of applications for some time now, but no two use cases are
>>> the same. That's why we have introduced the concept of an 'overlay' bundle
>>> - now you can easily add your own configuration and tweaks to a bundle at
>>> deploy time. See below for links to more information on this and other key
>>> features.
>>>
>>
>> Hi folks,
>>
>> Unfortunately a critical bug [0] has escaped to the field. This bug
>> affects existing relations in upgraded models. Models created after
>> upgrading, or with a fresh bootstrap, or where relations are created after
>> upgrading, will not be affected.
>>
>> I would not recommend upgrading from 2.x. to 2.3.0. We will be working on
>> a fix for 2.3.1, and I expect this issue will bring that release forward
>> much sooner. If you have already upgraded and are affected, then you can
>> fix it by adding a document to the "statuses" collection in Mongo, as
>> described in the bug.
>>
>> Cheers,
>> Andrew
>>
>> [0] https://bugs.launchpad.net/juju/+bug/1737107
>>
>>
>>>
>>>
>>> ## How can I get it?
>>>
>>>
>>> The best way to get your hands on this release of Juju is to install it
>>> via snap packages (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/2.3/reference-install <
>>> 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.
>>>
>>>
>>> For highlights of this release, please see the documentation at
>>>
>>> https://jujucharms.com/docs/2.3/whats-new. Further details are below.
>>>
>>>
>>>
>>> ## New
>>>
>>>
>>> * Cross Model Relations:
>>>
>>>  - see https://jujucharms.com/docs/2.3/models-cmr
>>>
>>>
>>> * Persistent Storage:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-storage
>>>
>>>
>>> * FAN:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-fan
>>>
>>>
>>> * Bundle deployments:
>>>
>>>  - Changed flags for deploying bundles to existing machines
>>>
>>>  - Bundle deploy flag --bundle-config replaced with --overlay
>>>
>>>  - Deploying bundles now supports --dry-run
>>>
>>>  - Deploying bundles can now target existing machines
>>>
>>>
>>> * Update Application Series:
>>>
>>>  - see https://jujucharms.com/docs/2.3/howto-updateseries
>>>
>>>
>>> * Parallelization of the Machine Provisioner:
>>>
>>> - Groups of machines will now be provisioned in parallel reducing
>>> deployment time, especially on large bundles.
>>>
>>>
>>> * open_port and close_port hook tools now support ICMP
>>>
>>> - The open_port and close_port hook tools now support opening firewall
>>> access for ICMP. The syntax is:
>>>
>>> open_port icmp
>>>
>>>
>>> * LXD Storage Provider:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)
>>>
>>>
>>> ## Fixes
>>>
>>>
>>> * Listing of Juju models is more efficient and can now handle more
>>> models gracefully
>>>
>>> * Leadership coordinations is no longer tied to local time which avoids
>>> problems with clock skew and reduces overall load on the database
>>>
>>> * Models are now more reliably destroyed and several fixes to avoid
>>> negative impacts while they are being removed
>>>
>>>
>>> You can check the milestones for a detailed breakdown of the Juju bugs
>>> we have fixed:
>>>
>>>
>>> https://launchpad.net/juju/+milestone/2.3.0
>>>
>>> https://launchpad.net/juju/+milestone/2.3-rc2
>>>
>>> https://launchpad.net/juju/+milestone/2.3-rc1
>>>
>>> 

Re: Juju 2.3.0 is here!

[Rick Harding]

Hey, how did you know I was working on a plugin for that :P

I just started poking at the problem of easier management of what version
your controller and models are on and a helper to maas upgrade. I'll reach
out for some testing once it's there.

On Fri, Dec 8, 2017 at 7:22 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Slightly related; is there a way to update _all_ models on a controller
> with one command?
>
> 2017-12-08 10:14 GMT+01:00 Andrew Wilkins :
>
>> On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
>> nicholas.ska...@canonical.com> wrote:
>>
>>> The Juju team are extremely pleased to announce the release of Juju 2.3.
>>> Juju is now more versatile, more efficient, and more configurable than ever.
>>>
>>> Cross Model Relations deliver a new way of organising your software
>>> stack. Deploy a database in one model and connect it to an application
>>> running another, even one running on a different controller, or even a
>>> different cloud.
>>>
>>> For containers at scale, Juju now integrates Canonical's Fan overlay
>>> network system. This allows containers to map network traffic to any other
>>> container on the fan network without distributed databases, consensus
>>> protocols, or any extra overhead.
>>>
>>> Juju's support for bundles has made it possible to quickly deploy
>>> connected sets of applications for some time now, but no two use cases are
>>> the same. That's why we have introduced the concept of an 'overlay' bundle
>>> - now you can easily add your own configuration and tweaks to a bundle at
>>> deploy time. See below for links to more information on this and other key
>>> features.
>>>
>>
>> Hi folks,
>>
>> Unfortunately a critical bug [0] has escaped to the field. This bug
>> affects existing relations in upgraded models. Models created after
>> upgrading, or with a fresh bootstrap, or where relations are created after
>> upgrading, will not be affected.
>>
>> I would not recommend upgrading from 2.x. to 2.3.0. We will be working on
>> a fix for 2.3.1, and I expect this issue will bring that release forward
>> much sooner. If you have already upgraded and are affected, then you can
>> fix it by adding a document to the "statuses" collection in Mongo, as
>> described in the bug.
>>
>> Cheers,
>> Andrew
>>
>> [0] https://bugs.launchpad.net/juju/+bug/1737107
>>
>>
>>>
>>>
>>> ## How can I get it?
>>>
>>>
>>> The best way to get your hands on this release of Juju is to install it
>>> via snap packages (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/2.3/reference-install <
>>> 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.
>>>
>>>
>>> For highlights of this release, please see the documentation at
>>>
>>> https://jujucharms.com/docs/2.3/whats-new. Further details are below.
>>>
>>>
>>>
>>> ## New
>>>
>>>
>>> * Cross Model Relations:
>>>
>>>  - see https://jujucharms.com/docs/2.3/models-cmr
>>>
>>>
>>> * Persistent Storage:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-storage
>>>
>>>
>>> * FAN:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-fan
>>>
>>>
>>> * Bundle deployments:
>>>
>>>  - Changed flags for deploying bundles to existing machines
>>>
>>>  - Bundle deploy flag --bundle-config replaced with --overlay
>>>
>>>  - Deploying bundles now supports --dry-run
>>>
>>>  - Deploying bundles can now target existing machines
>>>
>>>
>>> * Update Application Series:
>>>
>>>  - see https://jujucharms.com/docs/2.3/howto-updateseries
>>>
>>>
>>> * Parallelization of the Machine Provisioner:
>>>
>>> - Groups of machines will now be provisioned in parallel reducing
>>> deployment time, especially on large bundles.
>>>
>>>
>>> * open_port and close_port hook tools now support ICMP
>>>
>>> - The open_port and close_port hook tools now support opening firewall
>>> access for ICMP. The syntax is:
>>>
>>> open_port icmp
>>>
>>>
>>> * LXD Storage Provider:
>>>
>>>  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)
>>>
>>>
>>> ## Fixes
>>>
>>>
>>> * Listing of Juju models is more efficient and can now handle more
>>> models gracefully
>>>
>>> * Leadership coordinations is no longer tied to local time which avoids
>>> problems with clock skew and reduces overall load on the database
>>>
>>> * Models are now more reliably destroyed and several fixes to avoid
>>> negative impacts while they are being removed
>>>
>>>
>>> You can check the milestones for a detailed breakdown of the Juju bugs
>>> we have fixed:
>>>
>>>
>>> https://launchpad.net/juju/+milestone/2.3.0
>>>
>>> https://launchpad.net/juju/+milestone/2.3-rc2
>>>
>>> https://launchpad.net/juju/+milestone/2.3-rc1
>>>
>>> 

Re: Deploying a charm with t's & c's

[Rick Harding]

Thanks for this Tom, for some reason the controller in the region there
isn't running 2.2.6, we're looking into it and will try to get it updated
as soon as possible.

On Mon, Dec 4, 2017 at 9:22 AM Tom Barber  wrote:

> mymodel  jaasaws/us-east-1  2.2.2unsupported
>
>
> Tom
>
>
> On 04/12/17 14:08, Matthew Williams wrote:
>
> Hi Tom,
>
> What version of the controller are you using (show in juju status). Is
> this your own controller or are you using jimm?
>
> Thanks
>
> Matty
>
> On Mon, Dec 4, 2017 at 10:33 AM, Tom Barber  wrote:
>
>> Hi Casey
>>
>> https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB As you'll see here.
>> #45 works for me also but #47 fails. I don't think we changed anything
>> massively but clearly something in there is sad, the problem is that, the
>> error thrown gives me no indication of where we've messed up.
>>
>> On a side note I wanted to grab the zip archive of #45 and #47 and do a
>> diff to see if it was obvious but both give me a 404 from the charm store.
>>
>> juju list-agreements
>> Term Agreed on
>> isrg-lets-encrypt/2  2017-04-26 09:43:38 + UTC
>> canonical/sla-terms/32017-08-31 21:19:16 + UTC
>> spiculecharms/pdi-terms/12017-11-27 23:24:11 + UTC
>>
>> Tom
>>
>>
>> On 04/12/17 02:54, Casey Marshall wrote:
>>
>> Tom,
>> With 2.2.6, I cannot reproduce any problems with deploying your charm.
>> See https://paste.ubuntu.com/26109617/
>>
>> Please send me more information about your installation:
>>
>> - How you installed Juju (snap, deb from PPA, compiled from source, etc.)
>> - Platform information on the machine you're running the Juju client on,
>> OS, etc. Is it on a physical host, in a VM, in a container?
>> - What cloud you're trying to deploy into
>>
>> If you type `juju list-agreements`, does that show terms you've agreed to?
>>
>> -Casey
>>
>> On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber  wrote:
>>
>>> Just as a quick update, I get the same if I deploy the charm directly
>>> and from the charm store ie not in a bundle.
>>>
>>> But removing the terms in the metadata.yaml removes the error.
>>>
>>> Tom
>>>
>>>
>>> On 28/11/17 18:36, Stephen Downie wrote:
>>>
>>> Thanks for looking into this Casey. The version of Juju I'm running is
>>> 2.2.6-xenial-amd64
>>>
>>>
>>> Spicule Ltd
>>>
>>> Tel: 01603 327762
>>>
>>>
>>>
>>> www.spicule.co.uk
>>>
>>> On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall <
>>> casey.marsh...@canonical.com> wrote:
>>>
 On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber  wrote:

> hey Casey
>
> if you have no models and try and deploy a bundle with terms it shows
> you the deploy screen them hangs. if you go back you see the model with 0
> units deployed.
>
> this is a local bundle we were testing, just exported from the gui,
> Ste can provide it if you need it.
>

 Thanks for clarifying. One last question, what version of Juju was used
 on the command line when trying to deploy the exported bundle?


>
> Tom
>
>
> On 28 Nov 2017 6:00 pm, "Casey Marshall" 
> wrote:
>
> On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie <
> step...@spicule.co.uk> wrote:
>
>> Thanks. I have tried running juju agree spiculecharms/pdi-terms/1 and
>> it states terms already agreed?
>>
>> When trying to deploy in the GUI it returns the error message cannot
>> create bundle: already exists. It appears that it creates the model but
>> does't actually deploy anything? I know I'm a bit new to this but 
>> something
>> seems a bit broken.
>>
>
> Is it possible that the model name in the GUI (the drop down in the
> upper-left of the canvas) matched an already-created model name? You might
> need to type in a new model name there.
>
> Or does this happen for new models with this bundle no matter what?
>
> Was this in the GUI in JAAS (jujucharms.com)? Did you try deploying a
> bundle from the charmstore, or did you try importing a bundle.yaml file?
>
>
>>
>> Thanks all for your help.
>>
>> Spicule Ltd
>>
>> Tel: 01603 327762
>>
>>
>>
>> www.spicule.co.uk
>>
>> On Tue, Nov 28, 2017 at 12:33 PM, Tom Barber 
>> wrote:
>>
>>> stupid question, but I assume the bundles should handle t's better?
>>>
>>> On 28 Nov 2017 12:29, "Ales Stimec" 
>>> wrote:
>>>
 Hi,

 Could you please try
juju agree spiculecharms/pdi-terms/1

 This is these are the terms that require agreement in order to
 deploy cs:~spiculecharms/pentaho-data-integration-45.
 To get a list of terms i used:
curl "
 

Re: juju status ERROR current model controller devlocal not found

[Rick Harding]

Hi Feng, did you get anywhere with this? It looks like you're running
status on the controller itself. That's not a model to run status on. I'd
check out what juju list-models shows and run juju status on those.

I think what you need to do is to switch into the controller/model you want
to status or use the -m flag to specify it manually. Some helpful commands.

juju models
juju show-controller -c devlocal
juju status -m devlocal:controller
juju status -m devlocal:default
juju switch devlocal
juju models

On Mon, Dec 4, 2017 at 10:33 AM fengxia  wrote:

> Hi Juju,
>
> I had a localhost controller bootstrapped and deployed 8 machines (LXDs)
> to it. Host is a KVM vm of Ubuntu 16.04 amd64.
>
> Now for some strange reason, `juju status` reports error as if it lost
> its model? `list-controllers` showed the controller looks fine. `lxc
> list` shows all the machines are up and running.
>
> Any idea of what this error is about, and how to debug it?
>
> 
>
> (dev) fengxia@ubuntu:~$ juju status
> ERROR current model for controller devlocal not found
> (dev) fengxia@ubuntu:~$ juju list-controllers
> Use --refresh flag with this command to see the latest information.
>
> Controller  Model  User   Access Cloud/Region Models
> MachinesHA  Version
> devlocal*   -  admin  superuser  localhost/localhost 2 1
> none  2.2.6
>
> (dev) fengxia@ubuntu:~$ juju status
> ERROR current model for controller devlocal not found
> (dev) fengxia@ubuntu:~$ lxc list
>
> +---+-+---+--++---+
> | NAME  |  STATE  | IPV4  | IPV6 | TYPE|
> SNAPSHOTS |
>
> +---+-+---+--++---+
> | juju-6f4281-0 | RUNNING | 10.175.135.196 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-0 | RUNNING | 10.175.135.253 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-1 | RUNNING | 10.175.135.247 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-2 | RUNNING | 10.175.135.191 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-3 | RUNNING | 10.175.135.116 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-4 | RUNNING | 10.175.135.106 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-5 | RUNNING | 10.175.135.128 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-6 | RUNNING | 10.175.135.83 (eth0)  |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
> | juju-7031bf-7 | RUNNING | 10.175.135.223 (eth0) |  | PERSISTENT |
> 0 |
>
> +---+-+---+--++---+
>
> (dev) fengxia@ubuntu:~$ juju list-models
> Controller: devlocal
>
> Model   Cloud/Region Status Machines  Cores Access  Last
> connection
> controller  localhost/localhost  available 1  - admin   just
> now
> default localhost/localhost  available 8  - admin   11
> hours ago
>
> --
> 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju bootstrap fails

[Rick Harding]

Hi Deepa. When Juju boostrap it provisions a node and then uses an ssh
connection to communicate with that provisioned node. It looks like your
client machine isn't able to communicate with the newly provisioned MAAS
node without the proxy config you've setup to help with it. I personally
use a tool sshuttle [1]to enable me to create a tunnel to the MAAS managed
network from my client network so that I can work with the bootstrapped
controllers on MAAS.

1: https://sshuttle.readthedocs.io/en/stable/


On Tue, Nov 28, 2017 at 12:35 AM Deepa K R  wrote:

> Hello Team
>
>
>
>   I am trying to bootstrap a VM machine in order to deploy Openstack cloud
>  and it hangs as below
>
>
>
> maasadmin@FGSUSSUMAAS01:~$ juju bootstrap stagingmaas
>
> Creating Juju controller "stagingmaas" on stagingmaas
>
> Looking for packaged Juju agent version 2.2.6 for amd64
>
> Launching controller instance(s) on stagingmaas...
>
> - qrdf8y (arch=amd64 mem=10G cores=10)
>
> Fetching Juju GUI 2.10.2
>
> Waiting for address
>
> Attempting to connect to 10.x.0.10:22  <<<
>
>
>
> maasadmin@FGSUSSUMAAS01:~/openstack-stg$ juju --version
>
> 2.2.6-xenial-amd64
>
>
>
> Is there any way to fix this out .
>
>
>
> Also please note if I use below details in bootstrap.config file ,boot
> strap succeeds. 10.139.0.50 is the private IP of maas server  .
>
>
>
> default-series: xenial
>
> no-proxy: localhost
>
> http-proxy: http://10.x.0.50:8000
>
> https-proxy: http://10.x.0.50:8000
>
> ftp-proxy: http://10.x.0.50:8000
>
>
>
> If I use public IP of maas server in config file ,bootstrap fails
>
>
>
> As you see 10.x.0.50 is the private IP of maas server and Openstack
> deployment fails with
>
>
>
> Machine  StateDNS  Inst id  Series  AZ   Message
>
> 0down 10.x.0.17  4rc3n3   xenial  default  Failed deployment:
> Power state queried: on
>
> 0/lxd/0  pending   pending  xenial
>
> 0/lxd/1  pending   pending  xenial
>
> 0/lxd/2  pending   pending  xenial
>
> 0/lxd/3  pending   pending  xenial
>
> 0/lxd/4  pending   pending  xenial
>
> 1down 10.x.0.18  gst3at   xenial  default  Failed deployment:
> Power state queried: on
>
> 1/lxd/0  pending   pending  xenial
>
> 1/lxd/1  pending   pending  xenial
>
> 1/lxd/2  pending   pending  xenial
>
> 1/lxd/3  pending   pending  xenial
>
> 2down 10.x.0.19  s8pct4   xenial  default  Failed deployment:
> Power state queried: on
>
> 3down 10.x.0.20  7nrsab   xenial  default  Failed deployment:
> Power state queried: on
>
> 4down 10.x.0.21  7pqsdy   xenial  default  Failed deployment:
> Power state queried: on
>
>
>
> Please see the attachment also .
>
>
>
> So in order to get deployment going I need bootstrap issue to get resolve .
>
> Kindly suggest
>
>
>
> Regards,
>
> Deepa K R
>
>
>
>
> --
> 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

call to charmers/bundlers add a getstarted.md file

[Rick Harding]

Jeff's put together a blog post [1] on a new bit of functionality that the
GUI has baked in. It now supports showing a getstarted.md file when a charm
or bundle is deployed.

It's time to move those "you've deployed now what" next steps to a home
that the user gets in the right moment to be helpful and to leave room for
README files to be more clean/concise.

Check out the blog post and help your users out with great next steps
content.

1:
https://blog.jujugui.org/2017/10/30/juju-gui-get-your-users-started-with-getstarted-md/

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

Re: call for testing: relations across Juju models

[Rick Harding]

I've got this blog post on using snaps to change the version of Juju you're
running:

http://mitechie.com/blog/2017/7/20/testing-the-future-of-juju-with-snaps

Looking at the moment you can see from 'snap info juju' that the 2.3 beta1
is on the beta channel and the edge is the upcoming beta2. Either of those
you can use to start testing.

As far as using the feature check out this post I did and there's some in
flight documentation that the team is actively working on.

http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju
https://github.com/juju/docs/pull/2248



On Tue, Oct 24, 2017 at 11:49 AM Giuseppe Attardi <giuseppe.atta...@garr.it>
wrote:

> Thanks, we would like to try it.
> Where are the instructions for downloading it?
>
> — Beppe
>
> On 24 ott 2017, at 16:32, Rick Harding <rick.hard...@canonical.com> wrote:
>
> Definitely please try out the beta and play with it. I know there's been a
> couple of bugs driven out since beta1 already from folks banging on things
> so the more testing we get the better.
>
> On Tue, Oct 24, 2017 at 10:29 AM Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> I've been using cross model relations in 2.3-beta for the past few weeks
>> with little problem. I have a few more days of testing but I'll report back
>> here next week if no one else has feedback.
>>
>> Marco
>>
>> On Tue, Oct 24, 2017 at 4:11 PM Giuseppe Attardi <
>> giuseppe.atta...@garr.it> wrote:
>>
>>> This is a useful feature for our federated cloud architecture.
>>> Any news on the status of development and expected release date/
>>>
>>> Thank you
>>>
>>> — Beppe Attardi
>>>
>>>
>>> --
>>> 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
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: call for testing: relations across Juju models

[Rick Harding]

Definitely please try out the beta and play with it. I know there's been a
couple of bugs driven out since beta1 already from folks banging on things
so the more testing we get the better.

On Tue, Oct 24, 2017 at 10:29 AM Marco Ceppi 
wrote:

> I've been using cross model relations in 2.3-beta for the past few weeks
> with little problem. I have a few more days of testing but I'll report back
> here next week if no one else has feedback.
>
> Marco
>
> On Tue, Oct 24, 2017 at 4:11 PM Giuseppe Attardi 
> wrote:
>
>> This is a useful feature for our federated cloud architecture.
>> Any news on the status of development and expected release date/
>>
>> Thank you
>>
>> — Beppe Attardi
>>
>>
>> --
>> 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

intro to speaking juju, the show and blog

[Rick Harding]

Last week we did an intro to the terminology used in Juju during the Juju
Show [1]. I've gotten up the blog post [2] to go with it now. Please check
it out and let me know if you find it useful for introducing folks to Juju.

Thanks

Rick

1: https://www.youtube.com/watch?v=_yMx129uhYc
2: https://insights.ubuntu.com/2017/10/03/learning-to-speak-juju/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What determines the charm series?

[Rick Harding]

The series is defined in the metadata.yaml. Charms now support a list of
series and the preference for the charm is determined by the order in the
list.

Before the support for one charm to support multiple series at once, users
had to publish them directly to a specific series which is why you're not
seeing it in the older charms.

You can force a deploy to a series at deploy time. To quote juju deploy
--help

If '--series' is not specified, the charm's default series is used. The
default
series for a charm is the first one specified in the charm metadata. If the
specified series is not supported by the charm, this results in an error,
unless '--force' is used.

If you want to see if the charm will work on the latest series try using
that --force option.

On Tue, Sep 26, 2017 at 10:25 AM Akshat Jiwan Sharma 
wrote:

> Hello Everyone,
>
> I was looking at wordpress charm on the juju store and I noticed that the
> recommended version supported Trusty and Precise series. Where as one
> community version supported xenial and trusty series.
>
> I downloaded the recommended   
> charm
> package from the store and tried to look at code but I could not see where
> exactly the series definition is set. However in one of the community
> editions  the series
> was mentioned in the metadata.yml file.
>
> Is there any way I can use the recommended wordpress charm on my xenial
> machine. Currently when I try to deploy I get the following error:-
>
> "cannot add application "wordpress": cannot deploy to machine 0: series
> does not match"
>
> Thanks,
> Akshat
> --
> 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: using the new bundle features in Juju 2.2.3

[Rick Harding]

On Sat, Sep 16, 2017 at 3:23 AM Patrizio Bassi 
wrote:

> +1 from my side.
>
> At the moment i have 3 bundles, dev, qa and prod which differ only by IPs
> and unit number
> It would be great to have a dynamic filled bundle :)
>

Having IP addresses in there is something that are so specific from one
deployment to another I wonder if there's room to update either a relation
among charms or leverage spaces as an abstraction for the IP
addresses/ranges that can hep get rid of that. Ideally the model is generic
and repeatable enough that specifying IP and unit numbers isn't an issue.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: using the new bundle features in Juju 2.2.3

[Rick Harding]

On Fri, Sep 15, 2017 at 10:33 AM Giuseppe Attardi 
wrote:

> Is it possible to use variables in the bundle defined in the bundle-config?
>

Not currently no, there's no string substitution in there. Are you looking
for model specific data to make it in? Or some other input?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

using the new bundle features in Juju 2.2.3

[Rick Harding]

I wanted to mention that I put together a demo with a blog post and we ran
through the demo in The Juju Show yesterday. I have a feeling these updates
to allow --bundle-config will be really useful in a wide array of bundle
use out there. Take a look and I'd love to hear how folks put these changes
to use to help manage things.

Blog Post:
http://mitechie.com/blog/2017/9/12/modeling-the-infrastructure-while-keeping-security-and-flexibility-in-mind

The Juju Show #21:
https://www.youtube.com/watch?v=3658lsehjKM

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

Re: How to use the same controller from multiple devices on JaaS?

[Rick Harding]

JAAS is definitely great because it's basing everything off the single
login in JAAS and you can juju login jaas to reconnect from another machine
and pick up where you left off.

What I've found handy is that if I bootstrap my own controller is to add a
user for the other machines. I use juju add-user and then email myself the
register command. From the second machine I run the register command and
now I'm able to work against the controller.

The docs on adding a user are here:
https://jujucharms.com/docs/stable/users

What's happening is that when you bootstrap a cached file about the
controller with it's IP address and other details is stored on your file
system. When you go to the second computer it doesn't know any of those
details so you have to inform it. Using the second user automates that
process for you. I'm sure there's other methods you could use to sync
things up as well.

Hope that helps.

Rick

On Wed, Sep 13, 2017 at 1:22 PM Akshat Jiwan Sharma 
wrote:

> Hello Jang,
>
> I asked a similar question a couple of days back and got great answers
> from the community. I think you might find John's response
>  on
> how JAAS works quite helpful (even though it is not directly related to
> your question). In simple terms JAAS is a hosted controller. To use JAAS
> from your local machine you just have to login to it from your terminal.
> Assuming that you have juju installed, on the device you want to access
> JAAS from, you simply have to type this command (as described
>  on JAAS website):-
>
> `juju login jaas`
>
> and after completing the authentication process you should be able to use
> jass just like you would a local controller from your machine.
>
> In other words if you want to use JAAS you don't need to bootstrap any
> controllers on your machine. You only need to authenticate your machine
> with the JAAS controller that is already hosted for you on the cloud.
>
> >so I added another azure credential from another laptop
>
> Once you have connected to JAAS from your machine you should be able to
> use all the credentials that you've added to JAAS.
>
> Does that answer your question?
>
> Best,
> Akshat
>
> On Wed, Sep 13, 2017 at 9:38 PM, Jang Taehee  wrote:
>
>> Hello, I'm a newbie and have a question about controller in cloud.
>>
>> I'm using Microsoft Azure cloud and added 1 controller.
>> I want to use this controller from other laptop, so I added another azure
>> credential from another laptop. But it didn't reacted any juju commands.
>> How can I use juju commands from multiple devices to one controller?
>>
>> Thank you.
>>
>> --
>> 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm snap is now strictly confined

[Rick Harding]

+1 awesome work folks.

On Fri, Sep 8, 2017 at 2:49 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

>
>
> On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber  wrote:
>
>> good effort devs!
>>
>
> +1, thanks Cory.
>
>
>>
>> On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:
>>
>>> Greetings,
>>>
>>> I just wanted to make a quick announcement that the charm snap is now
>>> strictly confined on the stable channel (rev 17).  This fixes issues like
>>> https://github.com/juju/charm-tools/issues/339 and
>>> https://github.com/juju/charm-tools/issues/319 and prevents similar
>>> issues from cropping up in the future.
>>>
>>> In general, this change should be pretty much transparent, with the one
>>> caveat being that you can only build charms from under your HOME directory.
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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

Re: Charm snap is now strictly confined

[Rick Harding]

+1 awesome work folks.

On Fri, Sep 8, 2017 at 2:49 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

>
>
> On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber  wrote:
>
>> good effort devs!
>>
>
> +1, thanks Cory.
>
>
>>
>> On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:
>>
>>> Greetings,
>>>
>>> I just wanted to make a quick announcement that the charm snap is now
>>> strictly confined on the stable channel (rev 17).  This fixes issues like
>>> https://github.com/juju/charm-tools/issues/339 and
>>> https://github.com/juju/charm-tools/issues/319 and prevents similar
>>> issues from cropping up in the future.
>>>
>>> In general, this change should be pretty much transparent, with the one
>>> caveat being that you can only build charms from under your HOME directory.
>>>
>>> --
>>> 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
>>
>> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Newbie Question: How do I replace a machine in a deployed Model?

[Rick Harding]

On Tue, Sep 5, 2017 at 1:03 PM Raghurama Bhat  wrote:

> Hi Rick,
>
>
>
> My question was more generic in the sense, How do I build self healing to
> the system where I can replace broken machines. In the scenario that you
> describe below, will the remaining workers be correctly associated with the
> new master and etcd? Will it correctly trigger the charm logic on worker
> machine to point it to the new etcd and master?
>

 So in the scenario the new machine will come up and the charms will be
told about the new units available to be put into the pool to be used.
However, how the pool of available running instances of the software is
managed, that's managed by the software itself and how it recovers from a
fallen comrade. In the case of a datastore like etcd, it's up to etcd to
manage how many instances are in the cluster and how it responds when one
is removed and another is added. Juju doesn't do anything special with the
actual process itself there. It makes sure that all the information about
each running unit, the configuration, and it's the details of each unit of
related applications is up to date.

To make sure things are resilient you'd want to wire up monitoring to
either scripts (potentially written with libjuju) to respond how you'd like
to respond to different types of failure. This might mean adding new units,
it might mean scaling up units by adding new units with increased
constraints, it might mean performing actions against charms, it might
involve sending out automated messages to folks on call. That's something
that is very business specific and hopefully users have the building blocks
and tools they need to solve their business problems.

Rick

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

Re: Juju-gui only show localhost as the deployment option

[Rick Harding]

Sure thin Akshat. Pricing is still ongoing as we learn from the beta how
the back end costs work out. Our goal is definitely to use scale and our
expertise to have using JAAS be cheaper than your own infrastructure.
There's likely to be different pricing levels based on things like support
requirements. As we know more I'll make sure we spread the word.

As to conjure-up. It's a great client for Juju and JAAS. You'd use
conjure-up and it has an option to perform the deployment against JAAS as
the controller vs creating your own. In that way it's all compatible. You'd
just use the conjure-up tool you know/love and target it to JAAS for doing
the operating of the running model in the end.

Hope that helps and don't hesitate to let me know if you have any other
questions.


On Fri, Sep 1, 2017 at 8:18 AM Akshat Jiwan Sharma <akshatji...@gmail.com>
wrote:

> Hi Rick,
>
> Thank you for mentioning JAAS. It does indeed solve many of my problems.
> It would be great if you could let me know a bit about pricing. I
> understand that it's in Beta at the moment. But when it launches will the
> pricing be based on number of models/number or deployments or some other
> criteria. Some sort of an idea around pricing would be very helpful.
>
> Overall it looks like JAAS already does what I'm trying to do. And if the
> pricing is on a similar level as compared to what it would be when I'd
> deploy juju on my own then it becomes a no brainier.
>
> Also I was watching the Getting started with Juju
> <https://www.youtube.com/watch?v=OBseJVHuVXI=PLW1vKndgh8gJS4upPNaXiYYHnCmFdWk03>
> video on youtube and I learnt about conjure-up. I'm assuming that JAAS will
> be compatible with all of conjure up commands? Or is conjure-up a slightly
> different workflow as compared to juju?
>
> Best,
> Akshat
>
> On Wed, Aug 30, 2017 at 10:44 PM, Rick Harding <rick.hard...@canonical.com
> > wrote:
>
>> Just to toss, out. JAAS [1] is built to be Juju as a Service across
>> clouds doing some of the extra work to enable users to have a single
>> dashboard across a wide array of clouds and regions. Give it a try and I'd
>> love to chat about any feedback on where JAAS does or doesn't fit for the
>> needs you're having.
>>
>> 1: https://jujucharms.com
>>
>> On Wed, Aug 30, 2017 at 10:59 AM fengxia <fx...@lenovo.com> wrote:
>>
>>> Akshat,
>>>
>>> Just to chip in some of my thoughts on this since we (disclosure, I'm a
>>> researcher at Lenovo) have had extensive discussions on a similar use case
>>> and consequently come down to the same challenge as you are currently
>>> looking at.
>>>
>>> 1. Juju CLI allows user to select controller, which essentially leads to
>>> a particular cloud/provider (these two are 1-1 mapping). Therefore, in
>>> practice it already supports multi-cloud scenario (last time I counted 12
>>> clouds out of box including local LXD and manual). The catch is, of course,
>>> the manual step of selecting the proper controller.
>>>
>>> 2. There are two schools of thought -- whether to have Juju being more
>>> intelligent so to handle multiple clouds `automatically` (for example, in
>>> bundle YAML specify which cloud a charm should be deployed to, which is one
>>> step further than OS series), or using Juju as-is and utilize something
>>> else as a wrapper to facilitate such mixed-cloud automation. The former
>>> option minimize tech stack so there is one set of technology to learn and
>>> manage; the latter gives flexibility, mitigate vendor lock in... I think
>>> the theme is not new, so it's really a matter of design preference
>>>
>>> Juju team has done 90% of the heavy liftings. The former will require
>>> more in-depth of Juju knowledge, the latter requires less. I think the
>>> requirements, however, is clear, that there is a higher level of
>>> abstraction required above the current Juju existence so to drive this.
>>>
>>>
>>>
>>> On 08/30/2017 04:27 AM, Akshat Jiwan Sharma wrote:
>>>
>>> Thank you Feng,
>>>
>>> As I understand for now there is no way to use multiple providers with
>>> juju either with a GUI or command line.
>>>
>>> My goal is to be able to allow users to deploy charms (mostly
>>> wordpress/drupal/ghost) on a cloud of their choice. Anything that allows me
>>> to do this is acceptable. The only requirement is maximum cloud coverage.
>>> So for a multi cloud setup what options do I have?
>>>
>>> - Should I go for one controller per cloud setup?
>>> - Can juju api <https:/

Re: remove-application openstack-dashboard

[Rick Harding]

Is it alone on that container on machine 1 - container 12? If so you can

juju remove-machine --force 1/lxd/12

On Thu, Aug 31, 2017 at 8:08 PM Giuseppe Attardi 
wrote:

> I am not able to remove an openstack-dashboard application from a model,
> because apparently there is no registered hook for stop in the charm and
> the log shows:
>
> INFO juju-log Unknown hook stop - skipping.
>
> and juju status shows:
>
> App  Version  Status  Scale  Charm
> Store   Rev  OS   Notes
> openstack-dashboard  11.0.2   terminated  1  openstack-dashboard
> jujucharms  247  ubuntu
>
> UnitWorkloadAgent  Machine   Public
> address  Ports   Message
> openstack-dashboard/2*  terminated  executing  1/lxd/12  90.147.161.39
>  80/tcp,443/tcp  (stop)
>
> How can I get rid of it?
>
> —
>
>
>
>
> --
> 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: Juju-gui only show localhost as the deployment option

[Rick Harding]

Just to toss, out. JAAS [1] is built to be Juju as a Service across clouds
doing some of the extra work to enable users to have a single dashboard
across a wide array of clouds and regions. Give it a try and I'd love to
chat about any feedback on where JAAS does or doesn't fit for the needs
you're having.

1: https://jujucharms.com

On Wed, Aug 30, 2017 at 10:59 AM fengxia  wrote:

> Akshat,
>
> Just to chip in some of my thoughts on this since we (disclosure, I'm a
> researcher at Lenovo) have had extensive discussions on a similar use case
> and consequently come down to the same challenge as you are currently
> looking at.
>
> 1. Juju CLI allows user to select controller, which essentially leads to a
> particular cloud/provider (these two are 1-1 mapping). Therefore, in
> practice it already supports multi-cloud scenario (last time I counted 12
> clouds out of box including local LXD and manual). The catch is, of course,
> the manual step of selecting the proper controller.
>
> 2. There are two schools of thought -- whether to have Juju being more
> intelligent so to handle multiple clouds `automatically` (for example, in
> bundle YAML specify which cloud a charm should be deployed to, which is one
> step further than OS series), or using Juju as-is and utilize something
> else as a wrapper to facilitate such mixed-cloud automation. The former
> option minimize tech stack so there is one set of technology to learn and
> manage; the latter gives flexibility, mitigate vendor lock in... I think
> the theme is not new, so it's really a matter of design preference
>
> Juju team has done 90% of the heavy liftings. The former will require more
> in-depth of Juju knowledge, the latter requires less. I think the
> requirements, however, is clear, that there is a higher level of
> abstraction required above the current Juju existence so to drive this.
>
>
>
> On 08/30/2017 04:27 AM, Akshat Jiwan Sharma wrote:
>
> Thank you Feng,
>
> As I understand for now there is no way to use multiple providers with
> juju either with a GUI or command line.
>
> My goal is to be able to allow users to deploy charms (mostly
> wordpress/drupal/ghost) on a cloud of their choice. Anything that allows me
> to do this is acceptable. The only requirement is maximum cloud coverage.
> So for a multi cloud setup what options do I have?
>
> - Should I go for one controller per cloud setup?
> - Can juju api  help me write
> some custom code that'll allow me to do what I want? If so what should I be
> looking for in the documentation?
> - Since juju runs in an lxc  would it be a good idea to create clone
> containers that can switch the cloud environment on demand? Or would this
> cause more problems that it'll solve?
>
> Thank you once more for being patient with the questions and for all the
> answers! Much appreciated
>
> Best,
> Akshat
>
> On Wed, Aug 30, 2017 at 7:56 AM, fengxia  wrote:
>
>> Hi Akshat,
>>
>> Juju controller does not support multiple cloud/provider. It's like a
>> switch board, juju can only talk to one controller at a time.
>> However, I do think there are use case of supporting multiple clouds with
>> one orchestrator. I'm not sure whether juju team has sth like that on its
>> roadmap, or maybe using some other tools for the purpose?
>> On 08/29/2017 09:59 AM, Akshat Jiwan Sharma wrote:
>>
>> Is there a way I can configure multiple providers using the Juju-GUI?
>> Also is there a way I can configure cloud providers based on user access
>> roles? For example a user with access to a particular model can deploy only
>> to a specific cloud provider.
>>
>> If one controller can manage multiple clouds and one controller can have
>> many users then what is the mapping of the relationship between the users
>> and the clouds?
>>
>> Thanks,
>> Akshat
>>
>>
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>>  
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>   
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
> --
> 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: juju deploy docker

[Rick Harding]

Can you check the juju debug-log or juju ssh docker/0 and sudo cat
/var/log/juju/unit-xxx to see what's failed?

It looks like the charm there is hitting an error and will have to debug
what's up by checking the logs.

On Wed, Aug 30, 2017 at 1:02 PM Micheal B  wrote:

> Running juju vsphere cloud – current CDK
>
>
>
> Test both
>
>
>
> Juju deploy docker
>
> And
>
> juju deploy docker --series xenial –force
>
>
>
> always get
>
> hook failed: "config-changed"
>
>
>
> Tested other installs
>
> juju add-unit kubernetes-worker  --- install fine
>
>
>
> check DNS / DHCP all of that appears fine
>
>
>
> Trying to setup a registery pod if that help.
>
>
>
>
>
> Thanks
>
>
>
> Micheal
> --
> 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: Juju-gui only show localhost as the deployment option

[Rick Harding]

Hi Akshat, thanks for the interesting questions. I think that the blocker
is that a single controller cannot currently manage multiple clouds. Only
regions within the cloud. Once a cloud is bootstrapped to a specific cloud
it assumes all models are on that provider from then on.

In this way, the users are in the controller and so aren't cloud aware in
any way.

If a user has access to a model then it can only access that specific model
and the cloud and region it's on. So I'm not sure about the question of
limiting a user to only a specific cloud provider based on the model.
That's already built in at that point.

This is good to think about though if we bring multiple clouds to a single
controller that ACLs that limit the ability to use only specific
credentials would be something to consider.

Rick

On Tue, Aug 29, 2017 at 10:00 AM Akshat Jiwan Sharma 
wrote:

> Is there a way I can configure multiple providers using the Juju-GUI? Also
> is there a way I can configure cloud providers based on user access roles?
> For example a user with access to a particular model can deploy only to a
> specific cloud provider.
>
> If one controller can manage multiple clouds and one controller can have
> many users then what is the mapping of the relationship between the users
> and the clouds?
>
> Thanks,
> Akshat
> --
> 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: Elasticsearch Charm Promulgation

[Rick Harding]

I'd also encourage you to test an upgrade path from the current charm to
yours to help comfort any current users of the charm that if there's a
change it'll go smoothly for users.

On Mon, Aug 14, 2017 at 1:00 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> Hey James, my point was that if you want to replace the existing top-level
> ES charm with your own, we would need agreement from the maintainers of the
> existing charm.
>
> On Mon, Aug 14, 2017 at 12:45 PM, James Beedy 
> wrote:
>
>> @tim yeah ... possibly I'm not looking for promulgation then, and just
>> need to push it and grant everyone because its already promulgated?
>>
>> On Mon, Aug 14, 2017 at 9:29 AM, Tim Van Steenburgh <
>> tim.van.steenbu...@canonical.com> wrote:
>>
>>> There's already a top-level elasticsearch charm.
>>> https://jujucharms.com/elasticsearch/
>>>
>>> On Mon, Aug 14, 2017 at 12:13 PM, James Beedy 
>>> wrote:
>>>
 Request for promulgation of Elasticsearch. The Elasticsearch charm can
 be found at cs:~jamesbeedy/elasticsearch-7.

 Thanks,

 James

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

Re: Juju deploy a model, MAAS node status

[Rick Harding]

Glad you're off and running. I'll get a bug filed that the error messaging
from there could have been more helpful pointing to the lack of the image.
Hopefully Juju can build a better idea or add series to the output
constraint matching information in the very least.

On Mon, Aug 7, 2017, 8:38 AM wahi  wrote:

> Dear all,
>
> The problem has been solved, really it was related that there was no
> trusty on MAAS server, when I deployed mongodb it worked without any
> problem.
>
> Thanks a lot for all suggestions and help.
>
>
>
> Best,
>   Wahi
>
> --
> 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: The Juju Show #18 - testing new storage features

[Rick Harding]

And to watch the show for those that miss my dulcet tones:

https://www.youtube.com/watch?v=jrOP3nHNRcs

On Wed, Aug 2, 2017 at 2:42 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> In the show today we talked about testing out the new storage features
> coming in Juju 2.3. Now's a great time to test things out, update your
> charms, and see how these big changes will enable you to operate
> applications better. I wanted to drop a bunch of links here that I mention
> in the show.
>
> How do I get it? Use the edge snap
> http://mitechie.com/blog/2017/7/20/testing-the-future-of-juju-with-snaps
>
> Where can I test it?
> with AWS, GCE, Azure, OpenStack, and LXD (ooh new fancy storage tools)
>
> Any documentation in progress?
>
> https://jujucharms.com/docs/master/charms-storage
> https://jujucharms.com/docs/master/developer-storage
> https://awilkins.id.au/post/juju-2.3-storage/
>
> Test it out and let us know what questions you have and I'd love to see a
> suite of charms growing the ability to operate storage needs much better
> between now and when Juju 2.3 comes out.
>
> Rick
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

The Juju Show #18 - testing new storage features

[Rick Harding]

In the show today we talked about testing out the new storage features
coming in Juju 2.3. Now's a great time to test things out, update your
charms, and see how these big changes will enable you to operate
applications better. I wanted to drop a bunch of links here that I mention
in the show.

How do I get it? Use the edge snap
http://mitechie.com/blog/2017/7/20/testing-the-future-of-juju-with-snaps

Where can I test it?
with AWS, GCE, Azure, OpenStack, and LXD (ooh new fancy storage tools)

Any documentation in progress?

https://jujucharms.com/docs/master/charms-storage
https://jujucharms.com/docs/master/developer-storage
https://awilkins.id.au/post/juju-2.3-storage/

Test it out and let us know what questions you have and I'd love to see a
suite of charms growing the ability to operate storage needs much better
between now and when Juju 2.3 comes out.

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

Re: JAAS issue: add-model not working properly

[Rick Harding]

On Tue, Aug 1, 2017 at 3:18 PM Rick Harding <rick.hard...@canonical.com>
wrote:

>
> ...please note that they're not the 2.2.2 release of Juju.
>

Please note that THEY ARE the 2.2.2 release of Juju.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: JAAS issue: add-model not working properly

[Rick Harding]

Thank you for your patience. This issue has been corrected. The team has
identified a bug in the system that was corrected and an update was
deployed to production.

With this fix in place users are free to add new models and please note
that they're not the 2.2.2 release of Juju.



On Mon, Jul 31, 2017 at 3:48 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> The team is currently investigating an issue in JAAS causing users to not
> be able to create new models. None of the current models are affected. The
> error looks like:
>
> ERROR already exists
>
> We'll update everyone as we know more. Thanks for your patience as we work
> on it.
>
> Rick
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: testing the future of juju with snaps

[Rick Harding]

And one of these days I'll learn how email works and reply to the right
email. Apologies for the noise.

On Thu, Jul 20, 2017 at 11:40 AM Rick Harding <rick.hard...@canonical.com>
wrote:

> I've added the image and editing back in the paragraphs and such that
> didn't copy over. Can you please play editor and tweak it for any insights
> consistency and such please before it goes live?
>
> Thanks!
>
> On Thu, Jul 20, 2017 at 11:17 AM Rick Harding <rick.hard...@canonical.com>
> wrote:
>
>> In light of recent calls for testing out upcoming 2.3 work [1][2] I
>> wanted to make sure folks were aware of how easy it can be to get a hold of
>> a really recent build of trunk and test things out, look into how you can
>> use it, and provide feedback.
>>
>> http://mitechie.com/blog/2017/7/20/testing-the-future-of-juju-with-snaps
>>
>>
>> 1:
>> http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju
>> 2: https://awilkins.id.au/post/juju-2.3-storage/
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: testing the future of juju with snaps

[Rick Harding]

I've added the image and editing back in the paragraphs and such that
didn't copy over. Can you please play editor and tweak it for any insights
consistency and such please before it goes live?

Thanks!

On Thu, Jul 20, 2017 at 11:17 AM Rick Harding <rick.hard...@canonical.com>
wrote:

> In light of recent calls for testing out upcoming 2.3 work [1][2] I wanted
> to make sure folks were aware of how easy it can be to get a hold of a
> really recent build of trunk and test things out, look into how you can use
> it, and provide feedback.
>
> http://mitechie.com/blog/2017/7/20/testing-the-future-of-juju-with-snaps
>
>
> 1:
> http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju
> 2: https://awilkins.id.au/post/juju-2.3-storage/
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

testing the future of juju with snaps

[Rick Harding]

In light of recent calls for testing out upcoming 2.3 work [1][2] I wanted
to make sure folks were aware of how easy it can be to get a hold of a
really recent build of trunk and test things out, look into how you can use
it, and provide feedback.

http://mitechie.com/blog/2017/7/20/testing-the-future-of-juju-with-snaps


1:
http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju
2: https://awilkins.id.au/post/juju-2.3-storage/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: jujucharms.com outage in progress

[Rick Harding]

On Tue, Jul 11, 2017 at 10:39 AM Rick Harding <rick.hard...@canonical.com>
wrote:

> We're currently experiencing an unexpected outage of jujucharms.com and
> the charmstore. We apologize for the inconvenience. The team is actively
> working to bring things back as soon as possible. We'll keep you up to date
> as we progress.
>

Service has been restored. The team identified some abusive traffic causing
excess database queries that caused the outage. The team will be working on
additional methods to monitor and prevent this type of traffic in the
future.

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

jujucharms.com outage in progress

[Rick Harding]

We're currently experiencing an unexpected outage of jujucharms.com and the
charmstore. We apologize for the inconvenience. The team is actively
working to bring things back as soon as possible. We'll keep you up to date
as we progress.

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

Re: call for testing: relations across Juju models

[Rick Harding]

On Sat, Jul 8, 2017 at 11:26 PM John Meinel  wrote:

> ...
>>
>
>
>> Current known limitations:
>> Only works in the same model
>>
>
> I'm guessing you mean "only works in the same controller". If cross model
> relations were only to work in a single model then they'd just be
> relations. :)
>

Hah, nice catch. Yes, only the same controller. I hear there's stuff to
play with that works around that limitation coming soon as well. Exciting
times!

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

call for testing: relations across Juju models

[Rick Harding]

As I noted in The Juju Show [1] this week I've put together a blog post
around the cross model relations feature that folks can test out in Juju
2.2. Please test it out and provide your feedback.

http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju

Current known limitations:
Only works in the same model
You need to bootstrap with the feature flag to test it out
Does not currently work with relations to subordinates. Work is in progress

There's a lot of possibilities so we'd like to hear what you test out. I
just noticed that Spicule folks are tinkering with an LDAP charm [2] and a
single LDAP instance providing auth to an array of models is a very
exciting possibility, for instance.

Thanks everyone.

Rick

1: https://www.youtube.com/watch?v=d_vMN_opVlA
2: https://twitter.com/stephenspicule/status/883350361305747456
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Command Completion Not working? --SOLVED

[Rick Harding]

Awesome, glad you got it worked out and things nice and up to date with 2.2

On Wed, Jun 28, 2017 at 7:30 PM N. S.  wrote:

> Hi,
>
> Sorry
> False Alarm.
>
> There is something wrong , especially that version reads 2.0.2!
>
> After the refresh of the snap, issue is solved.
>
> Thanks
> BR
> NS
>
> On Jun 28, 2017 5:38 PM, "N. S."  wrote:
>
> Hi Juju team,
>
>
> I am upgraded my juju platform to latest release:
>
> ~$ juju --version
> 2.0.2-xenial-amd64
>
>
> However, when I use the tab key for command completion, I get this weird
> "juju_complete_2_0: command not found" instead of normal command completion
> that I used to have in version 2.1.3.
> Please see the below.
>
>
>
> $ juju attac_juju_complete_2_0: command not found
> _juju_complete_2_0: command not found
> h_juju_complete_2_0: command not found
>
> Thanks.
> BR,
> NS.
>
>
> --
> 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: Juju vs Openshift

[Rick Harding]

I think the reason it's challenging, and that you're seeing different tools
for different systems, is that each time you want to model something you
have to make sure you can translate the model into the underlying
substrates clearly and precisely. To date, Juju hasn't expressed a model on
the process container world because Juju's model is built upon a set of
promises that it can make sure each supported substrate can fulfill.
OpenStack, public cloud, MAAS, etc all have these nice primitive ideas that
are similar enough that a model can be expressed and then put into place
onto those different substrates but the promises of the model still hold
true.

As we've looked at expanding the model to support things like process
containers there are challenges and opportunities. The immutability of the
containers breaks a bunch of Juju promises, such as the adaptability when a
relation is made between applications. There's work that needs to be done
such that a model can either make clear the differences (say you can model
applications as well as process containers as different ideas in the model)
or you need to update and close the gaps between the substrates.

I think you're right on point and that we're aligned on the idea that you
construct a model of what you want and then allow the system to go and make
it reality. I think the trouble that we're currently in, and that you're
finding as you look at options, is that there's a gap at the moment that
needs to be closed. Folks are trying to say that we're all techies and love
using the right tool for the right job, and currently there are some things
that go great into process containers, some things that do better in
machine containers, and some things that really want to be on raw hardware
to operate at their best. Over time we hope Juju will expand to help define
the model across each of those scenarios.

On Tue, Jun 27, 2017 at 12:13 PM Giuseppe Attardi 
wrote:

> OK, but since I have been asked to help prepare a roadmap for the next 3
> years for the evolution of cloud services and infrastructure for the
> Italian public administrations, I need to have both a clear picture of the
> current situation and to make an educated guess at the most promising
> technology directions.
>
> My feeling is that one should promote a declarative modelling approach to
> cloud deployment, where one specifies the architecture model he wants to
> achieve, not how.
> A workflow engine takes care of generating an actual deployment plan that
> leads from the current to the desired state.
> Google director of network architecture, Bikash Koley, explains in this
> video why they use this approach in managing their world-wide network
> infrastructure (aka zero-touch networking):
> https://youtu.be/5N7QS5vP68o?t=13m01s
> The approach is quite similar to Juju for cloud applications.
> Openshift uses deployment on containers apparently in a similar fashion.
>
> One really wants to hide the details of the underlying IaaS infrastructure
> to users making deployments.
> Hence OpenStack could still be the platform foundation, but developers and
> users should deal with declarative deployment models and tools.
>
> An automated deployment engine based a declarative modelling for a
> container platfrom seems what one should want.
>
> —
>
> On 27 giu 2017, at 09:39, Tom Barber  wrote:
>
> Hey Giuseppe
>
> Having worked in the data sector for a while now whilst keeping an eye on
> container tech, for now at least I'd keep deploying data services to
> baremetal for a number of reasons, docker container discovery for one. Juju
> hadoop on services vs hadoop on containers is a bit of a no-brainer
> currently. That said of course data on containers support well improve but
> for now I'd stick to the basics.
>
> My 2 cents.
>
> Tom
>
> On 27 Jun 2017 8:32 am, "Giuseppe Attardi" 
> wrote:
>
> Some Italian public administration are considering purchasing cloud
> services for Big Data analytics deployed on Openshift.
> How this solution would compare with using a Kubernetes cluster deployed
> through Juju?
> More in general, what is the strategic outlook of container platforms vs
> virtualization platforms?
> Are the former ones going to overcome the latter?
>
> --
>
> --
> 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Digest, Vol 77, Issue 21

[Rick Harding]

Guiseppe that's very cool and I love hearing stories of how folks are
solving their problems out there. There's some interesting ideas in the
federation and quota use there. I'm sure our OpenStack team will find it
interesting as well. Definitely keep us up to date on how it goes and we'd
love to see any tips and tricks you find make its way back into the
community here or via blog posts shared and the like.



On Mon, Jun 26, 2017 at 1:19 PM Giuseppe Attardi 
wrote:

>
>
> On 26/6/2017 14:00, juju-requ...@lists.ubuntu.com wrote:
>
> Date: Mon, 26 Jun 2017 12:13:10 +0300
> From: Dmitrii Shcherbakov  
> 
> To: Merlijn Sebrechts  
> 
> Cc: juju  
> Subject: Re: Italian federated cloud runs Juju
> Message-ID:
>    
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hi Merlijn,
>
> As far as I know, this is only authentication federation. It might fit into
> a single use-case but you will have independent clouds where projects don't
> have anything in common on different installations (e.g. quotas, security
> groups, resource limits etc. will not be synchronized in any way). VXLAN
> connectivity between sites will not be possible in this case as clouds
> don't know anything about each other.
>
> It is a good project and I am definitely glad that they use our tools for
> that!
>
> If you think about the ETSI Architecture, Juju is a VNF Manager and there
> should be a VNFM per site with an orchestrator on top in that model.
> https://insights.ubuntu.com/wp-content/uploads/058f/Screen-Shot-2015-07-09-at-11.02.33.png
>
> In general, there are multiple approaches to handling multi-site
> deployments (each with its trade-offs) which are mentioned in a great blog
> post written after the OpenStack Summit this year:
> http://serverascode.com/2017/05/09/openstack-multisite-multicloud.html
> https://www.youtube.com/watch?v=3YCogWHREHA
> https://beyondtheclouds.github.io/dcc.htmlhttps://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds
>
> Just wanted to share that in case you are interested in multi-site
> deployments and how does Juju fit in these.
>
> No approach is preferable in my view as there are different requirements
> and use-cases.
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
>
> Yes, it is the same guy, it is me.
>
> This is not just an authencication federation, as Shcherbakov says.
> This is a true federation made of multiple regions, with a single
> coordinating master region.
> This makes the federation into a *single* cloud, where any resource is
> available to any user of the federation.
> We use federated authentication, just for authenticating users, using
> three types of authentication: SAML, OIDC and Keystone.
> But the federation consists of several distinct OpenStack clouds, which
> share common O~S infrastructure services.
> It took us a considerable amount of work to achieve this solution, that
> delegates administration of individual regions to specific domain
> administrators.
> In particular the solution allows us to deal with resource segregation, so
> that only each O~S project is entitled to use just the resources that have
> been assigned to it, by clever use of the quota mechanism.
>
> We are also working on a sophisticated accounting/billing scheme that
> allows each user/organization to visualize the amount of resources they use
> and to be billed accordingly.
> That is were I have developed a charm for Gnocchi.
>
> The link mentioned by Shcherbakov presents a nice discussion about the
> options for building a federation, that we all considered before building
> ours. Tricircla was not ready for production.
> Ours is a deployed and working federation with over 500 current users.
>
> We just run a two day workshop in Rome with 10 people from eastern Europe
> in the EaPConnect European project, where we gave them a full hands-one
> experience on how to build a region and then to integrate it into the
> federation.
> Each participant was given it own set of resources so that they could
> practically build a new OpenStack region in a few hours!
> They were all enthusiastic.
> You can see a picture of the participants here:
>
>
> https://www.facebook.com/photo.php?fbid=10155052806563855=a.10151237649608855.434137.518308854
>
> The slides will be made available soon, including a tutorial on building
> charms (in particular the Jupyter Notebook charm will be a use case).
>
> The technology for O~S multiclouds, still needs improvements, but for now, 
> this is our practical solution.
>
> Please read the paper and provide feedback.
> If there are better solutions, we would be glad to explore 

Re: How to Move a machine and its application from a Model to Another ?

[Rick Harding]

Not at this time Naz. I was thinking about how I might try to do this and I
got thinking about the feature in progress for persistent storage. If the
machine in question was associated with a persistent storage volume, would
it be possible to leverage that in some way.

I wonder if it's something that we should explore in the feature so that
you could add a new unit but specify a persistent storage volume that was
used in another model?

On Wed, Jun 14, 2017 at 5:04 AM N. S.  wrote:

> Hi,
>
>
> How could I move a service (Application/unit/machine) from a hosting model
> A to a model B?
>
> I am not talking about migrating a model, as a whole, from a controller A
> to controller B.
>
> I need to migrate a machine and its service from a Model A to a Model B.
>
>
> Thanks,
>
> BR,
>
> Naz
>
>
>
>
> --
> 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: OS X VMS on JAAS

[Rick Harding]

It always comes back to Juju being a tool pushing for best practice for
operations. It's hard for a hosted service to make any service promises
when things are running on personal laptops and such. It's all do-able, but
there's some form of what is the best practice thing to do. The controller
affinity is something akin to that. Controllers can be dealing with a lot
of communication at scale.

What's interesting here is exploring some idea of the development story
with Juju. I do find it interesting that you've got a sort of pre-seed
workspace you can create and setup.

On Mon, Jun 5, 2017 at 4:03 PM James Beedy  wrote:

> This raises the question: why do we need a provider -> controller affinity
> at all?
>
> On Mon, Jun 5, 2017 at 12:23 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> On 06/03/2017 02:56 AM, John Meinel wrote:
>>
>>> You can add a manually provisioned machine to any model, as long as
>>> there is connectivity from the machine to the controller. Now, I would have
>>> thought initial setup was initiated by the Controller, but its possible
>>> that initial setup is actually initiated from the client.
>>>
>>> Once initial setup is complete, then it is definitely true that all
>>> connections are initiated from the agent running on the controlled machine
>>> to the controller. The controller no longer tries to socket.connect to the
>>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>>> in 2.X the agents listen to see if there are any actions to run like they
>>> do for all other changes.)
>>>
>>> Now, given that he added a model into "us-east-1" if he ever did just a
>>> plain "juju add-machine" or "juju deploy" (without --to) it would
>>> definitely create a new instance in AWS and start configuring it, rather
>>> than from your VM.
>>>
>> Is it possible for us to convey the model's proper location, even when
>> using jaas? He's in effect lying to the controller which does have the
>> knock-on affect of weird behavior.
>>
>>>
>>> Which is why using something like the "lxd provider" would be a more
>>> natural use case, but according to James the sticking point is having to
>>> set up a controller in the first place. So "--to lxd:0" is easier for them
>>> to think about than setting up a provider and letting it decide how to
>>> allocate machines.
>>>
>>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>>> provider, because *that* would have JAAS be trying to make a direct
>>> connection to your LXD agent in order to provision the next machine.
>>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>>> talking to the local LXD agent in order to create a container.
>>>
>> If this is a useful case, could we define it as a mode of operation and
>> have juju just work in such a scenario? It's an interesting mix of allowing
>> the benefits of jaas for manually provisioned machines and environments.
>> Just eliminating the weird behaviors and having to pretend it's a known
>> cloud / provider could be useful. An assume nothing mode if you will.
>>
>> Nicholas
>>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

collecting tips, how-tos, tools used in troubleshooting Juju

[Rick Harding]

I'm working to build out the troubleshooting section of the Juju
documentation. [1] I'd like to collate common issues, tips, scripts, and
tools folks have buried in wikis, google docs, or their brains. I'd like to
ask you send anything you've got, as raw an unproofed as it lives today, my
way. I'll worry about organizing, cleaning up, fine tuning the language,
etc. I just want to ask everyone to help me brainstorm the things they can
think of that'll be useful in a full fleshed out troubleshooting guide. No
issue is too big or too small.

Example useful things that can be generically hit could be I've got X
configured wrong, or I hit the limit on my cloud compute instances allowed,
or this is what happens when Y over there goes down.

Potential moving parts to trigger ideas include:
general help in diagnosing what's going on beyond the logs
issues getting setup (add-cloud/add-credential) (the rackspace id needs to
be in quotes)
errors while bootstrapping
common issues with deploying, scaling, relations
issues with sharing/revoking models
Cloud specific issues and trouble spots
  - MAAS
  - LXD
  - OpenStack
  - AWS/GCE/Azure
  - Manual Provider

Items I'm currently calling out of scope include issues around charming as
I think that's going to be another big chunk with a different enough scope
to focus on separately.

Thanks for the assistance everyone. From here I'll start to build up a
"best practices" guide for operating Juju itself and we'll hopefully have a
lot of useful material going forward that users will be able to self-help
themselves much more easily.

Rick

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

collecting tips, how-tos, tools used in troubleshooting Juju

[Rick Harding]

I'm working to build out the troubleshooting section of the Juju
documentation. [1] I'd like to collate common issues, tips, scripts, and
tools folks have buried in wikis, google docs, or their brains. I'd like to
ask you send anything you've got, as raw an unproofed as it lives today, my
way. I'll worry about organizing, cleaning up, fine tuning the language,
etc. I just want to ask everyone to help me brainstorm the things they can
think of that'll be useful in a full fleshed out troubleshooting guide. No
issue is too big or too small.

Example useful things that can be generically hit could be I've got X
configured wrong, or I hit the limit on my cloud compute instances allowed,
or this is what happens when Y over there goes down.

Potential moving parts to trigger ideas include:
general help in diagnosing what's going on beyond the logs
issues getting setup (add-cloud/add-credential) (the rackspace id needs to
be in quotes)
errors while bootstrapping
common issues with deploying, scaling, relations
issues with sharing/revoking models
Cloud specific issues and trouble spots
  - MAAS
  - LXD
  - OpenStack
  - AWS/GCE/Azure
  - Manual Provider

Items I'm currently calling out of scope include issues around charming as
I think that's going to be another big chunk with a different enough scope
to focus on separately.

Thanks for the assistance everyone. From here I'll start to build up a
"best practices" guide for operating Juju itself and we'll hopefully have a
lot of useful material going forward that users will be able to self-help
themselves much more easily.

Rick

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

Re: Juju maas node ssh permission denied

[Rick Harding]

Hi Feng, what method were you using to ssh to the Juju node?

When you bootstrap with juju it will grab local ssh keys to setup for the
ubuntu user on the juju managed nodes. For example, I temporarily removed
my ssh key from my MAAS user profile and bootstrapped from my laptop a new
controller and I was able to ssh to the controller with 'juju switch
controller && juju ssh 0'. This uses the local keys I have on my laptop
system.

If you want to not use juju ssh then you need to specify the ubuntu user
name on the images. On my MAAS the address of machine 0 is 10.0.0.8

ssh ubuntu@10.0.0.8

Does that not work for you?

On Fri, May 19, 2017 at 8:12 AM fengxia  wrote:

> Hi Juju,
>
> I ran into an issue which I couldn't figure out. I setup a MAAS
> controller, can manually provision node directly using MAAS and was able
> to ssh to it, so I suppose MAAS is all working well.
>
> Then if I use $ juju deploy to start a node, I could not ssh to this
> node. What is the right way to access this node?
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> 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

matchmaking a jupyter community, and a reminder to share your work

[Rick Harding]

Last week for the Juju Show [1] I played with Jupyter Notebook which is a
great way to put together online instructional for code. It was fun to get
going and I was motivated by a charm from a new author [2] I had seen in
the new published api [3].

What was interesting was five minutes after the show Merlijn pointed out
that he had a charm[4] for it that he'd never pushed to the store. Then
after that Andrew from the Juju team mentioned he was playing with it and
had some layers and code [5][6][7][8][9] sitting around for Jupyter.

Clearly, this is awesome that there's so much interest around a great piece
of software. The bigger opportunity is that folks can now start
collaborating and really taking advantage of the shared brain powers of
everyone out there.

So I get to play matchmaker. Guiseppe, Merlijn, Andrew, and everyone else
out there interested in Jupyter I suggest you get together. I'm excited to
see what the combined power can bring to a great Jupyter experience.

If you've got a charm you've been sitting on and not yet pushed to the
charm store I really suggest you do it now. You never know what community
is waiting to pool around chunk of work. They just need that central point
to kick it all off.

Rick

1: https://www.youtube.com/watch?v=oJukQzROo-Q
2: https://jujucharms.com/u/attardi-h/jupyter-notebook/
3: https://api.jujucharms.com/charmstore/v5/changes/published?limit=100
4: https://jujucharms.com/u/tengu-team/jupyter-notebook/
5: https://github.com/axw/interface-jupyterhub-spawner
6: https://github.com/axw/interface-jupyterhub-authenticator
7: https://github.com/axw/layer-jupyterhub
8: https://github.com/axw/jupyterhub-usso-authenticator
9: https://github.com/axw/jupyterhub-lxd-spawner
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to remove credential from JaaS?

[Rick Harding]

Sure thing Merlijn. There's a WIP account page that you can get to via
https://jujucharms.com/account/

That has a list of your creds and allows you to remove them.

I know there was some work to link that account page to the normal header
UX. I'll check with the progress of that next week.

Let me know how that works out.

Rick

On Sat, May 6, 2017 at 3:20 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> Is it possible to remove a credential from JaaS?
>
>
>
> Kind regards
> Merlijn
> --
> 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

step by step for gitlab with the ssl-termination-proxy

[Rick Harding]

In the Juju Show episode this week [1] I mentioned that I was tinkering
with getting Gitlab testing. There was one tweak that needed doing so that
you can get Gitlab to work with it being proxied. You have to configure its
"external_url" config setting and then reconfigure Gitlab.

I've walked through the step by step in my blog post here:
http://mitechie.com/blog/2017/4/27/giving-gitlab-an-afternoon-spin\

I want to thank Tom for responding to my poking around his Gitlab charm and
for the awesome stuff i the ssl-termination-proxy charm from the Tengu
folks. It's a really nice combo [2] and I'll follow up on that awesomeness
in a bit.

1: https://www.youtube.com/watch?v=h2X9gIxXPH8=2s
2: https://jujucharms.com/u/spiculecharms/gitlab-ssl

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

Re: Thank you!

[Rick Harding]

On Thu, Apr 20, 2017 at 7:08 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

>
>
> Any official word on what this will mean for Juju?
>

The changes you hear about don't change the direction of Juju. We're still
focused on building a great platform for modeling and solving the software
problems we see out there.

Thanks for the <3, the teams appreciate it when folks find value in their
hard work.

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

Re: Check out the openvpn charm form the tengu team

[Rick Harding]

The delivery of the config files is interesting. There's nothing planning
in the gui at the moment for this. It's kind of an inverse "resources" idea
where you are building artifacts in the charm that you want clients to be
able to get access to. It's an interesting concept. It's a bit like actions
that generate a backup file or the like. The action can build the backup
and tell you where on disk it is, but then you need to juju scp it down. I
wonder if there's a specific action type that generates artifacts and then
there's a followup plugin/helper that automates the juju scp step for you
in a some nice way.

I think that Chuck was looking to have a relation available. In this way
you could tunnel traffic from an application across the VPN perhaps? In the
world of cross model relations it might enable folks to wire traffic across
clouds/DC in some interesting ways.



On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Thanks for the post!
>
>
> I'd really like to integrate this Charm more with JaaS. I'd like to give
> JaaS users the ability to download the client config files from the Juju
> GUI. Any idea if that's something that's being worked on?
>
> @chuck: I just watched the Juju show, what was the feature you were
> talking about?
>
>
>
> Kind regards
> Merlijn
>
> 2017-04-13 16:35 GMT+02:00 Rick Harding <rick.hard...@canonical.com>:
>
>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the
>> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does
>> some great work using metrics in Juju to output operational data. Running
>> juju metrics --all will show you how many clients are connected on each
>> unit. If you're a charmer, it might give you some new ideas for exposing
>> internal data in a really nice standard way.
>>
>> I just wanted to highlight it as something really useful for folks if
>> you've ever found yourself wishing you had a VPN around somewhere.
>>
>> 1:
>> http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket
>> 2: https://jujucharms.com/openvpn/
>>
>> Rick
>>
>> --
>> 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

Check out the openvpn charm form the tengu team

[Rick Harding]

I wrote up a quick blog post [1] as I was tinkering with VPNs and the
OpenVPN charm [2] from the Tengu team is really nice and easy. It also does
some great work using metrics in Juju to output operational data. Running
juju metrics --all will show you how many clients are connected on each
unit. If you're a charmer, it might give you some new ideas for exposing
internal data in a really nice standard way.

I just wanted to highlight it as something really useful for folks if
you've ever found yourself wishing you had a VPN around somewhere.

1:
http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket
2: https://jujucharms.com/openvpn/

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

Giving everyone a little data science, Juju and Zeppelin

[Rick Harding]

I wanted to point folks at something kind of fun. I was recently playing
with some data that I wanted to visualize and, after talking with folks, I
was pointed over to Zeppelin which is one of the big data charms. My data
wasn't big, and I wasn't using Hadoop. I only had some stuff in sqlite that
I wanted to query and give folks the ability to write their own queries.

It turns out that Zeppelin works with SQL based data (Postgres, MySQL, and
SQLite). So while I'm not playing with Hadoop it was awesome to learn about
cool ways to leverage existing charms to get things done fast. At a recent
sprint it took me less than a day to get a dashboard up and share it with
others.

Check out the blog post and I'd love to hear about other charms and tools
that are really useful outside of the normal field you associate it with.

http://mitechie.com/blog/2017/3/29/giving-everyone-a-little-data-science

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

Re: A new release of Juju, 2.2-beta1 and conjure-up are here!

[Rick Harding]

This is awesome Adam. Testing and bugs filing. Thanks for the work on this.

On Tue, Mar 28, 2017 at 6:56 AM Adam Stokes 
wrote:

> conjure-up was merged into hombrew last night, please give the macOS
> version a try and let us know if there are any issues:
>
> brew install conjure-up
>
> Thanks!
>
> On Fri, Mar 24, 2017 at 4:21 PM Curtis Hovey-Canonical <
> cur...@canonical.com> wrote:
>
> A new release of Juju, 2.2-beta1, and conjure-up, are here!
>
>
> ## What's new in 2.2-beta1
>
> - juju login updates
> - [conjure-up] Integrated JAAS support
> - [conjure-up] Steps now support handling actions that require sudo
>   (ie sudo snap install kubectl --classic --edge)
> - [conjure-up] macOS port (waiting on merge
>   https://github.com/Homebrew/homebrew-core/pull/11488)
> - [conjure-up] Lots of step processing polishes
>
>
> ### juju login updates
>
> Juju login command now accepts the name or hostname of a public
> controller as a parameter.
>
> juju login jaas
>
> This would add the jaas public controller to the list of the controllers
> you can use, it will also get cached in the controllers.yaml. Public
> controllers usually use external identity providers. JAAS uses Ubuntu
> SSO as an external provider, so in order to use this controller, you
> have to register at Ubuntu SSO. In order to get access to the JAAS
> public controller, please register through jujucharms.com or using this
> URL:
>
> https://jujucharms.com/login
>
> The previous version of the command accepted the user name as a
> parameter. In order to login as a local user, you can specify a user
> name as the argument to the -u flag.
>
> juju login -u bob
>
> Note that this release includes only the initial implementation of the
> juju login command changes. Polishing and improved UX will come with
> following releases.
>
>
> ## Resolved Issues
>
> Check the milestones for a detailed breakdown of Juju and conjure-up
> bugs corrected.
>
> https://github.com/conjure-up/conjure-up/milestone/19?closed=1
> https://launchpad.net/juju/+milestone/2.2-beta1
>
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get Juju from the juju stable ppa:
>
>sudo add-apt-repository ppa:juju/devel; sudo apt-get update
>
>sudo apt-get install juju
>
> Or install Juju from the snap store:
>
>snap install juju --classic --beta
>
> Install conjure-up from the snap store:
>
>snap install conjure-up --classic --beta
>
> If you are on Trusty, you'll need to run a few extra commands:
>
>sudo apt-get install snapd
>sudo groupadd lxd && sudo usermod -a -G lxd $USER
>sudo reboot
>
> Now you can install snaps, including conjure-up, as normal:
>
>snap install conjure-up --classic --beta
>
> macOS users can install conjure-up with brew:
>
>brew install conjure-up --devel
>
> Windows, CentOS, and MacOS users can get a corresponding Juju
> installer at:
>
>https://launchpad.net/juju/+milestone/2.2-beta1
>
>
> ## 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 these great technologies please visit
> https://jujucharms.com and http://conjure-up.io.
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A new release of Juju, 2.2-beta1 and conjure-up are here!

[Rick Harding]

One heads up is that this beta includes a memory improvement from Tim that
cut memory consumption over 75% when you get into the hundreds of models
for a controller. Folks that really iterate on controllers should notice
considerable improvement. If you're hitting this at all make sure to test
the beta and look forward to 2.2 final release.

On Fri, Mar 24, 2017 at 4:21 PM Curtis Hovey-Canonical 
wrote:

> A new release of Juju, 2.2-beta1, and conjure-up, are here!
>
>
> ## What's new in 2.2-beta1
>
> - juju login updates
> - [conjure-up] Integrated JAAS support
> - [conjure-up] Steps now support handling actions that require sudo
>   (ie sudo snap install kubectl --classic --edge)
> - [conjure-up] macOS port (waiting on merge
>   https://github.com/Homebrew/homebrew-core/pull/11488)
> - [conjure-up] Lots of step processing polishes
>
>
> ### juju login updates
>
> Juju login command now accepts the name or hostname of a public
> controller as a parameter.
>
> juju login jaas
>
> This would add the jaas public controller to the list of the controllers
> you can use, it will also get cached in the controllers.yaml. Public
> controllers usually use external identity providers. JAAS uses Ubuntu
> SSO as an external provider, so in order to use this controller, you
> have to register at Ubuntu SSO. In order to get access to the JAAS
> public controller, please register through jujucharms.com or using this
> URL:
>
> https://jujucharms.com/login
>
> The previous version of the command accepted the user name as a
> parameter. In order to login as a local user, you can specify a user
> name as the argument to the -u flag.
>
> juju login -u bob
>
> Note that this release includes only the initial implementation of the
> juju login command changes. Polishing and improved UX will come with
> following releases.
>
>
> ## Resolved Issues
>
> Check the milestones for a detailed breakdown of Juju and conjure-up
> bugs corrected.
>
> https://github.com/conjure-up/conjure-up/milestone/19?closed=1
> https://launchpad.net/juju/+milestone/2.2-beta1
>
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get Juju from the juju stable ppa:
>
>sudo add-apt-repository ppa:juju/devel; sudo apt-get update
>
>sudo apt-get install juju
>
> Or install Juju from the snap store:
>
>snap install juju --classic --beta
>
> Install conjure-up from the snap store:
>
>snap install conjure-up --classic --beta
>
> If you are on Trusty, you'll need to run a few extra commands:
>
>sudo apt-get install snapd
>sudo groupadd lxd && sudo usermod -a -G lxd $USER
>sudo reboot
>
> Now you can install snaps, including conjure-up, as normal:
>
>snap install conjure-up --classic --beta
>
> macOS users can install conjure-up with brew:
>
>brew install conjure-up --devel
>
> Windows, CentOS, and MacOS users can get a corresponding Juju
> installer at:
>
>https://launchpad.net/juju/+milestone/2.2-beta1
>
>
> ## 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 these great technologies please visit
> https://jujucharms.com and http://conjure-up.io.
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] Elastisys Charmscaler Promulgated!

[Rick Harding]

The question there is how different businesses will have different rules. I
think it makes sense for a relation to describe what the charm author
thinks is useful parameters/etc and maybe some default scaling config but I
think that different folks will have different tastes to this. Especially
as workloads are deployed on different sized instances in the cloud.

I think that having things as a relation is much more interesting when we
have relation config so that the charms can define some standard
definitions and the user making the relation can tweak how they work in
practice.

On Tue, Mar 21, 2017 at 8:01 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Awesome stuff!
>
> Would it make sense to expose the autoscaling options over an
> interface/relationship? So that you can connect the autoscaler to a charm
> and the charm tells the autoscaler how it should be scaled
>
>
> 2017-03-20 21:54 GMT+01:00 Simon Kollberg :
>
>
>
> On 20 March 2017 at 18:13, Charles Butler 
> wrote:
>
> Greetings,
>
> I realized last week I had completed a review and failed to send an update
> to the mailing list. As some of you may have heard on the Juju Show that
> Elastisys released their Charm Scaler to the promulgated channel.
>
>
> This was an easy +1 from me, with comprehensive test suites, and example
> cases for auto-horizontal-scaling workloads based on CPU load.
>
> https://jujucharms.com/charmscaler/
>
>
> Thanks a lot for the review, Charles!
>
> We're really looking forward to see the community use our autoscaler to
> increase performance and availability for all of the awesome charms out
> there and we hope the CharmScaler can become a great addition to the Juju
> ecosystem. The CharmScaler is very much in it's infancy when it comes to
> functionality but we are planning on extending it with a lot of features
> that is already available in the Elastisys platform such as support for
> more built-in and custom metrics, smarter scaling-algorithms and
> robustness. We also welcome PRs, feature requests and/or bug reports on the
> charm's GitHub page https://github.com/elastisys/layer-charmscaler .
>
>
> This particular charm is near and dear to my own interests, as they have
> published a POC bundle using Canonical Distribution of Kubernetes as the
> subject matter. Enjoy horizontally scaled workers when you reach node
> pressure thresholds on CPU.
>
> https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0
>
>
> Seeing how easy Juju makes bundling charms together building and deploying
> the autoscaled Kubernetes was a sheer pleasure. To be honest, what took me
> the most time was creating a (sort of) nice look for the GUI. :) However, I
> think we should go one step further. Rather than having to create a
> completely new bundle every time you want to extend a "core" bundle with
> one or more charms, why not enable bundles in the bundle manifests? That
> way two or more bundles could be combined just like charms. I know I'm not
> the first one to bring this up, so if this has already been requested on
> the mailing-list excuse this and just count it as a +1!
>
>
>
>
> Congratulations on your promulgation status to our friends at Elastisys!
> I look forward to seeing the bundles this charm unlocks the auto-scaling
> goodness thanks to tight integration with Juju.
>
>
> We are very excited to see our charm getting the Juju stamp of approval!
> Thanks again.
>
>
>
> All the best,
>
> Charles
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> conjure-up canonical-kubernetes | jujucharms.com
>
> --
> 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
>
>
> --
> 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: monitoring your production juju controllers

[Rick Harding]

Jacek, let's talk on the mongodb exporter sometime. I tried to get it
running but was unable to figure out how to get it to talk to the juju
mongodb. All I could get out of it was generic connection errors.

The relation thing you note is interesting. There's talk on the roadmap of
exposing controllers as relatable applications which makes a lot of this
easier as controllers can then just expose a prometheus endpoint and it
would do things like allow placing the Telegraf subordinate without first
using the Ubuntu charm as a relation endpoint.

As for the Grafana datasource, no reason at all. I just walked through
setting it up and I missed the relation there. I'll have to test that out
and update the article. Thanks for the heads up!


On Tue, Mar 21, 2017 at 5:01 AM Jacek Nykis <jacek.ny...@canonical.com>
wrote:

> On 20/03/17 18:04, Rick Harding wrote:
> > During The Juju Show #8 [1] last week we talked about how to setup your
> > controllers to be provide metrics through Prometheus to Grafana to keep
> > an eye on those controllers in production.
> >
> > I put together a blog post [2] about how to set it up, configure Juju,
> > and links to the sample json for an out of the box dashboard to use.
> > Give it a try and let me know what you would add to keep an eye on your
> > own production Juju.
> >
> > Rick
> >
> > 1: https://www.youtube.com/watch?v=tjp_JHSZCyA
> > 2: http://mitechie.com/blog/2017/3/20/operations-in-production
>
> Hi,
>
> We also added mongodb exporter [0] for more in depth mongodb metrics. It
> currently requires manual set up because juju mongo does not support
> relations but once that is done it works great!
>
> I have one question about your article - is there any specific reason
> you configure grafana datasource by hand as opposed to using
> "grafana-source" relation? This should work just fine:
>
> juju add-relation prometheus:grafana-source grafana:grafana-source
>
> Jacek
>
> [0] https://github.com/dcu/mongodb_exporter
>
> --
> 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

monitoring your production juju controllers

[Rick Harding]

During The Juju Show #8 [1] last week we talked about how to setup your
controllers to be provide metrics through Prometheus to Grafana to keep an
eye on those controllers in production.

I put together a blog post [2] about how to set it up, configure Juju, and
links to the sample json for an out of the box dashboard to use. Give it a
try and let me know what you would add to keep an eye on your own
production Juju.

Rick

1: https://www.youtube.com/watch?v=tjp_JHSZCyA
2: http://mitechie.com/blog/2017/3/20/operations-in-production
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: MySQL charm bugs

[Rick Harding]

Looking at the page: https://jujucharms.com/mysql on the right is the link
to "submit a bug" which goes to:
https://github.com/marcoceppi/charm-mysql/issues

You can also get the bug url with the charm command.

charm show mysql bugs-url
bugs-url: https://github.com/marcoceppi/charm-mysql/issues


On Wed, Mar 8, 2017 at 2:59 PM John Meinel  wrote:

> I just saw a couple of bugs targeted at Juju that were about the MySQL
> charm:
>  https://bugs.launchpad.net/charms/+source/mysql/+bug/1670431
> and
>  https://bugs.launchpad.net/charms/+source/mysql/+bug/1670430
>
> I retargeted them at the mysql charm. Is that the correct place to put
> them?
>
> Thanks,
> John
> =:->
>
> --
> 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: ssh keys

[Rick Harding]

This is definitely on the todo list. It's completely correct that users
should be able to manage their own keys.

On Wed, Mar 8, 2017 at 11:01 AM James Beedy  wrote:

> I'm quickly finding myself maintaining users ssh keys. How do people feel
> about making ssh keys bound to the user instead of the model? This way,
> when a user is added to a model ssh access comes with the package.
> Moreover, can we allow users to manage their own keys?
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: ssh keys

[Rick Harding]

This is definitely on the todo list. It's completely correct that users
should be able to manage their own keys.

On Wed, Mar 8, 2017 at 11:01 AM James Beedy  wrote:

> I'm quickly finding myself maintaining users ssh keys. How do people feel
> about making ssh keys bound to the user instead of the model? This way,
> when a user is added to a model ssh access comes with the package.
> Moreover, can we allow users to manage their own keys?
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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

Re: All our Charms became hidden because we promulgated some

[Rick Harding]

Merlijn, you're correct that when you search for a solution we prefer and
promote the promulgated charms in place of the community ones.

You can find the list of charms for a user directly by clicking on the user
name in that list or going to the user pages which have a /u vs the /q for
query.

https://jujucharms.com/u/tengu-team/
https://jujucharms.com/u/tengu-bot

I do agree that the search results in this case, where you're searching for
a user vs a charm/solution isn't helpful and we should link to the users in
the search results to help you more directly get you to the /u/ url
from those search results.

Hopefully that helps until we can address exposing users more directly in
the search results.

On Fri, Feb 17, 2017 at 7:41 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> Just stumbled on a serious issue. Until recently, all our charms where
> visible when searching for our team name in the charm store. Now, only our
> promulgated charms show up in the search result. Our colleagues use the
> search function to find our charms but they can't find them anymore.
>
> Query to username with promulgated charms:
> https://jujucharms.com/q/tengu-team
> Query to username without promulgated charms:
> https://jujucharms.com/q/tengu-bot
>
> As you can see in both queries, either the "recommended" or the
> "community" charms show up, they don't show both.
>
> This is a serious issue because *this makes it impossible to view/use our
> charms in the Juju UI*. The jujucharms.com storefront has a "user" page
> where we can see all our charms, but this page doesn't exist in the Juju
> UI. https://jujucharms.com/u/tengu-team/
>
> Is it possible to temporarily un-promulgate the openvpn and eclipse-che
> charms until this bug is fixed? This is really an issue since our
> colleagues can't find our charms anymore.
>
>
>
> Kind regards
> Merlijn
> --
> 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: Juju 2.1-beta5 is here

[Rick Harding]

Narinder, so the beta5 includes the container networking changes that are
required to help make sure that Juju stops guessing bindings incorrectly.
If you look at the error messages in those commands you can see a new error
that the beta5 presents:

  message: 'unable to setup network: no obvious space for container
"0/lxd/10",
host machine has spaces: "admin-api", "external",
"internal-api"'

This generally means that you need to be explicit in the bindings. I see in
your bundle paste that you have bindinds for each application on machine 0.
I would suggest checking if there are any endpoints that are missing form
the definition? There's a mechanism to define a default binding for the
application, but I'm unable to recall/find that at the moment. I've /cc'd
John who's been working on this and might have another hint for you.

I'd check the bindings for the ones that don't come up and see if that
helps.

Rick

On Sat, Feb 4, 2017 at 1:06 PM Narinder Gupta <narinder.gu...@canonical.com>
wrote:

> Here you go.
>
> juju status --format yaml
>
> http://paste.ubuntu.com/23927017/
>
> juju show-machine 0
>
> http://paste.ubuntu.com/23927020/
>
> pastebinit bundles.yaml
>
> http://paste.ubuntu.com/23927027/
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150 <(281)%20736-5150>  
>   narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Sat, Feb 4, 2017 at 9:20 AM, Rick Harding <rick.hard...@canonical.com>
> wrote:
>
> Narinder, can you share the output of juju status --format=yaml and juju
> show-machine 0
>
>
> On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta <narinder.gu...@canonical.com>
> wrote:
>
> Hi Nicholas,
> I am finding issues when do the deployment. Bundle i used to deploy with
> juju 2.1-beta4 does not get deployed with juju-2.1-beta5.
>
> Reason of that is mongodb lxd container still waiting to get machine which
> was not the case for juju 2.1-beta4
> mongodb/0 waiting  allocating  0/lxd/3
>   waiting for machine
>
> You can see here http://pastebin.ubuntu.com/23924329/ all services came
> up except mongodb and openfv-promise. I can confirm that if I switch to
> beta4 everything works. Here is the bundle i am deploying
> http://paste.ubuntu.com/23924334/
>
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150 <(281)%20736-5150>  
>   narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The
> most visible changes are to container networking and that juju controllers
> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up
> is also a snap, provides juju, and can be installed on trusty as a snap as
> well!
>
> We would especially like feedback on the container networking changes. Do
> let us know of your experiences, and feel free to open bugs and threads to
> discuss.
>
> ## What’s New in Beta 5
>
> [conjure-up] Now snapped for Trusty and Xenial.
> [conjure-up] Support for Canonical Kubernetes 1.5.2.
> [conjure-up] Ability to teardown models with the new `conjure-down`
> command.
> [juju] Container networking improvements:
> - LXD and KVM guests no longer join all spaces on the host
> machine, but use constraints and bindings to determine what spaces should
> be used
> - Bridges are not created during provisioning, but only created on demand
> for containers that will use them.
> - For clouds other than MAAS, we continue to put containers onlocal
> bridges (lxdbr0)
>[juju] Juju ssh/scp now selects correct address to use to connect to
> the controller.
> [juju] Model config now supports an "extra-info" field for holding
> additional metadata.
> [juju] More memory leaks have been addressed.
> [juju] Stricter rules for validating charm metadata field names to
> conform to data storage requirements. Charm metadata fields can not contain
> dots.
> [juju] controllers now expose HTTPS endpoints under “/introspection/”,
> accessible to controller superusers, and users with read access to the
> controller model:/introspection/debug/pprof/profile,
> /introspection/depengin

Re: Juju 2.1-beta5 is here

[Rick Harding]

Narinder, so the beta5 includes the container networking changes that are
required to help make sure that Juju stops guessing bindings incorrectly.
If you look at the error messages in those commands you can see a new error
that the beta5 presents:

  message: 'unable to setup network: no obvious space for container
"0/lxd/10",
host machine has spaces: "admin-api", "external",
"internal-api"'

This generally means that you need to be explicit in the bindings. I see in
your bundle paste that you have bindinds for each application on machine 0.
I would suggest checking if there are any endpoints that are missing form
the definition? There's a mechanism to define a default binding for the
application, but I'm unable to recall/find that at the moment. I've /cc'd
John who's been working on this and might have another hint for you.

I'd check the bindings for the ones that don't come up and see if that
helps.

Rick

On Sat, Feb 4, 2017 at 1:06 PM Narinder Gupta <narinder.gu...@canonical.com>
wrote:

> Here you go.
>
> juju status --format yaml
>
> http://paste.ubuntu.com/23927017/
>
> juju show-machine 0
>
> http://paste.ubuntu.com/23927020/
>
> pastebinit bundles.yaml
>
> http://paste.ubuntu.com/23927027/
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150 <(281)%20736-5150>  
>   narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Sat, Feb 4, 2017 at 9:20 AM, Rick Harding <rick.hard...@canonical.com>
> wrote:
>
> Narinder, can you share the output of juju status --format=yaml and juju
> show-machine 0
>
>
> On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta <narinder.gu...@canonical.com>
> wrote:
>
> Hi Nicholas,
> I am finding issues when do the deployment. Bundle i used to deploy with
> juju 2.1-beta4 does not get deployed with juju-2.1-beta5.
>
> Reason of that is mongodb lxd container still waiting to get machine which
> was not the case for juju 2.1-beta4
> mongodb/0 waiting  allocating  0/lxd/3
>   waiting for machine
>
> You can see here http://pastebin.ubuntu.com/23924329/ all services came
> up except mongodb and openfv-promise. I can confirm that if I switch to
> beta4 everything works. Here is the bundle i am deploying
> http://paste.ubuntu.com/23924334/
>
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta 
> [irc.freenode.net]+1.281.736.5150 <(281)%20736-5150>  
>   narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The
> most visible changes are to container networking and that juju controllers
> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up
> is also a snap, provides juju, and can be installed on trusty as a snap as
> well!
>
> We would especially like feedback on the container networking changes. Do
> let us know of your experiences, and feel free to open bugs and threads to
> discuss.
>
> ## What’s New in Beta 5
>
> [conjure-up] Now snapped for Trusty and Xenial.
> [conjure-up] Support for Canonical Kubernetes 1.5.2.
> [conjure-up] Ability to teardown models with the new `conjure-down`
> command.
> [juju] Container networking improvements:
> - LXD and KVM guests no longer join all spaces on the host
> machine, but use constraints and bindings to determine what spaces should
> be used
> - Bridges are not created during provisioning, but only created on demand
> for containers that will use them.
> - For clouds other than MAAS, we continue to put containers onlocal
> bridges (lxdbr0)
>[juju] Juju ssh/scp now selects correct address to use to connect to
> the controller.
> [juju] Model config now supports an "extra-info" field for holding
> additional metadata.
> [juju] More memory leaks have been addressed.
> [juju] Stricter rules for validating charm metadata field names to
> conform to data storage requirements. Charm metadata fields can not contain
> dots.
> [juju] controllers now expose HTTPS endpoints under “/introspection/”,
> accessible to controller superusers, and users with read access to the
> controller model:/introspection/debug/pprof/profile,
> /introspection/depengin

Re: Juju 2.1-beta5 is here

[Rick Harding]

Narinder, can you share the output of juju status --format=yaml and juju
show-machine 0

On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta 
wrote:

> Hi Nicholas,
> I am finding issues when do the deployment. Bundle i used to deploy with
> juju 2.1-beta4 does not get deployed with juju-2.1-beta5.
>
> Reason of that is mongodb lxd container still waiting to get machine which
> was not the case for juju 2.1-beta4
> mongodb/0 waiting  allocating  0/lxd/3
>   waiting for machine
>
> You can see here http://pastebin.ubuntu.com/23924329/ all services came
> up except mongodb and openfv-promise. I can confirm that if I switch to
> beta4 everything works. Here is the bundle i am deploying
> http://paste.ubuntu.com/23924334/
>
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta [irc.freenode.net]
> +1.281.736.5150narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The
> most visible changes are to container networking and that juju controllers
> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up
> is also a snap, provides juju, and can be installed on trusty as a snap as
> well!
>
> We would especially like feedback on the container networking changes. Do
> let us know of your experiences, and feel free to open bugs and threads to
> discuss.
>
> ## What’s New in Beta 5
>
> [conjure-up] Now snapped for Trusty and Xenial.
> [conjure-up] Support for Canonical Kubernetes 1.5.2.
> [conjure-up] Ability to teardown models with the new `conjure-down`
> command.
> [juju] Container networking improvements:
> - LXD and KVM guests no longer join all spaces on the host
> machine, but use constraints and bindings to determine what spaces should
> be used
> - Bridges are not created during provisioning, but only created on demand
> for containers that will use them.
> - For clouds other than MAAS, we continue to put containers onlocal
> bridges (lxdbr0)
>[juju] Juju ssh/scp now selects correct address to use to connect to
> the controller.
> [juju] Model config now supports an "extra-info" field for holding
> additional metadata.
> [juju] More memory leaks have been addressed.
> [juju] Stricter rules for validating charm metadata field names to
> conform to data storage requirements. Charm metadata fields can not contain
> dots.
> [juju] controllers now expose HTTPS endpoints under “/introspection/”,
> accessible to controller superusers, and users with read access to the
> controller model:/introspection/debug/pprof/profile,
> /introspection/depengine/,/introspection/metrics.
>
>
> ## Bugs Addressed
>
> Check the milestones for a detailed breakdown of juju and conjure-up bugs
> corrected.
>
> https://launchpad.net/juju/+milestone/2.1-beta5
>
> https://github.com/conjure-up/conjure-up/milestone/14?closed=1
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get Juju from the juju devel ppa:
>
>sudo add-apt-repository ppa:juju/devel; sudo apt-get update
>
>sudo apt-get install juju
>
> Or install Juju from the snap store:
>
>snap install juju --beta --devmode
>
> Install conjure-up from the snap store:
>
> snap install conjure-up --classic --beta
>
> If you are on Trusty, you'll need to run a few extra commands:
>sudo apt-get install snapd
>sudo groupadd lxd && sudo usermod -a -G lxd $USER
>sudo reboot
>
> Now you can install snaps, including conjure-up, as normal:
>snap install conjure-up --classic --beta
>
> Windows, Centos, and macOS users can get a corresponding Juju installer at:
>
>https://launchpad.net/juju/+milestone/2.1-beta5
>
> ## 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.
>
>
>
> --
> 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1-beta5 is here

[Rick Harding]

Narinder, can you share the output of juju status --format=yaml and juju
show-machine 0

On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta 
wrote:

> Hi Nicholas,
> I am finding issues when do the deployment. Bundle i used to deploy with
> juju 2.1-beta4 does not get deployed with juju-2.1-beta5.
>
> Reason of that is mongodb lxd container still waiting to get machine which
> was not the case for juju 2.1-beta4
> mongodb/0 waiting  allocating  0/lxd/3
>   waiting for machine
>
> You can see here http://pastebin.ubuntu.com/23924329/ all services came
> up except mongodb and openfv-promise. I can confirm that if I switch to
> beta4 everything works. Here is the bundle i am deploying
> http://paste.ubuntu.com/23924334/
>
>
>
> Thanks and Regards,
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
> Canonical, Ltd.narindergupta [irc.freenode.net]
> +1.281.736.5150narindergupta2007[skype]
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
> On Fri, Feb 3, 2017 at 5:54 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
> The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The
> most visible changes are to container networking and that juju controllers
> now expose Prometheus metrics over an HTTPS endpoint. Finally, conjure-up
> is also a snap, provides juju, and can be installed on trusty as a snap as
> well!
>
> We would especially like feedback on the container networking changes. Do
> let us know of your experiences, and feel free to open bugs and threads to
> discuss.
>
> ## What’s New in Beta 5
>
> [conjure-up] Now snapped for Trusty and Xenial.
> [conjure-up] Support for Canonical Kubernetes 1.5.2.
> [conjure-up] Ability to teardown models with the new `conjure-down`
> command.
> [juju] Container networking improvements:
> - LXD and KVM guests no longer join all spaces on the host
> machine, but use constraints and bindings to determine what spaces should
> be used
> - Bridges are not created during provisioning, but only created on demand
> for containers that will use them.
> - For clouds other than MAAS, we continue to put containers onlocal
> bridges (lxdbr0)
>[juju] Juju ssh/scp now selects correct address to use to connect to
> the controller.
> [juju] Model config now supports an "extra-info" field for holding
> additional metadata.
> [juju] More memory leaks have been addressed.
> [juju] Stricter rules for validating charm metadata field names to
> conform to data storage requirements. Charm metadata fields can not contain
> dots.
> [juju] controllers now expose HTTPS endpoints under “/introspection/”,
> accessible to controller superusers, and users with read access to the
> controller model:/introspection/debug/pprof/profile,
> /introspection/depengine/,/introspection/metrics.
>
>
> ## Bugs Addressed
>
> Check the milestones for a detailed breakdown of juju and conjure-up bugs
> corrected.
>
> https://launchpad.net/juju/+milestone/2.1-beta5
>
> https://github.com/conjure-up/conjure-up/milestone/14?closed=1
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get Juju from the juju devel ppa:
>
>sudo add-apt-repository ppa:juju/devel; sudo apt-get update
>
>sudo apt-get install juju
>
> Or install Juju from the snap store:
>
>snap install juju --beta --devmode
>
> Install conjure-up from the snap store:
>
> snap install conjure-up --classic --beta
>
> If you are on Trusty, you'll need to run a few extra commands:
>sudo apt-get install snapd
>sudo groupadd lxd && sudo usermod -a -G lxd $USER
>sudo reboot
>
> Now you can install snaps, including conjure-up, as normal:
>snap install conjure-up --classic --beta
>
> Windows, Centos, and macOS users can get a corresponding Juju installer at:
>
>https://launchpad.net/juju/+milestone/2.1-beta5
>
> ## 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.
>
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
>
>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Showing Juju GUI in controller model

[Rick Harding]

On Mon, Jan 16, 2017 at 11:57 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Jeff
>
>
> I'd like to use lets encrypt certs with the GUI. I'm not sure how to do
> that in a way that I don't break anything. I remember the Charm had config
> options for ssl certs.
>
> Another advantage of the charm is that it provided the HTTP relationship
> so you can connect it to a reverseproxy etc..
>
>
I'm copying this from another thread. There's a form of lets encyrpt in
Juju currently that was added to Juju 2.0. I've not tried this out yet, but
will pass this info along and tomorrow I'll work on getting some notes/docs
together and give it a go.

https://github.com/juju/juju/blob/6cf1bc9d917a4c56d0034fd6e0d6f394d6eddb6e/controller/config.go#L46

 copied info below

When bootstrapping, you can set the controller config attribute
"autocert-dns-name" to a DNS name that points to your controller. If you
then use that DNS name instead of the controller's IP, or some other DNS
name, the controller will use autocert-generated certificates. By default
we use Let's Encrypt, but you can override the provider with additional
controller config.

Once you've bootstrapped like that, clients can use the autocert-dns-name
value as the controller address, and they do not need to specify a CA
certificate for verification.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: lxd and constraints

[Rick Harding]

In the end, you say you want an instance with 2gb of ram and if the cloud
has an instance with that exact limit it is in fact an exact limit. The key
things here is the clouds don't have infinite malleable instance types like
containers (this works for kvm and for lxd). So I'm not sure the mis-match
is as far apart as it seems. root disk means give me a disk this big, if
you ask for 2 core as long as you can match an instance type with 2 cores
it's exactly the max you get.

It seems part of this can be more adjusting the language from "minimum" to
something closer to "requested X" where request gives it more of a "I want
X" without the min/max boundaries.



On Fri, Jan 13, 2017 at 3:14 AM John Meinel  wrote:

> So we could make it so that constraints are actually 'exactly' for LXD,
> which would then conform to both minimum and maximum, and would still be
> actually useful for people deploying to containers. We could certainly
> probe the host machine and say "you asked for 48 cores, and the host
> machine doesn't have it".
>
> However, note that explicit placement also takes precedence over
> constraints anyway. If you do:
>   juju deploy mysql --constraints mem=4G
> today, and then do:
>  juju add-unit --to 2
> We don't apply the constraint limitations to that specific unit. Arguably
> we should at *least* be warning that the constraints for the overall
> application don't appear to be valid for this instance.
>
> I guess I'd rather see constraints still set limits for containers,
> because people really want that functionality, and that we warn any time
> you do a direct placement and the constraints aren't satisfied. (but warn
> isn't failing the attempt)
>
> John
> =:->
>
> On Fri, Jan 13, 2017 at 10:09 AM, Stuart Bishop <
> stuart.bis...@canonical.com> wrote:
>
> On 13 January 2017 at 02:20, Nate Finch  wrote:
>
> I'm implementing constraints for lxd containers and provider... and
> stumbled on an impedance mismatch that I don't know how to handle.
>
>
>
> I'm not really sure how to resolve this problem.  Maybe it's not a
> problem.  Maybe constraints just have a different meaning for containers?
> You have to specify the machine number you're deploying to for any
> deployment past the first anyway, so you're already manually choosing the
> machine, at which point, constraints don't really make sense anyway.
>
>
> I don't think Juju can handle this. Either constraints have different
> meanings with different cloud providers, or lxd needs to accept minimum
> constraints (along with any other cloud providers with this behavior).
>
> If you decide constraints need to consistently mean minimum, then I'd
> argue it is best to not pass them to current-gen lxd at all. Enforcing that
> containers are restricted to the minimum viable resources declared in a
> bundle does not seem helpful, and Juju does not have enough information to
> choose suitable maximums (and if it did, would not know if they would
> remain suitable tomorrow).
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A new development release of Juju, 2.1-beta4, is here!

[Rick Harding]

You will notice this is beta4 vs the rc1 we had been working toward.

Part of 2.1 is an improvement to juju container networking that corrects
issues that many users are facing. This updates Juju to only create bridges
on a host machine only when a container is placed on the host and only for
the specific network interfaces that the container needs to function. This
code has been moving along and has been demonstrated to work properly when
used correctly.

However, in working to complete those changes it came up that we're missing
the ability to specify the correct network spaces that the application and
thus the container need to be on in the current bundle spec and format. We
support specifying on a per-endpoint basis with the changes done in Juju
2.0, however there's not a key to set the default value the charm wants to
use for any hook/endpoint that it leverages. These updates will hold the
RC1 while those are updated and landed.

If anyone is curious and would like to try out the new networking container
behavior please try out the feature branch that the work is taking place in
here:

https://github.com/juju/juju/tree/2.1-dynamic-bridges

We refer to this as dynamic bridging because the changes cause bridges to
be dynamically generated as required based on direct spaces information.

If you have any questions please let me know.

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

Re: A new development release of Juju, 2.1-beta4, is here!

[Rick Harding]

You will notice this is beta4 vs the rc1 we had been working toward.

Part of 2.1 is an improvement to juju container networking that corrects
issues that many users are facing. This updates Juju to only create bridges
on a host machine only when a container is placed on the host and only for
the specific network interfaces that the container needs to function. This
code has been moving along and has been demonstrated to work properly when
used correctly.

However, in working to complete those changes it came up that we're missing
the ability to specify the correct network spaces that the application and
thus the container need to be on in the current bundle spec and format. We
support specifying on a per-endpoint basis with the changes done in Juju
2.0, however there's not a key to set the default value the charm wants to
use for any hook/endpoint that it leverages. These updates will hold the
RC1 while those are updated and landed.

If anyone is curious and would like to try out the new networking container
behavior please try out the feature branch that the work is taking place in
here:

https://github.com/juju/juju/tree/2.1-dynamic-bridges

We refer to this as dynamic bridging because the changes cause bridges to
be dynamically generated as required based on direct spaces information.

If you have any questions please let me know.

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

Re: problem when building a charm for giraph

[Rick Harding]

On Thu, Jan 5, 2017 at 8:17 AM Panagiotis Liakos  wrote:

>
> Moreover, I have just released the latest version of my charm [2].


Congrats!


> 1) Should I follow some procedure to find someone to review the charm?
>

Definitely, you can submit it to the review queue [1] and there's a
document that goes through some things to look out for going through the
process [2].


> 2) When I release my charm I get the following warning: bugs-url is
> not set.  See set command. Am I supposed to set such a bugs-url? Can I
> use https://github.com/panagiotisl/bigtop/issues ?
>

Exactly, where ever you want to track the bugs for the charm is up to you.
Use the charm command to set the bugs-url

charm set cs:~panagiotisl/giraph bugs-url
https://github.com/panagiotisl/bigtop/issues
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: master/CiaB: Wait for juju services to have open ports - Timeout when waiting for services

[Rick Harding]

Can you paste the relations part of the juju status output that shows those
relations in place? Perhaps there's an issue with the charm logic and
breaking and re-adding the relations might kick it into gear?



On Wed, Jan 4, 2017 at 2:48 AM Mac Lin <mkl0...@gmail.com> wrote:

> Really appreciate for the help. Have been stuck here for weeks.
>
> AFAIK, no. I attached two result of "juju status" on CloudLab(good) and my
> server (bad). It's supposed to work without expose the ports. And I just
> noticed that on my server, most of the services are in blocked status. But
> it seems the missing parts are fulfilled. For example, the ceilometer is
> complaining missing messaging, identity, and database relations, but the
> relation does exist.
>
> Please let me know if any info needed.
>
>   ceilometer:
> charm: cs:trusty/ceilometer-17
> exposed: false
> service-status:
>   current: blocked
>   message: 'Missing relations: messaging, identity, database'
>   since: 03 Jan 2017 19:39:55Z
> relations:
>   amqp:
>   - rabbitmq-server
>   ceilometer-service:
>   - ceilometer-agent
>   cluster:
>   - ceilometer
>   identity-service:
>   - keystone
>   juju-info:
>   - nagios
>   nrpe-external-master:
>   - nrpe
>   shared-db:
>   - mongodb
> units:
>   ceilometer/0:
> workload-status:
>   current: blocked
>   message: 'Missing relations: messaging, identity, database'
>   since: 03 Jan 2017 19:39:55Z
> agent-status:
>   current: executing
>   message: running install hook
>   since: 03 Jan 2017 14:53:31Z
>   version: 1.25.9
> agent-state: started
> agent-version: 1.25.9
>     machine: "9"
> open-ports:
> - 8777/tcp
> public-address: ceilometer.cord.lab
>
>
>
> On Tue, Jan 3, 2017 at 8:23 PM, Rick Harding <rick.hard...@canonical.com>
> wrote:
>
> Has juju expose been run on the applications? The charm can declare that
> these ports are the ones that are opened if exposed, it's not actually set
> until the operator runs the juju expose command on the application.
>
> On Sun, Jan 1, 2017 at 2:58 AM Mac Lin <mkl0...@gmail.com> wrote:
>
>
> Hi,
>
> I'm running CORD master/cord-in-a-box.sh on an x86_64 server. The same
> script on CloudLab has no problem.
>
> If I log into each failed service(lxc), I could found the port is not
> listened because service is not up, which is due to not configured
> properly. The configuration files are mostly at its initial state.
>
> How could I let juju to generate the configuration for the services
> manually?
>
> TASK [juju-finish : Wait for juju services to have open ports]
> *
> Saturday 31 December 2016  12:04:22 + (0:00:04.738)   0:09:13.981
> *
> failed: [10.100.198.201] (item={u'service': u'ceilometer',
> u'ipv4_last_octet': 20, u'name': u'ceilometer-1', u'forwarded_ports':
> [{u'int': 8777, u'ext': 8777}], u'aliase
> s': [u'ceilometer']}) => {"elapsed": 1800, "failed": true, "item":
> {"aliases": ["ceilometer"], "forwarded_ports": [{"ext": 8777, "int":
> 8777}], "ipv4_last_octet": 20, "n
> ame": "ceilometer-1", "service": "ceilometer"}, "msg": "Timeout when
> waiting for ceilometer-1:8777"}
> failed: [10.100.198.201] (item={u'service': u'glance', u'ipv4_last_octet':
> 30, u'name': u'glance-1', u'forwarded_ports': [{u'int': 9292, u'ext':
> 9292}], u'aliases': [u'g
> lance']}) => {"elapsed": 1800, "failed": true, "item": {"aliases":
> ["glance"], "forwarded_ports": [{"ext": 9292, "int": 9292}],
> "ipv4_last_octet": 30, "name": "glance-1"
> , "service": "glance"}, "msg": "Timeout when waiting for glance-1:9292"}
> failed: [10.100.198.201] (item={u'service': u'keystone',
> u'ipv4_last_octet': 40, u'name': u'keystone-1', u'forwarded_ports':
> [{u'int': 35357, u'ext': 35357}, {u'int': 49
> 90, u'ext': 4990}, {u'int': 5000, u'ext': 5000}], u'aliases':
> [u'keystone']}) => {"elapsed": 1800, "failed": true, "item": {"aliases":
> ["keystone"], "forwarded_ports": [
> {"ext": 35357, "int": 35357}, {"ext": 4990, "int": 4990}, {"ext": 5000,
> "int": 5000}], "ipv4_last_octet": 40, "name&q

Re: Juju Wikipedia Needs Update

[Rick Harding]

Thanks for the heads up. I'll take a look at it. I've wanted to write for
wikipedia sometime.

On Tue, Jan 3, 2017 at 12:55 PM James Beedy  wrote:

> Wikipedia entry for Juju needs update
> https://en.m.wikipedia.org/wiki/Juju_(software)
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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

Re: using a bundle with manually added machines

[Rick Harding]

Hi Vance, you can deploy a bundle that uses existing machines in the model
with the juju-deployer [1] tool.

The built in juju deploy method is the first stage in a generic tool and
does not allow pointing at existing machines because it means the bundles
are not sharable and that you need your model in a specific state before
you can use the bundle. Since Juju doesn't allow you to rename machines it
means that you have to keep the bundle in sync with the model.

1: https://pypi.python.org/pypi/juju-deployer/

On Thu, Dec 29, 2016 at 9:09 AM Vance Morris  wrote:

>
> Hi all,
>
> Is it possible to use a bundle.yaml in conjunction with manually added
> machines?
>
> $ juju version
> 2.0.2-xenial-s390x
>
> $ juju status
> << snip >>
> Machine  StateDNS  Inst id  Series  AZ
> 0started  REDACTED  manual:REDACTED   xenial
> 1started  REDACTED  manual:REDACTED   xenial
> 2started  REDACTED  manual:REDACTED   xenial
> << snip >>
>
> When I go to deploy a bundle that defines machines 0, 1, and 2 and
> describes deployment of services to these machines, the charms are
> deployed, but no units are created.
>
> ERROR cannot deploy bundle: cannot create machine for holding aodh,
> ceilometer, ceph-mon, ceph-osd, cinder, glance, keystone, mongodb, mysql,
> neutron-api, neutron-gateway, nova-cloud-controller, nova-compute,
> openstack-dashboard, rabbitmq-server, swift-proxy and swift-storage-z1
> units: cannot add a new machine: use "juju add-machine ssh:[user@]"
> to provision machines
>
> If I manually deploy charms to the manually added machines, it's happy to
> oblige.
>
>
> VANCE MORRIS
> --
> Phone:  1-720-349-9450 <(720)%20349-9450>
> E-mail: vmor...@us.ibm.com
> [image: IBM]
> 
> 
> 
> 1177 S Belt Line Rd
> Coppell, TX 75019-4642
> United States
>
> --
> 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: using a bundle with manually added machines (redux)

[Rick Harding]

I'm looking into this. The bundle deploy feature in Juju 2.0 does not allow
referring to existing machines because it breaks the reusability of the
bundle.

However, the manual provider is a bit unique in that it's how you get
machines into the system. The bundle deployment should work to pick up
machines that are not in use. However, since they're 'existing' it's
failing for you.

The reason Merlijn is able to do things is that in 1.25 you used the
juju-deployer tool to deploy bundles which supports a wide range of
customized, non-generic functions like pointing at existing machines.

On Tue, Jan 3, 2017 at 4:31 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> I've used the manual provider in Juju 1.x, and that functionality was
> working at the moment. This is one of the bundles that was working:
>
>
> https://raw.githubusercontent.com/IBCNServices/tengu-charms/master/bundles/streaming/bundle.yaml
>
> (ignore the "annotations" of the machines)
>
> 2016-12-29 20:16 GMT+01:00 Vance Morris :
>
> I'm going to assume that it's not working for me because I'm not using a
> cloud provider and instead manually adding the machines to Juju prior to
> deploying the bundle.
>
> I would think that this is a supported approach, but maybe I'm outside the
> bounds here...
>
> Thanks,
> Vance
>
> -Merlijn Sebrechts  wrote: -
> To: Vance Morris/Dallas/IBM@IBMUS
> From: Merlijn Sebrechts 
> Date: 12/29/2016 11:09AM
> Cc: "juju@lists.ubuntu.com" 
> Subject: Re: using a bundle with manually added machines (redux)
>
> Sorry, didn't see that, I was on my phone.
>
> The bundle looks correct to me, and everything seems in order when I
> import it into demo.jujucharms.com so I'm not sure why it doesn't work
> for you..
>
> 2016-12-29 17:13 GMT+01:00 Vance Morris :
> Greets Merlijn,
>
>  The bundle was attached to the original message, sorry I didn't call it
> out.
>
>  See here:
> https://lists.ubuntu.com/archives/juju/attachments/20161229/8b65108b/attachment.obj
>
>  Thanks,
>  Vance
>
>
>  -Merlijn Sebrechts  wrote: -
>  To: Vance Morris/Dallas/IBM@IBMUS
>  From: Merlijn Sebrechts 
>  Date: 12/29/2016 08:33AM
>  Cc: "juju@lists.ubuntu.com" 
>  Subject: Re: using a bundle with manually added machines (redux)
>
>
>  Defining the machines and defining the correct machines for each
> application using `to` should work.
>
>  The error message looks like some applications don't define machines so
> juju tries to create new machines which obviously fails. Is it possible to
> share the bundle that produces this error message and show the command you
> use to deploy that bundle?
>
>  Note that if an application has multiple units, you must specify multiple
> machines to deploy to.
>
>  Op donderdag 29 december 2016 heeft Vance Morris 
> het volgende geschreven:
>  > Whoops, sorry for that last message -- let's try this again!
>  >
>  > Hi all,
>  >
>  > Is it possible to use a bundle.yaml in conjunction with manually added
> machines?
>  >
>  > $ juju version
>  > 2.0.2-xenial-s390x
>  >
>  > $ juju status
>  > << snip >>
>  > Machine  StateDNS   Inst id   Series  AZ
>  > 0started  REDACTED  manual:REDACTED   xenial
>  > 1started  REDACTED  manual:REDACTED   xenial
>  > 2started  REDACTED  manual:REDACTED   xenial
>  > << snip >>
>  >
>  > When I go to deploy a bundle that defines machines 0, 1, and 2 and
> describes deployment of services to these machines, the charms are
> deployed, but no units are created.
>  >
>  > ERROR cannot deploy bundle: cannot create machine for holding aodh,
> ceilometer, ceph-mon, ceph-osd, cinder, glance, keystone, mongodb, mysql,
> neutron-api, neutron-gateway, nova-cloud-controller, nova-compute,
> openstack-dashboard, rabbitmq-server, swift-proxy and swift-storage-z1
> units: cannot add a new machine: use "juju add-machine ssh:[user@]"
> to provision machines
>  >
>  > If I manually deploy charms to the manually added machines, it's happy
> to oblige. Any suggestions?
>  >
>  >
>  > Sincerely,
>  >
>  > Vance Morris
>  > 1-720-349-9450 <(720)%20349-9450>
>  > vmor...@us.ibm.com
>  >
>
>
>
>
>
> --
> 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

charmv6-unstable...long live charmv6?

[Rick Harding]

I went to the GH repo for /juju/charm and noticed that it was missing code.
After too long a time I realized I was looking at the v5 branch and
actually we're all using v6-unstable now.

With the release of 2.0 I wanted to see if we're all ready to make v6
stable and update the default branch for the GH repo to the new v6 branch.
Is there anyone out there that might cause an issue?

Thanks

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

Re: Juju Show #2 Wed Dec 14th

[Rick Harding]

Check out the recording of the show in case you missed it.

https://www.youtube.com/watch?v=FwLEMa7XE64

I want to thank everyone that joined us for the show this week. Some great
info on the new tools to aid in charm testing, reviewing, and an exciting
demo of the upcoming juju migrate feature in Juju 2.1.

With the holidays we'll be having our next Juju Show on January 4th and the
one after that will be the 18th. We'll have links and announcements out
after folks get back from the holidays.

On Tue, Dec 13, 2016 at 3:47 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> Come join us as we host the next Juju Show live stream tomorrow. We'll be
> going over the latest in community news, demoing the new developments in
> tools for charming, and getting a demonstration of the new model migration
> feature coming in Juju 2.1.
>
> When: Nov 30th, at 19:00 GMT, 2:00pm EST
> Where: https://www.youtube.com/watch?v=FwLEMa7XE64
> How to participate: Hang out in the #juju Freenode IRC channel
>
> Join us in the IRC channel to ask questions, get a link to the hangout to
> join the live stream, or just to listen in on the latest news.
>
> Make sure to subscribe to the Juju Youtube channel so you never miss any
> of the happenings in and around Juju!
>
> https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw
>
> See you there!
>
> Rick
> Juju Engineering
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Show #2 Wed Dec 14th

[Rick Harding]

Check out the recording of the show in case you missed it.

https://www.youtube.com/watch?v=FwLEMa7XE64

I want to thank everyone that joined us for the show this week. Some great
info on the new tools to aid in charm testing, reviewing, and an exciting
demo of the upcoming juju migrate feature in Juju 2.1.

With the holidays we'll be having our next Juju Show on January 4th and the
one after that will be the 18th. We'll have links and announcements out
after folks get back from the holidays.

On Tue, Dec 13, 2016 at 3:47 PM Rick Harding <rick.hard...@canonical.com>
wrote:

> Come join us as we host the next Juju Show live stream tomorrow. We'll be
> going over the latest in community news, demoing the new developments in
> tools for charming, and getting a demonstration of the new model migration
> feature coming in Juju 2.1.
>
> When: Nov 30th, at 19:00 GMT, 2:00pm EST
> Where: https://www.youtube.com/watch?v=FwLEMa7XE64
> How to participate: Hang out in the #juju Freenode IRC channel
>
> Join us in the IRC channel to ask questions, get a link to the hangout to
> join the live stream, or just to listen in on the latest news.
>
> Make sure to subscribe to the Juju Youtube channel so you never miss any
> of the happenings in and around Juju!
>
> https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw
>
> See you there!
>
> Rick
> Juju Engineering
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: support for local resources in bundles?

[Rick Harding]

No, currently it does not. It's on the 17.04 roadmap to add that support.

The bundle does support resources, but as revisions from the charmstore so
that you can build a bundle that's not just the latest published charm
revision/resource revision set.

On Tue, Dec 13, 2016 at 6:09 PM Kevin Monroe 
wrote:

> I've got a bundle.yaml that defines a local charm, e.g.:
>
> ...
>   mycharm:
> charm: "/home/ubuntu/charms/builds/mycharm"
> num_units: 1
> ...
>
> Does the bundle spec allow for attaching resources to mycharm?  If so, can
> the resource be local?
>
> Thanks!
> -Kevin
> --
> 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

Juju Show #2 Wed Dec 14th

[Rick Harding]

Come join us as we host the next Juju Show live stream tomorrow. We'll be
going over the latest in community news, demoing the new developments in
tools for charming, and getting a demonstration of the new model migration
feature coming in Juju 2.1.

When: Nov 30th, at 19:00 GMT, 2:00pm EST
Where: https://www.youtube.com/watch?v=FwLEMa7XE64
How to participate: Hang out in the #juju Freenode IRC channel

Join us in the IRC channel to ask questions, get a link to the hangout to
join the live stream, or just to listen in on the latest news.

Make sure to subscribe to the Juju Youtube channel so you never miss any of
the happenings in and around Juju!

https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

See you there!

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

Juju Show #2 Wed Dec 14th

[Rick Harding]

Come join us as we host the next Juju Show live stream tomorrow. We'll be
going over the latest in community news, demoing the new developments in
tools for charming, and getting a demonstration of the new model migration
feature coming in Juju 2.1.

When: Nov 30th, at 19:00 GMT, 2:00pm EST
Where: https://www.youtube.com/watch?v=FwLEMa7XE64
How to participate: Hang out in the #juju Freenode IRC channel

Join us in the IRC channel to ask questions, get a link to the hangout to
join the live stream, or just to listen in on the latest news.

Make sure to subscribe to the Juju Youtube channel so you never miss any of
the happenings in and around Juju!

https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

See you there!

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

Re: Upgrading multiseries Charm

[Rick Harding]

Oops sorry. It's what I get for replying while out. So the series in
metadata.yaml is ordered by preferred series. However, you're completely
correct that upgrade should not be attempting to upgrade across series with
an upgrade charm. We'll look into this and file a bug as soon as we
replicate.

On Thu, Dec 8, 2016, 8:37 PM Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
wrote:

> That seems like strange behavior. I would expect that the following for
> multiseries charms:
>
> - For upgrading, use the series of the deployed application. If that
> series is not supported by the "new" charm, throw an error. The error can
> be overridden with `--force-series`. (as stated in the help docs.)
> - For deploying, use the `default-series` (This is NOT the case, and this
> is definitely a bug according to the docs
> <https://jujucharms.com/docs/2.0/models-config#list-of-model-keys>.)
>
>
> In general, for multiseries charms, the following order seems the most
> logical to me:
> Application to upgrade > default-series > order of series in metadata.yaml
>
>
> Also note that it's not possible to specify a series manually with
> `upgrade-charm`. The command doesn't recognize the `--series` flag.
>
> 2016-12-08 14:20 GMT-05:00 Rick Harding <rick.hard...@canonical.com>:
>
> Trusty is listed first. Order counts for the series list.
>
> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
> Hi
>
>
> I'm having trouble upgrading a multiseries charm.
>
>
> merlijn@travers:~$ juju status
> ModelController  Cloud/Region  Version
> merlijntest  sojobo  tengumaas 2.0.1
>
> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
> openvpn   active  1  openvpn  jujucharms4  ubuntu
>
> UnitWorkload  Agent  Machine  Public address   PortsMessage
> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>
> Machine  StateDNS  Inst id  Series  AZ
> 10   started  193.190.127.152  4y3h7y   xenial  default
>
> merlijn@travers:~$ juju upgrade-charm openvpn --path
> $JUJU_REPOSITORY/builds/openvpn
> Added charm "local:trusty/openvpn-16" to the model.
> ERROR cannot upgrade application "openvpn" to charm
> "local:trusty/openvpn-16": cannot change an application's series
>
>
> Metadata.yaml:
>
> "series": ["trusty", "xenial"]
>
>
> I have no idea why he thinks I want to upgrade to trusty...
>
>
>
> Kind regards
> Merlijn
> --
> 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: Upgrading multiseries Charm

[Rick Harding]

Trusty is listed first. Order counts for the series list.

On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts 
wrote:

> Hi
>
>
> I'm having trouble upgrading a multiseries charm.
>
>
> merlijn@travers:~$ juju status
> ModelController  Cloud/Region  Version
> merlijntest  sojobo  tengumaas 2.0.1
>
> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
> openvpn   active  1  openvpn  jujucharms4  ubuntu
>
> UnitWorkload  Agent  Machine  Public address   PortsMessage
> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>
> Machine  StateDNS  Inst id  Series  AZ
> 10   started  193.190.127.152  4y3h7y   xenial  default
>
> merlijn@travers:~$ juju upgrade-charm openvpn --path
> $JUJU_REPOSITORY/builds/openvpn
> Added charm "local:trusty/openvpn-16" to the model.
> ERROR cannot upgrade application "openvpn" to charm
> "local:trusty/openvpn-16": cannot change an application's series
>
>
> Metadata.yaml:
>
> "series": ["trusty", "xenial"]
>
>
> I have no idea why he thinks I want to upgrade to trusty...
>
>
>
> Kind regards
> Merlijn
> --
> 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: One instance manual provider

[Rick Harding]

I'll have to test it out but I would think that you could

1) bring up a machine, create a container on it, bootstrap to that
container as the controller, create another container, and then add-machine
it as a second machine and things should work ok.

2) I wonder if you can bootstrap to a machine, manually add container on
that machine, and then add that container with add-machine.

I'm guessing there's some bits about making sure the added containers have
the ssh key you want to use for the ssh connection for add-machine.

On Mon, Dec 5, 2016 at 3:18 PM Matthew Williams <
matthew.willi...@canonical.com> wrote:

> Hey Folks,
>
> I notice the docs state that at least two instances are needed for the
> manual provider: https://jujucharms.com/docs/stable/clouds-manual. Some
> quick playing around suggests that this is indeed the case.
>
> Is there a technical reason why? I'd love to spin up a charm on [insert
> vps provider here] and only spend money for one instance
>
> Matty
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 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