Re: juju bootstrap to a particular subnet

[John Meinel]

Can you file a bug about the error message being misleading? It should be
that you get "unknown subnet" not "unknown placement directive".

Thanks,
John
=:->

On Mon, Jul 2, 2018 at 5:06 PM, chris  wrote:

> @John,
>
>   Thanks for confirming it's still there.  I was using the wrong subnet
> mask.  All working now.
>
> Thanks,
> -Chris
>
> On Mon, Jul 2, 2018 at 12:09 AM, John Meinel 
> wrote:
>
>> It should still be available for AWS. I think I saw a case where you
>> might get that error just when it can't find the subnet you asked for (so
>> 'subnet=' is known, but the 172.32.* couldn't be found).
>> I'm not positive about it, but I do still see the subnet matching code in
>> place.
>>
>> John
>> =:->
>>
>>
>> On Mon, Jun 25, 2018 at 11:42 PM, chris  wrote:
>>
>>> Hello everyone,
>>>
>>>   In looking through the docs I was unable to find a way to deploy a
>>> controller to a specific subnet.  I found some old bug reports where there
>>> was possibly a --to directive added to facilitate this back in 2.2.
>>> However, this is what happens when I use it...
>>>
>>> juju bootstrap --config vpc-id=vpc- --credential=cred_name
>>> aws/region controller_name --to subnet=172.32.X.X/20
>>> ERROR failed to bootstrap model: cannot start bootstrap instance:
>>> unknown placement directive: subnet=172.32.X.X/20
>>>
>>>   Is this directive still available?  Has it changed?
>>>
>>> Thanks,
>>> -Chris
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju bootstrap to a particular subnet

[John Meinel]

It should still be available for AWS. I think I saw a case where you might
get that error just when it can't find the subnet you asked for (so
'subnet=' is known, but the 172.32.* couldn't be found).
I'm not positive about it, but I do still see the subnet matching code in
place.

John
=:->


On Mon, Jun 25, 2018 at 11:42 PM, chris  wrote:

> Hello everyone,
>
>   In looking through the docs I was unable to find a way to deploy a
> controller to a specific subnet.  I found some old bug reports where there
> was possibly a --to directive added to facilitate this back in 2.2.
> However, this is what happens when I use it...
>
> juju bootstrap --config vpc-id=vpc- --credential=cred_name
> aws/region controller_name --to subnet=172.32.X.X/20
> ERROR failed to bootstrap model: cannot start bootstrap instance: unknown
> placement directive: subnet=172.32.X.X/20
>
>   Is this directive still available?  Has it changed?
>
> Thanks,
> -Chris
>
> --
> 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: How do you clean a juju disk or make it larger?

[John Meinel]

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

Re: bridge activation error: yaml: unmarshal errors:, line 7: field bonds not found in struct netplan

[John Meinel]

btw, including a copy of your /etc/netplan/*.yaml files once you've
bootstrapped would probably be useful to make sure we're addressing the
issues that you're seeing.

John
=:->


On Tue, Apr 17, 2018 at 4:18 PM, John Meinel <j...@arbash-meinel.com> wrote:

> We should get a bug following this. But essentially Bionic changed how
> networking configuration is being done, from /etc/network/interfaces to
> /etc/netplan/*.yaml files.
>
> When we started implementing support for netplan, they hadn't finished
> support for bonds, so we didn't implement support for reading bonds and
> configuring them.
>
> They have since finished supporting bonds in netplan, and we need to
> update our support for netplan to include bonds.
>
> While we *could* just not past "strict" to the yaml library, I think the
> net result of that would not be positive, because we might try to create
> configurations not being aware of part of your network.
>
>
> On Tue, Apr 17, 2018 at 10:46 AM, Vidmantas Rinkevičius <
> vidmantas.rinkevic...@vgtu.lt> wrote:
>
>> Hi,
>>
>> During openstack deployment juju gives error on all lxd containers.
>>
>> Example:
>>
>> sudo juju status
>>
>> 3/lxd/0  down pending  bionic bridge activation
>> error: yaml: unmarshal errors:
>>   line 7: field bonds not found in struct netplan.
>>
>> yaml:
>>
>> openstack-dashboard:
>> annotations:
>>   gui-x: '500'
>>   gui-y: '-250'
>> charm: cs:~openstack-charmers-next/bionic/openstack-dashboard
>> num_units: 1
>> bindings:
>>   website: web
>> options:
>>   openstack-origin: distro-proposed
>> to:
>> - lxd:3
>>
>>
>> I am deploying 18.04 and I use network spaces.
>>
>> Any ideas why this error occurs?
>>
>>
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: bridge activation error: yaml: unmarshal errors:, line 7: field bonds not found in struct netplan

[John Meinel]

We should get a bug following this. But essentially Bionic changed how
networking configuration is being done, from /etc/network/interfaces to
/etc/netplan/*.yaml files.

When we started implementing support for netplan, they hadn't finished
support for bonds, so we didn't implement support for reading bonds and
configuring them.

They have since finished supporting bonds in netplan, and we need to update
our support for netplan to include bonds.

While we *could* just not past "strict" to the yaml library, I think the
net result of that would not be positive, because we might try to create
configurations not being aware of part of your network.


On Tue, Apr 17, 2018 at 10:46 AM, Vidmantas Rinkevičius <
vidmantas.rinkevic...@vgtu.lt> wrote:

> Hi,
>
> During openstack deployment juju gives error on all lxd containers.
>
> Example:
>
> sudo juju status
>
> 3/lxd/0  down pending  bionic bridge activation error:
> yaml: unmarshal errors:
>   line 7: field bonds not found in struct netplan.
>
> yaml:
>
> openstack-dashboard:
> annotations:
>   gui-x: '500'
>   gui-y: '-250'
> charm: cs:~openstack-charmers-next/bionic/openstack-dashboard
> num_units: 1
> bindings:
>   website: web
> options:
>   openstack-origin: distro-proposed
> to:
> - lxd:3
>
>
> I am deploying 18.04 and I use network spaces.
>
> Any ideas why this error occurs?
>
>
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Implement aws style user-data

[John Meinel]

I think the actual question is how to create a service that responds to
metadata requests. In that case, it is a bit hard to say from the outside,
because it is very dependent on what software-defined-networking you're
using.

169.254.169.254 is a link-local address, which means it can't be routed
across the network. So you have to have your SDN know where to send your
packets (it effectively looks like the switch is the thing running the
metadata server, because that's the only thing on the other side of a
link-local connection).

I don't have any specific information about how it is done on the various
clouds. Though you could look at openstack which also implements a
metadata-server and is open source code.

John
=:->


On Wed, Apr 11, 2018 at 7:58 PM, Heather Lanigan <
heather.lani...@canonical.com> wrote:

> Hi Drew,
>
> Juju uses cloud-init currently when provisioning machines today.  We've
> recently added a bootstrap configuration option to allow for cloud-init
> yaml to
> be passed through.
>
> Details can be found in an old bug: https://bugs.launchpad.
> net/juju/+bug/1535891
>
> I need to get this added to the docs.  There is a known issue using lists
> in the yaml file, but strings work fine.
>
> -Heather
>
> On Wed, Mar 28, 2018 at 4:16 PM, Drew Wells 
> wrote:
>
>> I want to implement an aws user-data like interface. So the Ubuntu host
>> would respond on 169.254.169.254 and this address would be routable by
>> every juju managed machine and the containers running on those machines.
>>
>> Where would I get started for setting something like this up?
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju's dependencies, juju/utils and a road forward

[John Meinel]

I agree with breaking up utils. I've certainly read similar comments
elsewhere that calling something 'utils' inherently causes issues like
this, and it seems to fit with our experience.

I also agree that X stable depending on Y unstable doesn't seem right.
Though we're also very bad at ever making a genuine release of
dependencies. (it's a lot of overhead if nobody else is actually consuming
them)

There are probably other small things like it is "mgo/bson" where bson
should really be it's own package.

Also some questions about how well packages avoid leaking. (charmstore uses
mgo as a backend. if it doesn't expose those types then we probably don't
care if some of our tree depends on it while the other part doesn't. At
least as a transition phase.)

John
=:->

On Apr 4, 2018 06:19, "Tim Penhey"  wrote:

Which then begs the question...

Why do we have stable gopkg.in branches depending on unstable branches?

i.e. gopkg.in/juju/charmstore.v5 depending on
gopkg.in/macaroon-bakery.v2-unstable?

This seems to smell bad.



Tim


On 04/04/18 14:17, Tim Penhey wrote:
> As a follow on...
>
> I'd like to move juju to only use "stable" dependency branches. No more
> '-unstable'.
>
> Tim
>
> On 04/04/18 12:52, Tim Penhey wrote:
>> Hi folks,
>>
>> Juju has a problem with its dependencies. We have been trying to upgrade
>> a number of our dependencies recently have have been hitting road
>> blocks. Mostly because of changes to common libraries that are
>> incompatible with other libraries that we use.
>>
>> I'm pretty sure that the root of all these problems is the juju/utils
>> package. It has become a dumping ground for any common functions that
>> packages may want to share. However these common functions are changed
>> arbitrarily with only thoughts around how they impact a subset of the
>> downstreams of juju/utils.
>>
>> I think that the only sane way forward is to move all the functionality
>> we care about out of juju/utils into more cohesive, smaller, packages
>> that have meaningful names and you should be able to determine what they
do.
>>
>> Where the current clashes came from were a few places.
>>  1) we wanted to change our mgo dependency
>>  2) a new file path utility function was wanted
>>  3) the debugstatus package inside utils was updated in a backward
>> incompatible way
>>
>> The root problem here is that the utils package tries to do too many
>> things. Any package called "utils" should be a warning, and we should
>> have listened to Dave Cheney when he brought this up originally.
>>
>> I think the way forward is to break up the utils package. I'd like to
>> propose that we don't add anything new to the utils package, and only
>> deletions are allowed. We create new packages that contain the
>> functionality we require, and have them be much more controlled on their
>> own dependencies.
>>
>> Thoughts?
>>
>> Tim
>>
>

--
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 deploys with a vsphere controller using hardware vm version 10

[John Meinel]

We've done some digging on this. It turns out that we can fairly easily
request VSphere to deploy the best version it knows about (ESXi 5.5
supports 10, 6.0 supports 11, 6.5 supports 13). It is fairly easy to change
our descriptor to request any of them, and we saw that 6.0 picked 11 and
ignored 13.

However, there seems to be a problem with the ubuntu image when booted in
version 11. We've filed a bug with the people generating the images, but it
starts to boot, but fails to get to a login prompt.

So while it is fairly easy for Juju to start requesting newer hardware
versions, there is a potential issue with the actual images not supporting
them.

John
=:->


On Wed, Feb 7, 2018 at 11:32 AM, Mark Shuttleworth  wrote:

>
> Seems we should support a range of widely used versions, rather than
> only the latest.
>
> Mark
>
> On 02/07/2018 04:24 AM, Ian Booth wrote:
> > Hi Daniel
> >
> > The Juju vSphere provider currently only supports hardware version 10,
> but 14 is
> > now the most recent according to the VMWare website. If we were simply
> to track
> > and support the most recent hardware version, would that work for you?
> >
> > On 05/02/18 12:38, Daniel Bidwell wrote:
> >> Is there anyway to make the vsphere controller to deploy vms with
> >> hardware vm version 13 instead of version 10?
> >>
>
>
> --
> 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 deploys with a vsphere controller using hardware vm version 10

[John Meinel]

We've done some digging on this. It turns out that we can fairly easily
request VSphere to deploy the best version it knows about (ESXi 5.5
supports 10, 6.0 supports 11, 6.5 supports 13). It is fairly easy to change
our descriptor to request any of them, and we saw that 6.0 picked 11 and
ignored 13.

However, there seems to be a problem with the ubuntu image when booted in
version 11. We've filed a bug with the people generating the images, but it
starts to boot, but fails to get to a login prompt.

So while it is fairly easy for Juju to start requesting newer hardware
versions, there is a potential issue with the actual images not supporting
them.

John
=:->


On Wed, Feb 7, 2018 at 11:32 AM, Mark Shuttleworth  wrote:

>
> Seems we should support a range of widely used versions, rather than
> only the latest.
>
> Mark
>
> On 02/07/2018 04:24 AM, Ian Booth wrote:
> > Hi Daniel
> >
> > The Juju vSphere provider currently only supports hardware version 10,
> but 14 is
> > now the most recent according to the VMWare website. If we were simply
> to track
> > and support the most recent hardware version, would that work for you?
> >
> > On 05/02/18 12:38, Daniel Bidwell wrote:
> >> Is there anyway to make the vsphere controller to deploy vms with
> >> hardware vm version 13 instead of version 10?
> >>
>
>
> --
> 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.3.3 failing to bootstrap localhost

[John Meinel]

That sounds more like the 'ubuntu' user inside the container is having
trouble? Juju connects to initially launched machines as the ubuntu user,
not as your username.

John
=:->


On Thu, Feb 22, 2018 at 5:32 AM, fengxia  wrote:

> Verified by login to the container. I could `apt update`, `apt install
> htop`.
>
> At juju bootstrap terminal, I picked up this error message:
>
> 01:27:52 DEBUG juju.provider.common bootstrap.go:564 connection attempt
> for 10.170.
>
> 130.125 failed: WARNING: Your password has expired.
> Password change required but no TTY available.
>
> What does it mean? I looked at my user's password expiration settings on
> the host using `chage`:
>
> (dev) fengxia@ubuntu:~$ sudo chage -l fengxia
> Last password change: Dec 07, 2017
> Password expires: never
> Password inactive: never
> Account expires: never
> Minimum number of days between password change: 0
> Maximum number of days between password change: 9
> Number of days of warning before password expires: 7
>
> Looks like the password should be just fine.
>
> Any other pointer would be highly appreciated.
>
>
>
> On 02/21/2018 06:24 PM, Nicholas Skaggs wrote:
>
>> On 02/21/2018 04:47 PM, David Britton wrote:
>>
>>> On Wed, Feb 21, 2018 at 04:11:44PM -0500, fengxia wrote:
>>>
 Hi Juju,

 Is anyone seeing this? I'm running the same setup as yesterday's, then
 updated `apt update && apt upgrade` this morning. All of a sudden `juju
 bootstrap localhost ..` stuck at Attempting to connect. LXC container
 was
 created and had an IP, but juju won't connect somehow?

 1. Tried reconfiguring LXD to different network addresses, not helpful.

 2. Made sure `.local/share/juju/ssh/juju_id_rsa` has mode 0600

 Any idea what to try?

>>> If you have your lxd container created, you can get access to it
>>> directly:
>>>
>>> lxc list
>>> lxc exec  bash
>>> # look in /var/log/cloud*, /var/log/juju/*,
>>> # /var/log/syslog, etc for errors
>>>
>>> Also, you can run your `juju bootstrap` in --debug mode, which gives a
>>> lot more data.
>>>
>>> Specifically make sure you can:
>>
>> 1) create an lxc container
>>
>> 2) ssh into the container
>>
>> 3) that container has proper connectivity, including the ability to
>> install packages
>>
>>
>> Nicholas
>>
>>
> --
> Feng Xia
>
> Advisory Engineer
> Datacenter Group (DCG), Lenovo US
> 8000 Development Dr, Morrisiville, NC 27509
> W: http://www.lenovo.com
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju juju-upgrade -m controller woes

[John Meinel]

In 2.3 there is "juju upgrade-juju --ignore-agent-versions" but I think
that is only respected if the target controller already is 2.3 (eg, this
would help if you were trying to go from 2.3 to 2.4, but won't help going
2.2 to 2.3).

There is a separate command line utility that you can build in the juju
source tree called "juju-force-upgrade" which can work to bypass the agent
version check.

It might also be possible to "juju remove-machine --force 2" which would
let you remove that machine. However, I'm not 100% sure that you can remove
a machine that is currently pending provisioning.

Its possible that "juju debug-log --replay [-m controller]" would be
enlightening as to why machine 2 is failing to be provisioned (or looking
at machine-0.log on the controller machine).

Is there a reason you are manually provisioning instances and then
registering them rather than using the cloud as a VMWare cloud? (juju
add-cloud vmware).

John
=:->

On Wed, Jan 31, 2018 at 12:00 AM, Daniel Bidwell <drbidw...@gmail.com>
wrote:

> I have a vmware vm on my public network that is my juju host.  In it I
> have an lxc container that is also bridged to my public network.  I
> bootstrapped it with:
>
> juju bootstrap manual/ipaddress modelname
>
> I also created vms with public IP addresses that I setup an ubuntu
> account and added as:
>
> juju add-machine ssh:ubuntu@ipaddress
>
> all machines have public ip address and full routing.
>
> The controller container was running juju version 2.2.6 (unsupported)
> while the main machine had been upgraded to 2.3.2.
>
> juju status produces:
>
> ModelController  Cloud/Region  Version  SLA
> default  uncloud manual2.2.6unsupported
>
> App   Version  Status  Scale  Charm
> Store  Rev  OS  Notes
> au-webcluster-member   active  1  au-webcluster-
> member  local0  ubuntu
> aubase1active  1  aubase1
> local0  ubuntu
>
> Unit Workload  Agent  Machine  Public
> address  Ports  Message
> au-webcluster-member/0*  activeidle   1webc4  Web
> cluster member for instance test completed
> aubase1/0*   activeidle   1webc4
>
> Machine  StateDNS  Inst id Series  AZ  Message
> 0down amzsend  manual:amzsend  xenial  Manually
> provisioned machine
> 1started  webc4manual:webc4xenial  Manually
> provisioned machine
> 2pending  webc5manual:webc5xenial  Manually
> provisioned machine
>
> machine 2 failed to "add".  The upgrade-juju command now says:
>
> ERROR some agents have not upgraded to the current model version 2.2.6:
> machine-2
>
> but juju doesn't let me do anything with machine-2 until it is finished
> with it.
>
> I suspect that my only option is to build a new container/controller
> and redeploy my machines on it before removing the old
> container/controller.
>
> On Tue, 2018-01-30 at 14:40 +0400, John Meinel wrote:
> > I'm a bit curious what you mean by "manually provisioned machine".
> > Are you saying that you used the VMWare APIs directly to launch an
> > instance, and then "juju bootstrap IP" to start using that machine,
> > and then "juju add-machine ssh:IP" to add the second machine?
> >
> > You could try doing "juju upgrade-juju --debug" to see what at least
> > the client thinks it is trying to do. I wonder if it is a case where
> > your VM doesn't actually have egress access, but your client does.
> > And so Jujud on the VM is trying to do something like download the
> > new agent, which your client saw and said was available, but the
> > controller isn't actually able to download.
> >
> > John
> > =:->
> >
> >
> > On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell <drbidw...@gmail.com>
> > wrote:
> > > I have a juju controller, uncloud, in a container in a vmware vm.
> > > The
> > > controller has a manually provisioned machine deployed happily.  I
> > > tried to manually provision a second machine.  It is stuck in
> > > pending
> > > with no progress after a day of waiting.  I can ssh to ubuntu@host
> > > just
> > > fine with the ssh keys installed.
> > >
> > > I am provisioning from a machine with juju 2.3.2 and the controller
> > > has
> > > version 2.2.6 on it (now unsupported).  I have attempted to do
> > > "juju
> > > upgrade-juju -m uncloud" and it happily says that it is upgrading
>

Re: juju juju-upgrade -m controller woes

[John Meinel]

In 2.3 there is "juju upgrade-juju --ignore-agent-versions" but I think
that is only respected if the target controller already is 2.3 (eg, this
would help if you were trying to go from 2.3 to 2.4, but won't help going
2.2 to 2.3).

There is a separate command line utility that you can build in the juju
source tree called "juju-force-upgrade" which can work to bypass the agent
version check.

It might also be possible to "juju remove-machine --force 2" which would
let you remove that machine. However, I'm not 100% sure that you can remove
a machine that is currently pending provisioning.

Its possible that "juju debug-log --replay [-m controller]" would be
enlightening as to why machine 2 is failing to be provisioned (or looking
at machine-0.log on the controller machine).

Is there a reason you are manually provisioning instances and then
registering them rather than using the cloud as a VMWare cloud? (juju
add-cloud vmware).

John
=:->

On Wed, Jan 31, 2018 at 12:00 AM, Daniel Bidwell <drbidw...@gmail.com>
wrote:

> I have a vmware vm on my public network that is my juju host.  In it I
> have an lxc container that is also bridged to my public network.  I
> bootstrapped it with:
>
> juju bootstrap manual/ipaddress modelname
>
> I also created vms with public IP addresses that I setup an ubuntu
> account and added as:
>
> juju add-machine ssh:ubuntu@ipaddress
>
> all machines have public ip address and full routing.
>
> The controller container was running juju version 2.2.6 (unsupported)
> while the main machine had been upgraded to 2.3.2.
>
> juju status produces:
>
> ModelController  Cloud/Region  Version  SLA
> default  uncloud manual2.2.6unsupported
>
> App   Version  Status  Scale  Charm
> Store  Rev  OS  Notes
> au-webcluster-member   active  1  au-webcluster-
> member  local0  ubuntu
> aubase1active  1  aubase1
> local0  ubuntu
>
> Unit Workload  Agent  Machine  Public
> address  Ports  Message
> au-webcluster-member/0*  activeidle   1webc4  Web
> cluster member for instance test completed
> aubase1/0*   activeidle   1webc4
>
> Machine  StateDNS  Inst id Series  AZ  Message
> 0down amzsend  manual:amzsend  xenial  Manually
> provisioned machine
> 1started  webc4manual:webc4xenial  Manually
> provisioned machine
> 2pending  webc5manual:webc5xenial  Manually
> provisioned machine
>
> machine 2 failed to "add".  The upgrade-juju command now says:
>
> ERROR some agents have not upgraded to the current model version 2.2.6:
> machine-2
>
> but juju doesn't let me do anything with machine-2 until it is finished
> with it.
>
> I suspect that my only option is to build a new container/controller
> and redeploy my machines on it before removing the old
> container/controller.
>
> On Tue, 2018-01-30 at 14:40 +0400, John Meinel wrote:
> > I'm a bit curious what you mean by "manually provisioned machine".
> > Are you saying that you used the VMWare APIs directly to launch an
> > instance, and then "juju bootstrap IP" to start using that machine,
> > and then "juju add-machine ssh:IP" to add the second machine?
> >
> > You could try doing "juju upgrade-juju --debug" to see what at least
> > the client thinks it is trying to do. I wonder if it is a case where
> > your VM doesn't actually have egress access, but your client does.
> > And so Jujud on the VM is trying to do something like download the
> > new agent, which your client saw and said was available, but the
> > controller isn't actually able to download.
> >
> > John
> > =:->
> >
> >
> > On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell <drbidw...@gmail.com>
> > wrote:
> > > I have a juju controller, uncloud, in a container in a vmware vm.
> > > The
> > > controller has a manually provisioned machine deployed happily.  I
> > > tried to manually provision a second machine.  It is stuck in
> > > pending
> > > with no progress after a day of waiting.  I can ssh to ubuntu@host
> > > just
> > > fine with the ssh keys installed.
> > >
> > > I am provisioning from a machine with juju 2.3.2 and the controller
> > > has
> > > version 2.2.6 on it (now unsupported).  I have attempted to do
> > > "juju
> > > upgrade-juju -m uncloud" and it happily says that it is upgrading
>

Re: juju juju-upgrade -m controller woes

[John Meinel]

I'm a bit curious what you mean by "manually provisioned machine". Are you
saying that you used the VMWare APIs directly to launch an instance, and
then "juju bootstrap IP" to start using that machine, and then "juju
add-machine ssh:IP" to add the second machine?

You could try doing "juju upgrade-juju --debug" to see what at least the
client thinks it is trying to do. I wonder if it is a case where your VM
doesn't actually have egress access, but your client does. And so Jujud on
the VM is trying to do something like download the new agent, which your
client saw and said was available, but the controller isn't actually able
to download.

John
=:->


On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell  wrote:

> I have a juju controller, uncloud, in a container in a vmware vm.  The
> controller has a manually provisioned machine deployed happily.  I
> tried to manually provision a second machine.  It is stuck in pending
> with no progress after a day of waiting.  I can ssh to ubuntu@host just
> fine with the ssh keys installed.
>
> I am provisioning from a machine with juju 2.3.2 and the controller has
> version 2.2.6 on it (now unsupported).  I have attempted to do "juju
> upgrade-juju -m uncloud" and it happily says that it is upgrading to
> 2.3.2, but I never see any progress with that either (after hours or
> days).
>
> What is the secret sauce for making these thing work?  For some reason,
> whenever I have trouble with my juju environment, I have to destory it
> and set up the controllers from scrap.  I guess I just don't have the
> juju for juju :-(  I do like being able to develop charms for my apps
> and deploy them though.
> --
> 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: juju juju-upgrade -m controller woes

[John Meinel]

I'm a bit curious what you mean by "manually provisioned machine". Are you
saying that you used the VMWare APIs directly to launch an instance, and
then "juju bootstrap IP" to start using that machine, and then "juju
add-machine ssh:IP" to add the second machine?

You could try doing "juju upgrade-juju --debug" to see what at least the
client thinks it is trying to do. I wonder if it is a case where your VM
doesn't actually have egress access, but your client does. And so Jujud on
the VM is trying to do something like download the new agent, which your
client saw and said was available, but the controller isn't actually able
to download.

John
=:->


On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell  wrote:

> I have a juju controller, uncloud, in a container in a vmware vm.  The
> controller has a manually provisioned machine deployed happily.  I
> tried to manually provision a second machine.  It is stuck in pending
> with no progress after a day of waiting.  I can ssh to ubuntu@host just
> fine with the ssh keys installed.
>
> I am provisioning from a machine with juju 2.3.2 and the controller has
> version 2.2.6 on it (now unsupported).  I have attempted to do "juju
> upgrade-juju -m uncloud" and it happily says that it is upgrading to
> 2.3.2, but I never see any progress with that either (after hours or
> days).
>
> What is the secret sauce for making these thing work?  For some reason,
> whenever I have trouble with my juju environment, I have to destory it
> and set up the controllers from scrap.  I guess I just don't have the
> juju for juju :-(  I do like being able to develop charms for my apps
> and deploy them though.
> --
> 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: Getting the exposed ports

[John Meinel]

If it works, great. But I have the feeling we only run in a hook context
for units and so opened-ports isn't available for a machine. (There are no
machine level hooks, as applications are always unit level)

John
=:->

On Dec 2, 2017 13:30, "Merlijn Sebrechts" <merlijn.sebrec...@gmail.com>
wrote:

> Yes, so with juju-run you could run 'opened-ports' in the hook context of
> each unit on that machine, and this get all the opened+ports on the machine.
>
> On 2 Dec 2017 04:26, "John Meinel" <j...@arbash-meinel.com> wrote:
>
>> I'm pretty sure that opened-ports only reports the ports that Juju had
>> opened for the charm that is making the request. I don't think we list all
>> ports opened on the machine for all other applications.
>>
>> So you might need to have a relation that can report it's opened ports to
>> the subordinate
>>
>> John
>> =:->
>>
>> On Dec 1, 2017 20:58, "Michał Ajduk" <michal.aj...@canonical.com> wrote:
>>
>>> Hello,
>>>
>>> You can take a look at iptables charm. It does the "easy part", that is
>>> admin defined ruleset.
>>>
>>> I was actually thinking of making it also use the open ports. I'm pretty
>>> sure juju-info relation has the open ports data, but I can take a look.
>>>
>>> BR,
>>> Michal
>>>
>>>
>>> 01.12.2017 16:52 "Tom Barber" <t...@spicule.co.uk> napisał(a):
>>>
>>> Hello folks
>>>
>>> I want to write a firewall charm for those deployments that aren't in
>>> the cloud. The "easy" thing to do is provide a config block and have admins
>>> write in rules and just apply them. I was wondering though, if I wrote a
>>> subordinate charm on juju-info to attach to anything, is there any
>>> mechanism for me to find the exposed port of the parent charm? and whether
>>> its exposed or not?
>>>
>>>
>>> Ta
>>>
>>> Tom
>>>
>>>
>>> --
>>>
>>>
>>> Spicule Limited is registered in England & Wales. Company Number:
>>> 09954122. Registered office: First Floor, Telecom House, 125-135
>>> Preston Road, Brighton, England, BN1 6AF
>>> <https://maps.google.com/?q=125-135+Preston+Road,+Brighton,+England,+BN1+6AF=gmail=g>.
>>> 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/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Getting the exposed ports

[John Meinel]

I'm pretty sure that opened-ports only reports the ports that Juju had
opened for the charm that is making the request. I don't think we list all
ports opened on the machine for all other applications.

So you might need to have a relation that can report it's opened ports to
the subordinate

John
=:->

On Dec 1, 2017 20:58, "Michał Ajduk"  wrote:

> Hello,
>
> You can take a look at iptables charm. It does the "easy part", that is
> admin defined ruleset.
>
> I was actually thinking of making it also use the open ports. I'm pretty
> sure juju-info relation has the open ports data, but I can take a look.
>
> BR,
> Michal
>
>
> 01.12.2017 16:52 "Tom Barber"  napisał(a):
>
> Hello folks
>
> I want to write a firewall charm for those deployments that aren't in the
> cloud. The "easy" thing to do is provide a config block and have admins
> write in rules and just apply them. I was wondering though, if I wrote a
> subordinate charm on juju-info to attach to anything, is there any
> mechanism for me to find the exposed port of the parent charm? and whether
> its exposed or not?
>
>
> Ta
>
> Tom
>
>
> --
>
>
> 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/mailm
> an/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: Deploying a charm with t's & c's

[John Meinel]

Do you know what terms you need to accept? You should be able to 'juju
accept termname'.
The other thing to check is if your local clock time is fairly accurate.
I believe we filed a bug recently that the term server gives out temporary
auth tokens that are only valid for 1 minute. (and we end up evaluating the
time both locally and remotely and should really only evaluate it remotely).


John
=:->

On Nov 28, 2017 15:49, "Stephen Downie"  wrote:

Hi

I am trying to deploy a bundle that has a charm that contains terms and
conditions. I am getting the following error message https://gist.github.
com/gizmo693/5a4fc5235da987a4f64e378e1850dd62

Any help would be appreciated.

Thanks

Steve

Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk

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

Re: ownership and sharing of models via team namespace

[John Meinel]

So models shared with you are currently possible, but I believe everything
is still owned as an individual user, rather than at a team scope. You
should be able to add other users as 'admin' on an existing model, but
we're still working through a backlog of places that treat "owner"
differently than a user marked as "admin" on the model.

I do believe creating a team namespaced model is still on the drawing board.

John
=:->


On Mon, Nov 27, 2017 at 8:08 PM, James Beedy  wrote:

> Looking at the jujucharms page for my team namespace [0], I see a place
> where models may be shared with the team. Is this something that is in the
> works, or is there existing functionality where models can be shared
> with/owned by a team?
>
> Thanks
>
> [0] https://imgur.com/a/7xint
>
> --
> 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: ownership and sharing of models via team namespace

[John Meinel]

So models shared with you are currently possible, but I believe everything
is still owned as an individual user, rather than at a team scope. You
should be able to add other users as 'admin' on an existing model, but
we're still working through a backlog of places that treat "owner"
differently than a user marked as "admin" on the model.

I do believe creating a team namespaced model is still on the drawing board.

John
=:->


On Mon, Nov 27, 2017 at 8:08 PM, James Beedy  wrote:

> Looking at the jujucharms page for my team namespace [0], I see a place
> where models may be shared with the team. Is this something that is in the
> works, or is there existing functionality where models can be shared
> with/owned by a team?
>
> Thanks
>
> [0] https://imgur.com/a/7xint
>
> --
> 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: Endpoints trials + MAAS charms

[John Meinel]

It does seem like Juju operating the LXD provider, but spanning multiple
machines would be an answer. I do believe that LXD itself is introducing
clustering into their API in the 18.04 cycle. Which would probably need
some updates on the Juju side to handle their targeted provisioning (create
a container for maas-postgresql on the 3rd machine in the LXD cluster).
But that might get you out of manual provisioning of a bunch of machines
and VMs to target everything.
We're certainly not at a point where you could just-do-that today.
I can also see that it took a few attempts to get there (the last machine
is #40 :)
John
=:->


On Mon, Nov 27, 2017 at 5:17 PM, James Beedy  wrote:

> Dmitrii,
>
> Thanks for the response.
>
> When taking into account the overhead to get MAAS deployed as charms, it
> definitely makes the LXD provider method you have described seem very
> appealing. Some issues I've experienced trying to get MAAS HA deployed are
> such that it seems like just a ton of infrastructure is needed to get MAAS
> HA standing using the manual provider deploying the MAAS charms. You have
> to provision/maintain the manual Juju controller cluster underneath MAAS,
> just to have MAAS  ugh
>
> I found not only the sheer quantity of servers needed to get this working
> quite unnerving, but also the manual ops I had to undergo to get it all
> standing #snowflakes #custom.
>
> I iterated on this a few times to see if I could come up with something
> more manageable, and this is where I landed (brace yourself) [0]
>
> What's going on there?
>
> I created a model in JAAS, manually added 3 physical hosts across
> different racks, then bootstrapped 4 virtual machines on each physical host
> (1 vm for each postgresql, maas-region, maas-rack [1], juju-controller
> (juju controllers for maas provider, to be checked into maas)) on each host.
>
> I then also added my vms to my JAAS model so I could deploy the charms to
> them (just postgresql and ubuntu at the time - the MAAS stuff got manually
> installed and configured after the machiens had ubuntu deployed to them in
> the model).
>
> (ASIDE: I'm seeing I could probably do this one better by combining my
> region and rack controller to the same vm, and colocating the postgresql
> charm with the region+rack on the same vm, giving me ha of all components
> using single vm on each host.)
>
> I know there are probably a plethora of issues with what I've done here,
> but it solved a few primary issues that seemed to outweigh the misuse.
>
> The issues were:
>
> 1) Too many machines needed to get MAAS HA
> 2) Chicken or egg?
> 3) Snowflakes!!!
> 4) No clear path to support MAAS HA
>
> My idea behind this was such that by using JAAS I am solving the chicken
> or the egg issue, and reducing the machines/infra needed to get MAAS HA.
> Deploying the MAAS infra with Juju eliminates the snowflake/lack of
> tracking and chips at the "No clear path to support MAAS HA".
>
> Thanks,
>
> James
>
> [0] http://paste.ubuntu.com/25891429/
> [1] http://paste.ubuntu.com/26058033/
>
> On Mon, Nov 27, 2017 at 12:09 AM, Dmitrii Shcherbakov <
> dmitrii.shcherba...@canonical.com> wrote:
>
>> Hi James,
>>
>> This is an interesting approach, thanks for taking a shot at solving this
>> problem!
>>
>> I thought of doing something similar a few months ago. The problematic
>> aspect here is the assumption of having a provider/substrate already
>> present for MAAS to be deployed - this is the chicken or the egg type of
>> problem.
>>
>> If you would like to take the MAAS charm route, manual provider could be
>> used with Juju to do that with pre-created hosts (which may be
>> containers/VMs/hosts all in a single model with this provider, regardless
>> of how they were deployed). There would be hosts for a Juju controller(s)
>> and MAAS region/rack controllers in the end.
>>
>> If you put both Juju controller and MAAS into containers, it gives you
>> some flexibility. If you are careful, you can even migrate those
>> containers. Running MAAS in an unprivileged container should be perfectly
>> possible https://github.com/CanonicalLtd/maas-docs/issues/700 - I am not
>> sure that the instructions that require a privileged container with loop
>> devices passed to it are relevant anymore.
>>
>> An alternative is to use the lxd provider (which can connect to a remote
>> daemon, not only localhost) but this is only one daemon per provider. For
>> HA purposes you would need several LXDs on different hosts and for this
>> provider to support network spaces because you may have MAAS hosts located
>> in different layer 2 networks with different subnets used. Cross-model
>> relations could be used to have a model per LXD provider but I am not sure
>> this is the best approach - units would be on different models with no
>> shared unit-level leadership.
>>
>> https://github.com/juju/juju/tree/develop/provider/lxd
>>
>> With the new LXD clustering work it might be possible overcome this
>> 

Re: Is there a universal interface I can use?

[John Meinel]

My apologies. I had done a bunch of local updates and had not yet pushed
them back to github.

There should be quite a bit of changes, including a lot more of the values
and changing interfaces.yaml, etc.

John
=:->


On Fri, Nov 24, 2017 at 6:24 PM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:

> Hey John, apart from those fields missing. (BTW check usage section of
> https://jujucharms.com/cassandra/36 for a list of fields)
>
> interface.yaml calls this interface elasticsearch. I was able to use
> this after I changed that.
>
> ;-)
>
>
> Cheers
>  Tilman
>
> On 23.11.2017 11:39, Tilman Baumann wrote:
> > Cool. Thanks
> >
> > The two fields I was interested in, username and password are mising
> > though. :D
> > But I'm thinking right now if I even want to go that route...
> >
> > On 23.11.2017 04:01, John Meinel wrote:
> >> I did start working on a Cassandra interface for something I was working
> >> on. I don't know that it is complete but
> >> https://github.com/jameinel/interface-cassandra
> >>
> >> Was my attempt at it.
> >>
> >> 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: How to open port with juju when no application is instlaled?

[John Meinel]

I had thought of that, but it only works if you then 'juju expose
postgresql' which would also expose the other ports of postgres

John
=:->

On Nov 23, 2017 23:03, "Tim Penhey"  wrote:

> I think you might be able to use:
>
>   juju run postgresql/0 'open-port 80'
>
> Tim
>
> On 24/11/17 06:54, Akshat Jiwan Sharma wrote:
> > Hi,
> >
> > I've used juju to deploy postgres on aws. On the same machine I've
> > installed an nginx server manually (i.e without juju) that listens on
> > ports 80 and 443. I want both of these ports to be open but juju command
> > open-port only works when an application is exposed.
> >
> > /open-port
> >
> > open-port registers a port or range to open on the public-interface. On
> > public clouds the port will only be open while the application is
> exposed./
> >
> > Now according to juju I only have one application (postgres) on my
> > machine, that I don't want exposed anyway. However I do want ports 80
> > and 443 to be accessible  publicly. Is adding a policy to aws manually
> > my only option here?
> >
> >
> > 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: How to open port with juju when no application is instlaled?

[John Meinel]

I believe there is an nginx charm, which you could have installed with
"juju deploy nginx --to X"  (where X is the machine id of the postgres
charm), and then used "juju expose nginx".
Is there a reason you prefer to install it manually?
One other option would be to co-locate the "ubuntu" charm and than use open
port from there, if you really don't want any other applications installed.
Generally we model ports-to-be-opened as part of an application, rather
than on a machine. So there's likely to be friction there without an
application to expose.

John
=:->

On Thu, Nov 23, 2017 at 9:54 PM, Akshat Jiwan Sharma 
wrote:

> Hi,
>
> I've used juju to deploy postgres on aws. On the same machine I've
> installed an nginx server manually (i.e without juju) that listens on ports
> 80 and 443. I want both of these ports to be open but juju command
> open-port only works when an application is exposed.
>
>
>
> *open-portopen-port registers a port or range to open on the
> public-interface. On public clouds the port will only be open while the
> application is exposed.*
>
> Now according to juju I only have one application (postgres) on my
> machine, that I don't want exposed anyway. However I do want ports 80 and
> 443 to be accessible  publicly. Is adding a policy to aws manually my only
> option here?
>
>
> 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: Is there a universal interface I can use?

[John Meinel]

I did start working on a Cassandra interface for something I was working
on. I don't know that it is complete but
https://github.com/jameinel/interface-cassandra

Was my attempt at it.

John
=:->

On Nov 23, 2017 02:26, "Haw Loeung"  wrote:

> Hi Tilman,
>
> On Wed, Nov 22, 2017 at 04:02:08PM +0100, Tilman Baumann wrote:
> > However, that doesn't seem to work. Juju complains the relation doesn't
> > exist.
> > $ juju add-relation cassandra-backup:database cassandra:database
> > ERROR no relations found
> >
> > So, is there a interface that I can (ab-)use in a similar way?
> >
> > I don't  want to build a full blown cassandra interface and at it to the
> > list.
>
> Not sure if you've seen this, but I did some work recently with
> something similar to backup Cassandra DBs:
>
> | https://jujucharms.com/u/hloeung/cassandra-backup/
>
> It's currently still experimental and uses the CQL COPY
> TO... commands. The Cassandra charm already ships out the required
> credentials so tools such as cqlsh should just work.
>
>
> Regards,
>
> Haw
>
> --
> 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: keystone charm

[John Meinel]

It seems like you would tend to use:
import os

os.makedirs(os.path.dirname(config_file))

Which doesn't treat a directory that already exists as a failure.
However, I'm guessing that there is some other expectation that the
directory should be created at some other time.

John
=:->


On Tue, Nov 7, 2017 at 3:57 PM, Giuseppe Attardi 
wrote:

> I run into a problem when adding a unit to keystone.
>
> The log shows this;
>
> 2017-11-07 11:18:11 DEBUG leader-settings-changed   File
> "/var/lib/juju/agents/unit-keystone-ba1-cl2-14/charm/
> hooks/leader-settings-changed", line 675, in leader_settings_changed
> 2017-11-07 11:18:11 DEBUG leader-settings-changed
>  update_all_identity_relation_units()
> 2017-11-07 11:18:11 DEBUG leader-settings-changed   File
> "/var/lib/juju/agents/unit-keystone-ba1-cl2-14/charm/
> hooks/leader-settings-changed", line 353, in update_all_identity_relation_
> units
> 2017-11-07 11:18:11 DEBUG leader-settings-changed CONFIGS.write_all()
> 2017-11-07 11:18:11 DEBUG leader-settings-changed   File
> "/var/lib/juju/agents/unit-keystone-ba1-cl2-14/charm/
> hooks/charmhelpers/contrib/openstack/templating.py", line 285, in
> write_all
> 2017-11-07 11:18:11 DEBUG leader-settings-changed [self.write(k) for k
> in six.iterkeys(self.templates)]
> 2017-11-07 11:18:11 DEBUG leader-settings-changed   File
> "/var/lib/juju/agents/unit-keystone-ba1-cl2-14/charm/
> hooks/charmhelpers/contrib/openstack/templating.py", line 276, in write
> 2017-11-07 11:18:11 DEBUG leader-settings-changed with
> open(config_file, 'wb') as out:
> 2017-11-07 11:18:11 DEBUG leader-settings-changed IOError: [Errno 2] No
> such file or directory: '/etc/keystone/keystone.conf'
> 2017-11-07 11:18:11 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "leader-settings-changed" failed: exit status 1
>
> and indeed the directory /etc/keystone is still missing.
> I am using Juju 2.2.4 and a variant of the keystone charm from
> stable/17.08.
>
> I solved the problem by adding:
>
> from charmhelpers.core.host import (mkdir) # Attardi
> mkdir(os.path.dirname(config_file)) # Attardi
>
> in templating.py before line 276.
> Doing so should be no harm, but I wonder whether this is the right
> solution.
>
> — Beppe
>
>
> --
> 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.3 beta2 is here!

[John Meinel]

...


> > Perhaps just:
> >
> >   juju deploy --map-machines A=B,C=D
> >
> > ... or some variant of that?
> >
> > Let's use the betas to refine and condense and clarify.
>
> +1 to that. I'm wondering if use-existing-machines is ever appropriate
> on its own, as the machine numbers in a model are ephemeral but
> machine numbers in a bundle are static.
>
>
Feedback from Admins that one of their big use case really is for bundle-a
to lay down a definition/base charm across everything, and bundle-b to be
meant as an exact overlay, and all of the machine-ids are exact matches.
And having to specify 0=0,...50=50 is a lot of ugly boilerplate.
While a plethora of options isn't great, addressing a significant use case
is.

I think we need to keep in mind that there really are 2 distinct use cases
for bundles:
1) Sharable snapshots of a particular application
2) Descriptions of an entire deployment, that people want to be able to
reproduce. (Teardown, redo, understand the description of an existing
deployment, etc.)

For things like the charm store, (1) is common, and the use cases around
machines being an abstract idea is common.
For many customer engagements, we end up with bundles that are very
specific to the site.

The '--use-existing-machines' is meant to flip the logic around
machine-identities are purely abstract, to machine identities are explicit
unless otherwise changed.

I agree that it would be good to expand upon the ability to have abstract
identifiers for machines in bundles, so that you don't end up with
1=2,2=3,3=1 sort of scenarios.

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

Re: Effect of lease tweaks

[John Meinel]

(sent too soon)

Summary:
before:
1043 local.oplog.rs
 868 juju.txns
 470 juju.leases

after:
 802 local.oplog.rs
 625 juju.txns
 267 juju.leases

So there seems to be a fairly noticeable decrease in load on the system
around leases (~70%). Again, not super scientific because I didn't measure
over enough time, deal with variation, all that kind of stuff. But at least
at a glimpse it looks pretty good.
As far as load around the global clock:
juju.globalclock  5ms 3ms  1ms
juju.globalclock 10ms 8ms  1ms
etc

So generally noticeable, but not specifically an issue.

Hopefully we'll see similar improvements in live systems. The main thing is
to make sure upgrade is smooth from 2.2 to 2.3 since the lease issue was a
pretty major crash of the system.

John
=:->

On Wed, Nov 1, 2017 at 6:43 PM, John A Meinel 
wrote:

> So I wanted to know if Andrew's changes in 2.3 are going to have a
> noticeable affect at scale on Leadership. So I went and set up a test with
> HA controllers running 10 machines each with 3 containers, and then
> distributing ~500 applications each with 3 units across everything.
> I started at commit 2e50e5cf4c3 which is just before Andrew's Lease patch
> landed.
>
> juju bootstrap aws/eu-west-2 --bootstrap-constraint
> instance-type=m4.xlarge --config vpc-id=
> juju enable-ha -n3
> # Wait for things to stablize
> juju deploy -B cs:~jameinel/ubuntu-lite -n10 --constraints
> instance-type=m4.xlarge
> # wait
>
> #set up the containers
> for i in `seq 0 9`; do
>   juju deploy -n3 -B cs:~jameinel/ubuntu-leader ul --to
> lxd:${i},lxd:${i},lxd:${i}
> done
>
> # scale up. I did this more in batches of a few at a time, but slowly grew
> all the way up
> for j in `seq 1 49`; do
>   echo $j
>   for i in `seq 0 9`; do
> juju deploy -B -n3 cs:~jameinel/ubuntu-leader ul${i}{$j} --to
> ${i}/lxd/0,${i}/lxd/1,${i}/lxd/2 &
>   done
>   time wait
> done
>
> I let it go for a while until "juju status" was happy that everything was
> up and running. Note that this was 1500 units, 500 applications in a single
> model.
> time juju status was around 4-10s.
>
> I was running 'mongotop' and watching 'top' while it was running.
>
> I then upgraded to the latest juju dev (c49dd0d88a).
> Now, the controller immediately started thrashing, with bad lease
> documents in the database, and eventually got to the point that it ran out
> of open file descriptors. Theoretically upgrading 2.2 => 2.3 won't have the
> same problem because the actual upgrade step should run.
> However, if I just did "db.leases.remove({})" it recovered.
> I ended up having to restart mongo and jujud to recover from the open file
> handles, but it did eventually recover.
>
> At this point, I waited again for everything to look happy, and watch
> mongotop and top again.
>
> These aren't super careful results, where I would want to run things for
> like an hour each and check the load over that whole time. Really I should
> have set up prometheus monitoring. But as a quick check, these are the top
> values for mongotop before:
>
>   nstotal readwrite
>   local.oplog.rs181ms181ms  0ms
>juju.txns120ms 10ms110ms
>  juju.leases 80ms 34ms 46ms
>juju.txns.log 24ms  4ms 19ms
>
>   nstotal readwrite
>   local.oplog.rs208ms208ms  0ms
>juju.txns140ms 12ms128ms
>  juju.leases 98ms 42ms 56ms
>  juju.charms 43ms 43ms  0ms
>
>   nstotal readwrite
>   local.oplog.rs220ms220ms  0ms
>juju.txns161ms 14ms146ms
>  juju.leases115ms 52ms 63ms
> presence.presence.beings 69ms 68ms  0ms
>
>   nstotal readwrite
>   local.oplog.rs213ms213ms  0ms
>juju.txns164ms 15ms149ms
>  juju.leases 82ms 35ms 47ms
> presence.presence.beings 79ms 78ms  0ms
>
>   nstotal readwrite
>   local.oplog.rs221ms221ms  0ms
>juju.txns168ms 13ms154ms
>  juju.leases 95ms 40ms 55ms
>juju.statuses 33ms 16ms 17ms
>
> totals:
> 1043 local.oplog.rs
> juju.txns 868
> juju.leases 470
>
> and after
>
>   nstotalreadwrite
>   local.oplog.rs 95ms95ms  0ms
>juju.txns 68ms 6ms 61ms
>  juju.leases 33ms13ms 19ms
>juju.txns.log 13ms 3ms 10ms
>
>   nstotal readwrite
>   local.oplog.rs200ms200ms  0ms
>juju.txns160ms 10ms150ms
>  

Re: backward compatibility

[John Meinel]

So I think its fine for giving feedback from client against a controller
(new client, old controller). Though how often we want to warn, have a way
to disable the warning (for how long, etc)?

The other side seems more difficult, as far as 2.0 client talking to a 2.4
controller. We could start assuming we're going to deprecate today, and
just start writing the 2.4 client to warn if you're running against a 2.8+
controller.

I think as for what we actually *support* (as in, be willing to make a
release if we break compatibility) is possibly even only 1 minor version.

It is also interesting to consider how we convey to users of the API (aside
from the Juju client itself), that they are running against older versions
of the Facades. They know that they are when they connect and inspect the
available versions. So they *could* inform the user, but there isn't any
sort of inherit pressure we put on them to do so.

I think saying that we offer "we will allow clients that are <1yr old to
stay compatible with current controllers", and vice versa seems ok, and
doesn't seem like a significant maintenance burden. (we could at least
release a new 2.X if we broke compatibility with 2.(X-2).)

John
=:->


On Mon, Oct 30, 2017 at 8:22 AM, Anastasia Macmood <
anastasia.macm...@canonical.com> wrote:

> Hi
>
> Now that we are settled on Juju 2, going forward we need to have a way
> to retire older minor versions in a user-friendly manner.
>
> We propose to use client/server version comparison to flag retiring
> versions in 3 distinct steps - deprecated, obsolete and unsupported.
>
> For example, we can determine that if your client version differs from
> your controller version by:
>
>   * 2 minor versions, you are running a deprecated back-end;
>   * 3 minor versions, you are running an obsolete back-end;
>   * 4+ minor versions, you are running an unsupported backend.
>
> In this world, it means that when you are running a 2.4 client, you will
> be told that the controller on:
>
>   * 2.2 is deprecated;
>   * 2.1 is obsolete;
>   * 2.0 is unsupported.
>
> This will be surfaced as a warning on 'juju status'.
>
> This approach will allow us to not just retire certain API versions, but
> also help triage bugs and set clear user expectations. Additional
> benefits for maintenance and support - we will not be carrying around
> huge amount of backward compatible code and craft... For example, does
> it really makes sense for us to carry around and cater for backward
> compatibility with Juju 2.0 when we are developing 2.6?
>
> Thoughts?
>
> Sincerely Yours,
>
> Anastasia
>
>
> --
> 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: backward compatibility

[John Meinel]

So I think its fine for giving feedback from client against a controller
(new client, old controller). Though how often we want to warn, have a way
to disable the warning (for how long, etc)?

The other side seems more difficult, as far as 2.0 client talking to a 2.4
controller. We could start assuming we're going to deprecate today, and
just start writing the 2.4 client to warn if you're running against a 2.8+
controller.

I think as for what we actually *support* (as in, be willing to make a
release if we break compatibility) is possibly even only 1 minor version.

It is also interesting to consider how we convey to users of the API (aside
from the Juju client itself), that they are running against older versions
of the Facades. They know that they are when they connect and inspect the
available versions. So they *could* inform the user, but there isn't any
sort of inherit pressure we put on them to do so.

I think saying that we offer "we will allow clients that are <1yr old to
stay compatible with current controllers", and vice versa seems ok, and
doesn't seem like a significant maintenance burden. (we could at least
release a new 2.X if we broke compatibility with 2.(X-2).)

John
=:->


On Mon, Oct 30, 2017 at 8:22 AM, Anastasia Macmood <
anastasia.macm...@canonical.com> wrote:

> Hi
>
> Now that we are settled on Juju 2, going forward we need to have a way
> to retire older minor versions in a user-friendly manner.
>
> We propose to use client/server version comparison to flag retiring
> versions in 3 distinct steps - deprecated, obsolete and unsupported.
>
> For example, we can determine that if your client version differs from
> your controller version by:
>
>   * 2 minor versions, you are running a deprecated back-end;
>   * 3 minor versions, you are running an obsolete back-end;
>   * 4+ minor versions, you are running an unsupported backend.
>
> In this world, it means that when you are running a 2.4 client, you will
> be told that the controller on:
>
>   * 2.2 is deprecated;
>   * 2.1 is obsolete;
>   * 2.0 is unsupported.
>
> This will be surfaced as a warning on 'juju status'.
>
> This approach will allow us to not just retire certain API versions, but
> also help triage bugs and set clear user expectations. Additional
> benefits for maintenance and support - we will not be carrying around
> huge amount of backward compatible code and craft... For example, does
> it really makes sense for us to carry around and cater for backward
> compatibility with Juju 2.0 when we are developing 2.6?
>
> Thoughts?
>
> Sincerely Yours,
>
> Anastasia
>
>
> --
> 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: default network space

[John Meinel]

So at the moment, I don't think Juju supports what you're looking for,
which is cross model relations without public addresses. We've certainly
discussed supporting all private for cross model. The main issue is that we
often drive parts of the firewalls (security groups) but without
understanding all the routing, it is hard to be sure whether things will
actually work.

I do believe the intended resolution is to use juju relate --via X, and
then X can be a space that isn't public. I'm pretty sure we don't have
everything wired up for that yet, and we want to make sure we can get the
current steps working well.

The very first thing I noticed in your first email was that charms should
*not* be aware of spaces. The abstractions for charms are around their
bindings (explicit or via binding their endpoints). The goal of spaces is
to provide human operators a way to tell charms about their environment.
But you shouldn't ever have to change the name of your space to match the
name a charm expects.

So if you do 'network-get BINDING -r relation' that should give you the
context you need to coordinate your network settings with the other
application. The intent is that we give you the right data so that it works
whether you are in a cross model relation or just related to a local app.

John
=:->


On Oct 13, 2017 19:59, "James Beedy"  wrote:

I can give a high level of what I feel is a reasonably common use case.

I have infrastructure in two primary locations; AWS, and MAAS (at the local
datacenter). The nodes at the datacenter have a direct fiber route via
virtual private gateway in us-west-2, and the instances in AWS/us-west-2
have a direct route  via the VPG to the private MAAS networks at the
datacenter. There is no charge for data transfer from the datacenter in and
out of us-west-2 via the fiber VPG hot route, so it behooves me to use this
and have the AWS instances and MAAS instances talk to each other via
private address.

At the application level, the component/config goes something like this:

The MAAS nodes at the data center have mgmt-net, cluster-net, and
access-net, interfaces defined, all of which get ips from their respective
address spaces from the datacenter MAAS.

I need my elasticsearch charm to configure elasticsearch such that
elasticsearch <-> elasticsearch talk on cluster-net, web server (AWS
instance) -> elasticsearch to talk across the correct space for the AWS
instance, and the access-net space for the MAAS instance (I'm thinking this
is where bindings and '--via' might come in handy).

(I know the openstack charms have to make similar network mitigation, for
which they use the bindings, I must just be looking at it backwards, or not
looking into network bindings which are the key here I think)

For example, my web server charm in AWS will be deployed to a NAT
space/subnet, and will only get a private ip from the AWS subnet. It needs
to give the ip to elasticsearch (deployed in MAAS), and to a loadbalancer
(deploy to different model and space in the same AWS VPC) - this all seems
like there should be no issues with getting it to happen because the web
server charm only has a single ip address to be handing out, but what I'm
after here is a consistent way to be able to retrieve this information at
the charm level - but I think what you are telling me is that if I use the
functionality correctly, then I won't have to do any mitigating at the
charm/network-get level.

Looks like I need to take a deeper dive into the network bindings at the
charm level and see how that functionality fits into the bigger picture to
make the whole picture make sense.

Thanks



> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about
> public
> vs private addresses in terms of what to put into relation data - the other
> remote unit should not be exposed to things in those terms.
>
> There's some doc here to explain things in more detail
>
> https://jujucharms.com/docs/master/developer-network-primitives
>
> The TL;DR: is that charms need to care about:
> - what address do I bind to (listen on)
> - what address do external actors use to connect to me (ingress)
>
> Depending on how the charm has been deployed, and more specifically
> whether it
> is in a cross model relation, the ingress address might be either the
> public or
> private address. Juju will decide based on a number of factors (whether
> models
> are deployed to same region, vpc, other provider specific aspects) and
> populate
> the network-get data accordingly. NOTE: for now Juju will always pick the
> public
> address (if there is one) for the ingress value for cross model relations
> - the
> algorithm to short circuit to a cloud local address is not yet finished.
>
> The content of the bind-addresses block is space aware in that these are
> filtered based on the space with which the specified endpoint is
> associated. The
> 

Re: default network space

[John Meinel]

So at the moment, I don't think Juju supports what you're looking for,
which is cross model relations without public addresses. We've certainly
discussed supporting all private for cross model. The main issue is that we
often drive parts of the firewalls (security groups) but without
understanding all the routing, it is hard to be sure whether things will
actually work.

I do believe the intended resolution is to use juju relate --via X, and
then X can be a space that isn't public. I'm pretty sure we don't have
everything wired up for that yet, and we want to make sure we can get the
current steps working well.

The very first thing I noticed in your first email was that charms should
*not* be aware of spaces. The abstractions for charms are around their
bindings (explicit or via binding their endpoints). The goal of spaces is
to provide human operators a way to tell charms about their environment.
But you shouldn't ever have to change the name of your space to match the
name a charm expects.

So if you do 'network-get BINDING -r relation' that should give you the
context you need to coordinate your network settings with the other
application. The intent is that we give you the right data so that it works
whether you are in a cross model relation or just related to a local app.

John
=:->


On Oct 13, 2017 19:59, "James Beedy"  wrote:

I can give a high level of what I feel is a reasonably common use case.

I have infrastructure in two primary locations; AWS, and MAAS (at the local
datacenter). The nodes at the datacenter have a direct fiber route via
virtual private gateway in us-west-2, and the instances in AWS/us-west-2
have a direct route  via the VPG to the private MAAS networks at the
datacenter. There is no charge for data transfer from the datacenter in and
out of us-west-2 via the fiber VPG hot route, so it behooves me to use this
and have the AWS instances and MAAS instances talk to each other via
private address.

At the application level, the component/config goes something like this:

The MAAS nodes at the data center have mgmt-net, cluster-net, and
access-net, interfaces defined, all of which get ips from their respective
address spaces from the datacenter MAAS.

I need my elasticsearch charm to configure elasticsearch such that
elasticsearch <-> elasticsearch talk on cluster-net, web server (AWS
instance) -> elasticsearch to talk across the correct space for the AWS
instance, and the access-net space for the MAAS instance (I'm thinking this
is where bindings and '--via' might come in handy).

(I know the openstack charms have to make similar network mitigation, for
which they use the bindings, I must just be looking at it backwards, or not
looking into network bindings which are the key here I think)

For example, my web server charm in AWS will be deployed to a NAT
space/subnet, and will only get a private ip from the AWS subnet. It needs
to give the ip to elasticsearch (deployed in MAAS), and to a loadbalancer
(deploy to different model and space in the same AWS VPC) - this all seems
like there should be no issues with getting it to happen because the web
server charm only has a single ip address to be handing out, but what I'm
after here is a consistent way to be able to retrieve this information at
the charm level - but I think what you are telling me is that if I use the
functionality correctly, then I won't have to do any mitigating at the
charm/network-get level.

Looks like I need to take a deeper dive into the network bindings at the
charm level and see how that functionality fits into the bigger picture to
make the whole picture make sense.

Thanks



> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about
> public
> vs private addresses in terms of what to put into relation data - the other
> remote unit should not be exposed to things in those terms.
>
> There's some doc here to explain things in more detail
>
> https://jujucharms.com/docs/master/developer-network-primitives
>
> The TL;DR: is that charms need to care about:
> - what address do I bind to (listen on)
> - what address do external actors use to connect to me (ingress)
>
> Depending on how the charm has been deployed, and more specifically
> whether it
> is in a cross model relation, the ingress address might be either the
> public or
> private address. Juju will decide based on a number of factors (whether
> models
> are deployed to same region, vpc, other provider specific aspects) and
> populate
> the network-get data accordingly. NOTE: for now Juju will always pick the
> public
> address (if there is one) for the ingress value for cross model relations
> - the
> algorithm to short circuit to a cloud local address is not yet finished.
>
> The content of the bind-addresses block is space aware in that these are
> filtered based on the space with which the specified endpoint is
> associated. The
> 

Re: Relation scope clarification

[John Meinel]

Ah, I guess that telegraf is actually gathering extra data from mysql or
postgres about database specific stats, and thus it should have a container
scoped relation because it wants to explicitly sit with postgres and
collect general machine information, as well as collect postgres specific
information. It isn't that telegraf is using postgresql as its data store,
its that it knows how to get extra statistical information about a database.

In that case, telegraf *should* use a container scope for its postgresql
interface. I wonder how that works when you have HA postgres, and each
telegraf connection to postgres is at least logically different. (telegraf
should care very much that it never connect to the postgresql on a
different machine and get its information.)

Is this a case where we actually need postgresql to offer up a
"pgsql-monitoring" relation, rather that use the existing "store my data in
postgres, 'pgsql' relation"
?

John
=:->


On Tue, Oct 17, 2017 at 11:16 PM, John Meinel <j...@arbash-meinel.com>
wrote:

> Why is the subordinate container scoped? The specific scope of container
> is that you only see the single instance that you share a machine with.
> Typically subordinates will use something like the juju-info relation
> because all they really care about is to be colocated on the same machine.
>
> I can't claim to have deep knowledge here, but I would guess that if one
> end of a relation is normally scoped, and the other is container scoped,
> then the intent is that the relation itself is container scoped and each
> unit of each application only sees the other unit that shares the same
> machine/container.
>
> Now in the telegraf case, I would expect telegraf to have 2 types of
> relations. 1 which is container scoped that means "I want to monitor this
> application", and *another* which must be global scoped which means "I want
> to use this application to store my data" (assuming telegraf is trying to
> connect to pgsql because it wants to record stuff in a database, if it just
> wanted to sit in the same machine and monitor postgres than I would have
> expected it to use juju-info for that relation.)
>
> I can't say that I've paged in all the bug comments yet, so I may be
> speaking from misinformation.
>
> John
> =:->
>
>
>
> On Tue, Oct 17, 2017 at 3:16 PM, Stuart Bishop <
> stuart.bis...@canonical.com> wrote:
>
>> Hi.
>>
>> A server declares a relation with standard scope. Lets use PostgreSQL
>> for example, which declares the following in metadata.yaml:
>>
>> provides:
>>   db:
>> interface: pgsql
>>
>> A client happens to be a subordinate, and declares its end of the
>> relation as container scoped. So in its metadata.yaml:
>>
>> requires:
>>   postgresql:
>> interface: pgsql
>> scope: container
>>
>> My first question is: Is this supported by Juju? Can charms have a
>> relation with a different scope at each end? I know it works in most
>> cases, but is it supported or just an accident of implementation?
>>
>> If the answer to that is yes, my second question is: If the relation
>> fails when the two charms declare a different scope, whose fault is
>> it?
>>
>> The problem I have is that if one end of the relation declares
>> container scope, then the relation is container scoped, and
>> relation-get calls attempting to inspect relation data of peers fail.
>> Is this a Juju bug, or does the PostgreSQL charm need to understand
>> this limitation and use some other mechanism if it wants the pgsql
>> relation to work in either global or container scope?
>>
>> Should relation-get return an error if a charm attempts to access
>> relation info from a peer unit, rather than only working if both ends
>> of the relation agree that the relation scope is global.
>>
>> There are several bugs open on this issue dealing with large scale
>> deployments and I'm not sure how to proceed.
>> https://bugs.launchpad.net/juju/+bug/1721295 is the juju one. I think
>> I can update the PostgreSQL charm to support requirements, but I'm
>> worried I would just be digging a deeper hole.
>>
>> --
>> Stuart Bishop <stuart.bis...@canonical.com>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Relation scope clarification

[John Meinel]

Why is the subordinate container scoped? The specific scope of container is
that you only see the single instance that you share a machine with.
Typically subordinates will use something like the juju-info relation
because all they really care about is to be colocated on the same machine.

I can't claim to have deep knowledge here, but I would guess that if one
end of a relation is normally scoped, and the other is container scoped,
then the intent is that the relation itself is container scoped and each
unit of each application only sees the other unit that shares the same
machine/container.

Now in the telegraf case, I would expect telegraf to have 2 types of
relations. 1 which is container scoped that means "I want to monitor this
application", and *another* which must be global scoped which means "I want
to use this application to store my data" (assuming telegraf is trying to
connect to pgsql because it wants to record stuff in a database, if it just
wanted to sit in the same machine and monitor postgres than I would have
expected it to use juju-info for that relation.)

I can't say that I've paged in all the bug comments yet, so I may be
speaking from misinformation.

John
=:->



On Tue, Oct 17, 2017 at 3:16 PM, Stuart Bishop 
wrote:

> Hi.
>
> A server declares a relation with standard scope. Lets use PostgreSQL
> for example, which declares the following in metadata.yaml:
>
> provides:
>   db:
> interface: pgsql
>
> A client happens to be a subordinate, and declares its end of the
> relation as container scoped. So in its metadata.yaml:
>
> requires:
>   postgresql:
> interface: pgsql
> scope: container
>
> My first question is: Is this supported by Juju? Can charms have a
> relation with a different scope at each end? I know it works in most
> cases, but is it supported or just an accident of implementation?
>
> If the answer to that is yes, my second question is: If the relation
> fails when the two charms declare a different scope, whose fault is
> it?
>
> The problem I have is that if one end of the relation declares
> container scope, then the relation is container scoped, and
> relation-get calls attempting to inspect relation data of peers fail.
> Is this a Juju bug, or does the PostgreSQL charm need to understand
> this limitation and use some other mechanism if it wants the pgsql
> relation to work in either global or container scope?
>
> Should relation-get return an error if a charm attempts to access
> relation info from a peer unit, rather than only working if both ends
> of the relation agree that the relation scope is global.
>
> There are several bugs open on this issue dealing with large scale
> deployments and I'm not sure how to proceed.
> https://bugs.launchpad.net/juju/+bug/1721295 is the juju one. I think
> I can update the PostgreSQL charm to support requirements, but I'm
> worried I would just be digging a deeper hole.
>
> --
> Stuart Bishop 
>
> --
> 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: JAAS confusion

[John Meinel]

So just changing your client isn't going to fix the issue, as it is a
server side issue that is refusing to destroy the models.

https://bugs.launchpad.net/bugs/1714409

Is at least one of them that might be relevant for your issue.

I also know that we have:
 https://bugs.launchpad.net/bugs/1721786

which is a different iteration of remove-model failing (we changed a lot of
code to use a shared pool of information about models, and it has a
slightly different issue as models get removed). But that one is 2.3
specific and I expect it to be fixed by early next week.

John
=:->

On Thu, Oct 12, 2017 at 11:59 AM, Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:

> Hi All,
>
> > I think the inability to remove a model that is half-dead might be
> fixed already in 2.3 but has to do with an issue around 2 critical
> documents that define a model, and one of them has been removed but not the
> other, which leads to a bunch of code that gets a different view of whether
> the model exists or not.
>
> I have a few models stuck in a state where I can't remove them. I gave
> juju 2.3 a try via the edge channel in the snap
> (2.3-beta2+develop-79cd92d), and it looks like the error message is
> different, but I still can't remove them.
>
> The old error message:
>
> ERROR cannot destroy model: failed to destroy model: state changing too
> quickly; try again soon
>
> The new error message:
>
> ERROR cannot destroy model: context deadline exceeded
>
> Is there an open bug that I can paste error messages and logs to?
>
> ~ PeteVG
>
>
>
> On Mon, Oct 9, 2017 at 4:18 PM John Meinel <j...@arbash-meinel.com> wrote:
>
>> The 6 accessible models is gone in 2.3 (IIRC), because it was actually
>> just reflecting some locally cached information about model numbers, but
>> wasn't actually being kept up to date properly.
>>
>> I think the inability to remove a model that is half-dead might be fixed
>> already in 2.3 but has to do with an issue around 2 critical documents that
>> define a model, and one of them has been removed but not the other, which
>> leads to a bunch of code that gets a different view of whether the model
>> exists or not.
>>
>> A different explanation could be that you create a model with the same
>> name with a different client and thus its actually the underlying UUID
>> doesn't exist, but there is a model collision. (Your local client new a
>> model named 'mymodel' with UUID 1234, but you had a different client that
>> deleted that model and created a new 'mymodel' with UUID 3456, but when
>> you're trying to 'juju destroy-model' we are using the 1234 UUID again. I'm
>> brainstorming, though, and wouldn't say concretely that it is definitely
>> true.)
>>
>> John
>> =:->
>>
>>
>> On Mon, Oct 9, 2017 at 9:42 PM, Tom Barber <t...@spicule.co.uk> wrote:
>>
>>> Hello folks
>>>
>>> Couple of random questions:
>>>
>>> juju destroy-model mymodel
>>> WARNING! This command will destroy the "mymodel" model.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue [y/N]? y
>>> ERROR cannot connect to API: model "mymodel" has been removed from the
>>> controller, run 'juju models' and switch to one of them.
>>> There are 6 accessible models on controller "jaas".
>>>
>>> juju models
>>> Controller: jaas
>>>
>>> Model  Cloud/Region   Status Machines  Cores  Access  Last
>>> connection
>>> mymodelaws/eu-west-1  available 5  9  -   never
>>> connected
>>>
>>>
>>>
>>> 2 things in this output, firstly how do I delete the model that seems
>>> stuck?
>>>
>>> secondly what is the 6 accessible models bit talking about?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>> --
>>> 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: JAAS confusion

[John Meinel]

The 6 accessible models is gone in 2.3 (IIRC), because it was actually just
reflecting some locally cached information about model numbers, but wasn't
actually being kept up to date properly.

I think the inability to remove a model that is half-dead might be fixed
already in 2.3 but has to do with an issue around 2 critical documents that
define a model, and one of them has been removed but not the other, which
leads to a bunch of code that gets a different view of whether the model
exists or not.

A different explanation could be that you create a model with the same name
with a different client and thus its actually the underlying UUID doesn't
exist, but there is a model collision. (Your local client new a model named
'mymodel' with UUID 1234, but you had a different client that deleted that
model and created a new 'mymodel' with UUID 3456, but when you're trying to
'juju destroy-model' we are using the 1234 UUID again. I'm brainstorming,
though, and wouldn't say concretely that it is definitely true.)

John
=:->


On Mon, Oct 9, 2017 at 9:42 PM, Tom Barber  wrote:

> Hello folks
>
> Couple of random questions:
>
> juju destroy-model mymodel
> WARNING! This command will destroy the "mymodel" model.
> This includes all machines, applications, data and other resources.
>
> Continue [y/N]? y
> ERROR cannot connect to API: model "mymodel" has been removed from the
> controller, run 'juju models' and switch to one of them.
> There are 6 accessible models on controller "jaas".
>
> juju models
> Controller: jaas
>
> Model  Cloud/Region   Status Machines  Cores  Access  Last
> connection
> mymodelaws/eu-west-1  available 5  9  -   never
> connected
>
>
>
> 2 things in this output, firstly how do I delete the model that seems
> stuck?
>
> secondly what is the 6 accessible models bit talking about?
>
> Thanks
>
> Tom
>
> --
> 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: "Attempting to connect to" takes a long time

[John Meinel]

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

John
=:->

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

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

Re: Jujucharms

[John Meinel]

It appears to be a more general Canonical outage, as irc.canonical.com is
also affected.

John
=:->


On Sat, Sep 9, 2017 at 6:03 PM, Tom Barber  wrote:

> Okay, own up, who killed Jujucharms.com whilst i'm trying to catch up on
> work? :)
>
>
> --
> 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: How to use LXC local image for new machine

[John Meinel]

If you're seeing "ubuntu-trusty" then you're using a version of Juju that
doesn't support the pressed. I believe reusing the cached image first was
added in 2.1, when we switched the naming scheme to be more specific.

John
=:->

On Sep 1, 2017 18:10, "Alex Kavanagh"  wrote:

>
>
> On Fri, Sep 1, 2017 at 11:47 AM, Stuart Bishop <
> stuart.bis...@canonical.com> wrote:
>
>> On 1 September 2017 at 02:37, fengxia  wrote:
>> > According to https://bugs.launchpad.net/juju/+bug/1650651, juju 2.1
>> supports
>> > using local image if its alias is `juju/series/arch` format.
>> >
>> > So following this, I created a local image and gave it an alias of this
>> > format, but juju deploy will still download ubuntu-trusty before
>> creating
>> > the container.
>>
>> I'm attaching the script I'm using, which is slightly modified from
>> the original version passed around and posted here. It might point you
>> to where your process is failing. I haven't done it manually myself.
>>
>
> Thanks Stuart; that looks really useful.
>
> Cheers
> Alex.
>
>
> --
> 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

[John Meinel]

The main reasons we don't directly offer cross cloud support is mostly
about user experience. There are potentially tricky things around getting
routing to work correctly between machines. Also there are several things
that are cached on controllers, which only helps if the controller is
"local" to the application machines.

JAAS actually works by running clustered controllers in each cloud and then
providing the redirection at a higher level. (essentially the switching and
picking the right controller for you.) There are other bits for running at
scale like having potentially multiple controllers per cloud, migrations,
etc when your dealing with scaling for other people.

Internally most of the work has been done to have a single controller
across clouds and it something we've wanted to do, but mostly on the back
burner. The nice use case there is to use Juju to deploy MAAS
infrastructure into LXD containers to then provision machines that can be
used to deploy Openstack and then controll applications on top of that
(with a k8s on the side, either on bare metal or on the openstack). The
controller is still local to all of these layers so lots of the potential
issues aren't there.

Doing that at a WAN scale is possible, but as it isn't something we've
tuned/optimized, it may not be a great experience.

It doesn't work *today*, because there are still a couple places that check
if the cloud type/provider matches. And while it's easy to find the first
ones and disable them, finding any deeper assertions that they are
protecting might be a bit harder.

John
=:->


On Sep 1, 2017 17:06, "Akshat Jiwan Sharma"  wrote:

> Many thanks Fen for the detailed guide and for starting a great
> discussion. I have a couple of ideas that I'd like to share as well as a
> few followups to your write-up.
>
> >The catch is, of course, the manual step of selecting the proper
> controller.
>
> Yes in addition to deploying the container on a particular cloud, right?
> Switching between providers or selecting them manually does not look like
> that much of a trouble to me,but taking care of controllers across
> providers does. So if the controller management can be simplified (like
> JAAS has, for instance) that's a bigger win for me.  This is the question
> that I was actually trying to ask but could not articulate well. What is
> stopping me from using a JUJU container deployed on aws to deploy charms on
> google compute platform? Is it the way juju has been desgined or is it
> something I'm missing?
>
> On your point number 2 I think essentially what we're talking about is
> bootstrapping juju across cloud providers? So once that is done we can use
> juju as it is (I guess I'm oversimplifying the high availability part
> here). I think conjure-up  simplifies this
> bootstrap process quite a bit. But I just came to know about it so I may be
> wrong in my understanding about some of its capabilities.
>
> The the other thing that I've been thinking about is terraform+juju
> integration. Since juju allows shell scripts
>  to be used
> as plugins we should be able to call all of terraform commands directly
> from juju (wrapped inside a helpful script).   Together they give me cross
> cloud ops ability. Of course it would be even more sweet if we could figure
> out a way to translate juju models into tf files.
>
> BTW I'd love to know more about how lennovo is using juju.
>
> Best,
> Akshat
>
> On Wed, Aug 30, 2017 at 8:26 PM, 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, 

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

[John Meinel]

Supporting multiple 'projects' in Openstack should already be supported by
passing different credentials during "juju add-model".

John
=:->

On Thu, Aug 31, 2017 at 1:55 AM, Giuseppe Attardi 
wrote:

> I have a slightly different requirement.
> Currently in our OpenStack cloud, if a user wants to use Juju, it must
> install a Juju controller in his project.
> It would be useful to use a single controller for the whole cloud and to
> just switch the project which the controller uses.
> Juju already can deal with multiple models, so it would just need to
> distinguish which models exist in a given project.
> It also should be possible to authenticate with OpenStack credentials in
> the Juju GUI.
>
> — Beppe
>
> > Date: Tue, 29 Aug 2017 19:29:14 +0530
> > From: Akshat Jiwan Sharma 
> > To: juju@lists.ubuntu.com
> > Subject: Juju-gui only show localhost as the deployment option
> > Message-ID:
> >    gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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: developer commands

[John Meinel]

I don't think you intended to send the email as PGP encrypted.

John
=:->


2017-08-28 12:06 GMT+04:00 Tim Penhey :

> -BEGIN PGP MESSAGE-
> Version: GnuPG v2
>
> hQIMA233D38ktbXXAQ/+P+Wl6YvVE3PVo1tsN/ynVPSeR5Xu3SfKLoRmXvxM0om/
> /LXYkelYeD5xuJCuLP87gNqiDqJnDZi4I0kOWkLjeG9xvAAJY/57tZLbv29quyKZ
> 9qVAKXbaCL8bsqHOZ9hsecpq8Bdkhu0P0J/VW0B/YYr3x8O3gggxYxD2EJD/+M4w
> Z0TJw6CYjEVy4nZ4dtn7TkBd/g68hcjU367VZLHdumxaCieoPm0Yq8jILP1FpfxQ
> DNyKs3PwPEtJJz1PAvq/pG01GeAiO+9+xl12KdCUDGlgUE7ph+U1Uw7On12zS+n1
> 1UzhyNxGD3lrjvJsM11pSi2R84o3ad+MGF3zCNbXowp6QowUytK5/xquFOqtBqze
> +yQ/3GcVaHnRnSHpxZt68rfq5DGCTqP233zKT11qo/Hxho3OmVP3tQpNh4Y6b2J6
> 6Cz7bH5L8MxaZexBEvMZcEfFMedLylVncxZeuvsGf1dSqGirIN4toejt69TUrD3C
> uF6aDySX5ruObPf7vkzzKXkXXN2qM9tXx9iMLaCRyYPCxt2lvGJYfbQtOupo4df/
> DgjjwGiXzjrUmAGpU1A6vCIotIw7pOsfVdlVicYRmkHoyShOWWv5oA6myqtcgmsO
> wGdAA2ZubE3p/WFL0Qfl8bPNGy4Yh22QdAAQsCLbhbWm0Q2LNDVqaSO3ODEBGf+F
> AQ4DdFn2rLtx3aMQA/4ncKGDjs/kcp1dxHM6FJJ8hu7vsMJxTZLdLWmx7ZIeBJNw
> 5RrnB0BAid03DHyPF8dMi+kgfiD1dwFMbBW8FTsKv1muHmjdePj27I/4K/5F7s08
> v1JuPAt0neI94Xkyx18+aih3gnmC2TCYgka9LhusDY2otlr1X1//vgAZj33OLgP+
> JNmQeq3LGP9Y10wHbnXcWQ5TTKD2rGDOLItNAYyVKTg6erHRR+8NlWLYz32XDN1D
> eITHN7BnvhbMcaiD+pQsU6J3zoPky1ZkW8GN4o8/lrOZW1zUnUnsl0RQmplNIKi1
> Zarch+m8+I8dmS4R9pdk69Zc3sAl114FMhp3C8bmsXDS6QEwYFfG7vFFN8kPPx0f
> MN2aj6SBCAq33DDWZRcUiqdTtxRaf6IFCcLZmYFNuEc4dloONE7zin0xUoGNmhoV
> m+CNwoeHvP72xcTclIqXwvH90HI1K8eSVE9PmvTSY/QW9fxv+Wp1pQSowbJmfoA1
> qQX1wU90tlEfnM9sYtr6ggjN0ee2WyhOc63p7U7W9L3r13D/nZggLMOzPW5krz5C
> K+/92ZGT7Eo8q8PQQzZvBrx4WMGDth/AGMBsRbf0LsCCzWcjKhMuKzzfxDbbgNc9
> EjPl6OzzjYnkuToXgCkkO9NrUN9wcpricMP54OFoK7eE+s085/oX1EYsDM/dyHTB
> TjhFbMUqyIvNM6muX3mzrEIokWIjGZEzuPQC2gu1+QMMPgU/BjN+9UuDsD/uT9pu
> s9/VwW9MKxZLQnNbRVCH0Ei134+MN4YSrSGuVuBTLObDHMp7XnFy7nGfVduyf4b3
> HuxPGIMwilVpM9gpC2puEqriUuxB/uw2PxBIVIhIyRgnqUB128XIIDJpIXzLOAlC
> ucM0Y2JB4/DNAiMUx+EeDT0lihu5xG6oigKTdI9NilAM03jEc4namoEJJtOAiMe/
> j14wm8VqBk0GvZ99EGnvOArV2MKZDziKyZdKTNtqyKLuyC4wI28mfmzfq1kd9Mxw
> MaYNbcn4dpTKZjQn0f5IF9+jwKh7YY6FuXqvFNpKkHBSOxu0ognj4oDej/qsJSz8
> oCW2rRfLwPzt9hGvM9VX62TGoCiR4TI488NE/0VlVZ/Bk0ehqg6casaUZxyfuFQO
> X8k5mNfOy2b+beq7CSo4sm9RiuGyOUBxMP4ur0hyT7xi8CQgB2KWBlsHn9k5H4Cu
> a/qB798tKrbkd0hn7uXIeSPcenBWF8LPGeIvQtHQ3ZJgmjxBwxsFLELioGgstpCl
> 93/Ny9K8mxNcEcAmj866g03Z5dBqsc9T+lg6viDMMKnQmqqlvC5l1VhTLf8D6Jpd
> oiW7M7Q76xi/uR+0m2ofRNf+FRfoOPGMKyXDTWlk1K+YjZp5LixAokgnOWKJeXB0
> rNy9V+E70ijvNtcTVvI5Cp2X7a+2PanCyj/2O37CBsE28TflYS0HMUUGZDmI+JUu
> DGAnEKBxxzEvu4jJ3gg68ipbbQRzr7eKlTc4xAGRZmlJkUloT2tqfp0kEPM=
> =Va56
> -END PGP MESSAGE-
>
> --
> 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: LXD bootstrap inside KVM failed

[John Meinel]

If you set up a space in MAAS and you declare that the VM is in that space,
then when you deploy something into a container, MAAS and Juju will
coordinate to get a Container set up onto a bridge connected to the
interface in the VM that is connected to the same space, with an IP address
from the range you declared in MAAS for that space and subnet. This also
scales to support multiple interfaces in different spaces, and however many
containers you request.
The only reason you end up private, is because you probably haven't
actually asked to be anywhere else. (Note this works the same for a machine
that is actually a VM as for a physical machine.)

John
=:->


On Tue, Aug 8, 2017 at 2:06 PM, Muhammad Yousuf Khan 
wrote:

> Thank you very much for the understanding right Mark. yes you are connect
> i was doing that however on your advice i manage to install it on new VM
> now one step is clear. but the problem is i notice. LXD is creating its own
> subnet and hide the guest behind the NAT. now the problem is how can LAN
> computers see LXD containers behind NAT. can't we use it the way we use it
> in bridge style. where it get the IP from LAN DHCP? instead of hiding
> behind NAT?
>
> in the context of same case. the whole idea deploying services like mysql,
> kyenotes any others will be fail as all the services will be behind NAT how
> come openstack services will integrate each other.
>
> Any knowledge sharing and tip will be highly appreciated.
> Thank,
> MYK
>
>
>
> On Tue, Aug 8, 2017 at 1:07 PM, Mark Shuttleworth  wrote:
>
>> On 08/08/17 08:31, Ante Karamatić wrote:
>>
>> If you want to run LXD on the same host where bind is running, you just
>> have to configure bind to *not* listen on LXD network:
>>
>> https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-listen
>> on-configuration/
>>
>> uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan  je
>> napisao:
>>
>>> Thanks for the update Ante. but since MAAS also used Bind for its own
>>> DNS resolution. how come one can use juju or lxd in absence of bind.
>>> any tip will be highly appreciated.
>>>
>>> Thanks,
>>> MYK
>>>
>>
>> MYK, if I understand your problem, you are running a MAAS controller on
>> the VM (which means bind is running) and you want to bootstrap a LXD
>> localhost Juju controller on that same machine. The question is why you
>> need to bootstrap a local Juju on a MAAS controller?
>>
>> As Ante says, you can configure the MAAS bind to avoid grabbing the lxd
>> network interfaces, which ill allow LXD's dnsmasq to work alongside bind
>> (because bind is focused on the main network interfaces, and dnsmasq is
>> grabbing the lxd network interfaces). But that's fiddly, you would need to
>> look carefully over the bind config files and make sure you don't
>> inadvertently break MAAS. If you are not familiar with bind configuration,
>> I don't recommend this approach.
>>
>> The easy answer is just to create a separate VM that points resolv.conf
>> at the MAAS DNS server, and bootstrap Juju locally in that VM. You can even
>> IIRC use MAAS to create that new VM, using the 'pod' functionality in 2.2.
>>
>> Mark
>>
>
>
> --
> 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: Consuming MongoDB from a Snap

[John Meinel]

I just wanted to note that some of the reason for 128GB was because 2.0 and
2.1 did leak memory over time. And if you have a leak you will always
eventually run out. In 2.2 we've fixed all the ones we've found so far and
we're actively doing some performance measuring to give better guidelines.
(If you are running X machines Y units you need a machine with A cores and
B memory.)
There are a lot of different ways to stress Juju (lots of small models, one
giant model, etc) and many performance numbers are soft (command X gets
slower, but doesn't fail, at what point do we consider it unusable).

All this to say, we've run ~2000 units against 16GB of memory. There really
shouldnt be a need to go to 128+ in the future. Current results show us to
be more CPU constrained (at least during deploy, etc) on normal RAM vs CPU
ratios.

John
=:->

On Jul 26, 2017 16:51, "Felipe Reyes"  wrote:

> On Fri, 23 Jun 2017 00:09:14 +
> Andrew Wilkins  wrote:
>
> > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits
> >  wrote:
> >
> > > We've had some discussion this week about whether Juju could use
> > > MongoDB from snap instead of a deb. This would make it easier for
> > > Juju to stay up to date with the latest MongoDB releases, avoiding
> > > the involved process getting each update into Ubuntu's update
> > > repository, as well as giving us all the other advantages of snaps.
> > >
> > > Two concerns were raised in this week's tech board meeting.
> > >
> > > *1. Does snapd work on all architectures that Juju supports?*
> > >
> > > The answer appears to be "yes with some caveats". For xenial
> > > onwards there are snapd packages for all the architectures the Juju
> > > team cares about.
> >
> > Ah, I thought the question was rather whether or not the mongo snap
> > existed for all of those architectures. I don't think it does. IIANM,
> > the snap comes from
> > https://github.com/niemeyer/snaps/blob/master/mongodb/
> mongo32/snapcraft.yaml,
> > which (if you look at the "mongodb" part, appears to only exist for
> > x86_64). So we would need to do some work on that first.
> >
> >
> > >https://packages.ubuntu.com/xenial/snapd
> > >
> > > For trusty only amd64, armhf and i386 appear to be supported.
> > >
> > >https://packages.ubuntu.com/trusty-updates/snapd
> > >
> > > This is probably ok. I think it's probably fine to start saying
> > > that new Juju controllers, on some architectures at least, need to
> > > be based on xenial or later.
> > >
> >
> > Since the controller machine isn't designed for workloads, it seems
> > fine to me to restrict them to latest LTS.
> >
> > One issue would be upgrades: we would either have to continue
> > supporting both snaps and debs for mongodb, or we would have to
> > disallow upgrading from a system that doesn't support snaps. That
> > would OK as long as there are no workloads on the controller, as we
> > could use migration.
>
> Some users run the controller in fairly big bare metal machines (e.g.
> 128G of RAM, I've seen even bigger controllers) and it won't be easy for
> them to have an extra machine to setup a new controller and run model
> migration, if their controller is HA then 3 spare machines are
> needed, this is hard to justify.
>
> --
> Felipe Reyes
> Software Sustaining Engineer @ Canonical
> # Launchpad: ~freyes | IRC: freyes
>
> --
> 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 to set state in @hook code block?

[John Meinel]

I'm pretty sure hooks execute in the parent directory.
So if you have
charm/
 hooks/
   db-relation-changed
   myfiles/
 test.yaml

you need to
 open("hooks/myfiles/test.yaml")


John
=:->

On Jul 20, 2017 04:58, "fengxia"  wrote:

> Hi Juju,
>
> I think I read at some point in the official document that you can't set
> state from hook.
>
> However, this is what I'm trying to achieve: in @hook('config-changed'), I
> will pass in a file path as a config value. Files are part of the charm so
> they are installed in /var/lib/juju/agents/unit-mycharm/myfiles/ on the
> unit node. But when @hook('config-changed') is triggered, my code to
> "open('/path/file')" actually complains "file not found". This makes me
> wonder that hook is not visible of the charm directory?
>
> So I'm thinking this can be worked around if I set_state("mystate") from
> hook. But doing so didn't trigger @when("mystate").
>
> What's the right way to do this then?
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> 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/mailm
> an/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

[John Meinel]

>
> ...
>


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

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

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

Re: Organising apiserver facades

[John Meinel]

I'd really like to see us split apart the facades-by-purpose. So we'd
collect the facades for Agents separately from facades for Users (and
possibly also facades for Controller).
I'm not sure if moving things just into 'facades' just moves the problem
around and leaves us with just a *different* directory that is a bit
cluttered.  But I'm +1 on things that would help organize the layout.

John
=:->

On Thu, Jul 6, 2017 at 1:55 PM, Andrew Wilkins  wrote:

> The juju/apiserver package currently has a whole lot of facade packages
> within it, as well as some other packages related to authentication,
> logging, and other bits and bobs. I find it difficult to navigate and tell
> what's what a lot of the time.
>
> I'd like to move the apiserver facade packages into a common "facades"
> sub-directory:
>   apiserver/facades/application
>   apiserver/facades/client
>   apiserver/facades/controller
>   etc.
>
> Any objections? Or alternative suggestions?
>
> Cheers,
> Andrew
>
> --
> 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 Deb Proxy to cache Debs to minimize time starting-up machines and its installation scripts

[John Meinel]

For what its worth, I use "apt-cacher-ng" to do this very thing and have
~/.local/share/juju/clouds.yaml:
clouds:
  lxd:
type: lxd
config:
  apt-http-proxy: http://192.168.0.106:3142
  apt-https-proxy: http://192.168.0.106:3142
  enable-os-upgrade: false

As long as you're keeping your images up to date (which is an attribute of
the LXD images which Juju should be setting with newer versions), then you
don't really need the 'apt upgrade' step because it just spends time to
find there is nothing new.

IIRC, I didn't have to do any custom configuration on apt-cacher-ng, nor
did I have to expose it to the bridge, because my host is already
configured to allow containers to talk to the host, so I can just configure
the hosts local network address. (I also use this same proxy for my local
MAAS deployment, so the apt cache gets used either way).

I don't know if there are advantages to squid-deb-proxy vs apt-cacher-ng, I
just found that "apt install apt-cacher-ng" and then setting the cloud
config was sufficient. (apt-cacher-ng also puts up a web page at a specific
port so you can see if the cache is getting used and what the hit/miss rate
is.)

John
=:->



On Thu, Jul 6, 2017 at 2:13 AM, Menno Smits 
wrote:

> Hi Naz,
>
> I use squid-deb-proxy to speed up deployments and it works well. If you're
> using the lxd provider install the proxy on the host machine so that all
> controllers and models benefit from the packages cached during previous
> deployments.
>
> Ensure that squid-deb-proxy is configured to listen on the address of the
> lxdbr0 bridge and remember to tell your Juju controllers and models to use
> the proxy via the apt-http-proxy option. There's more detail on setting
> this up here:  https://github.com/juju/juju/wiki/Faster-LXD . There a
> suggestion at the bottom of the page for defining a custom cloud type which
> includes the options for speeding up test/development deployments. That
> might be a good starting point for you.
>
> Regards,
> Menno
>
>
>
> On 6 July 2017 at 07:17, N. S.  wrote:
>
>> Hi,
>>
>> I am running juju latest version on local LXD.
>>
>> When deploying services,
>>
>> FOR each new machine, the "cloud init log" of the LXC in question
>> captures some "apt-get install "
>> before starting up the machine and then i see that it's up to the
>> "install" hook to install additional software and configure them.
>>
>> In my situation,
>> I have some repetitive machines.
>>
>>
>> I am thinking of using SQUID DEB PROXY or SIMILAR to cache the Debs for
>> faster deploy of subsequent machines.
>>
>> My questions are:
>>
>> I.
>> Where should I install and configure SQUID DEB PROXY or a similar PROXY?
>> Is it on
>> 1.
>> The host machine running the LXD including the controller juju-abcd-0?
>> Or
>> 2.
>> The controller machine juju-abcd-0 itself?
>>
>> So that I increase the "hit" rate of the needed-to-be-downloaded Debs and
>> decease the readiness time?
>>
>> II. What proxy do you recommend?
>>
>>
>> Thanks
>> Br
>> Naz
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Running KVM in addition to LXC on local LXD CLOUD

[John Meinel]

Generally you have to configure the profile of the containers (either by
configuring the default profiles or by altering the configuration of a
single container and then restarting that container).
If there are particular modules that you know you will need then you can
use "linux.kernel_modules" to ensure that those modules are loaded before
the container starts (because you cannot load modules from inside the
container).

I'm not entirely sure how you get /lib/modules to be present. It may be
that setting kernel_modules is sufficient and it will cause those
directories to be available, or more likely you'll want to do something
like bind mount the host's /lib/modules into the container (which you can
also do via the profile).

This is more a question about how to operate LXD than Juju, so I'm a little
unclear about some of the details. I'll refer you to some nice blog posts
from Stephane Graber who drives LXD development
  https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/

Openstack happens to be one of the more complex things to run inside
containers, so tends to have a lot of details about loading modules, etc:
  https://stgraber.org/2016/10/26/lxd-2-0-lxd-and-openstack-1112/

John
=:->


On Sun, Jul 2, 2017 at 4:56 PM, N. S.  wrote:

> Hi again,
>
> Another challenge related to same issue of empty /lib/modules from another
> LXC.
>
> make[4]: *** /lib/modules/4.8.0-56-lowlatency/*build*: No such file or
> directory.  Stop.
> CMakeFiles/ue_ip.dir/build.make:60: recipe for target 'ue_ip.ko' failed
> make[3]: *** [ue_ip.ko] Error 2
> CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/ue_ip.dir/all'
> failed
> make[2]: *** [CMakeFiles/ue_ip.dir/all] Error 2
> CMakeFiles/Makefile2:74: recipe for target 'CMakeFiles/ue_ip.dir/rule'
> failed
> make[1]: *** [CMakeFiles/ue_ip.dir/rule] Error 2
> Makefile:118: recipe for target 'ue_ip' failed
> make: *** [ue_ip] Error 2
>
>
> root@juju-0f8be6-10:/srv/openairinterface5g/cmake_targets# ls -l
> /lib/modules/
>
> total 0
>
> So,
>
> Is it possible to have the contents of the /lib/modules of the host
> inherited in each LXC?
>
> Thanks,
>
> BR,
> NS
>
>
>
> On Jul 2, 2017 3:47 PM, "N. S."  wrote:
>
> Hi Nicholas,
>
>
> Thanks, you are right.
>
> Yes , i used
>
>  sudo apt-get install --install-recommends linux-generic-hwe-16.04
>
>
>
> However, I have the following problem:
> I have not the host machine running 4.8 which is great, but the LXC
> underneath it have empty /lib/modules.
>
> In fact,
>
>
> * ON HOST Machine: *
> root@ns-HP:/lib/modules/4.8.0-56-lowlatency# ll
>
> total 4824
> drwxr-xr-x  5 root root4096 Jun 29 01:02 ./
> drwxr-xr-x  8 root root4096 Jun 29 01:01 ../
> lrwxrwxrwx  1 root root  42 Jun 14 19:40 build ->
> /usr/src/linux-headers-4.8.0-56-lowlatency/
> drwxr-xr-x  2 root root4096 Jun 14 19:27 initrd/
> drwxr-xr-x 14 root root4096 Jun 29 01:01 kernel/
> -rw-r--r--  1 root root 1133746 Jun 29 01:02 modules.alias
> -rw-r--r--  1 root root 1121947 Jun 29 01:02 modules.alias.bin
> -rw-r--r--  1 root root7271 Jun 14 19:25 modules.builtin
> -rw-r--r--  1 root root9059 Jun 29 01:02 modules.builtin.bin
> -rw-r--r--  1 root root  504755 Jun 29 01:02 modules.dep
> -rw-r--r--  1 root root  717645 Jun 29 01:02 * modules.dep.bin*
> -rw-r--r--  1 root root 285 Jun 29 01:02 modules.devname
> -rw-r--r--  1 root root  190950 Jun 14 19:25 modules.order
> -rw-r--r--  1 root root 386 Jun 29 01:02 modules.softdep
> -rw-r--r--  1 root root  543694 Jun 29 01:02 modules.symbols
> -rw-r--r--  1 root root  664280 Jun 29 01:02 modules.symbols.bin
> drwxr-xr-x  3 root root4096 Jun 29 01:01 vdso/
>
>
> root@ns-HP:/lib/modules/4.8.0-56-lowlatency# du -sh .
>
> *224M. *
>
>
> EXCERPT from within the LXC container called oai-spgw-0
> I can see the following error about empty /lib/modules.
>
> *rmmod: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not
> open builtin file '/lib/modules/4.8.0-56-lowlatency/modules.builtin.bin'*
>
>
>
> * rmmod: ERROR: Module gtp is not currently loaded modprobe: ERROR:
> ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file
> '/lib/modules/4.8.0-56-lowlatency/modules.dep.bin' modprobe: FATAL: Module
> gtp not found in directory /lib/modules/4.8.0-56-lowlatency 000142
> 2:497894 7FF1A14AE700 CRITI GTPv2-
> air-cn/src/gtpv1-u/gtpv1u_task.c:0105ERROR in loading gtp kernel module
> (check if built in kernel)*
>
> root@oai-spgw-0:~# uname -a
> Linux *oai-spgw-0 4.8.0-56-lowlatency* #61~16.04.1-Ubuntu SMP PREEMPT Wed
> Jun 14 13:24:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> root@*oai-spgw-0:/lib/modules# * ll
> total 3
> drwxr-xr-x  2 root root  2 Jun 19 23:52 ./
> drwxr-xr-x 22 root root 26 Jun 29 11:55 ../
>
> root@oai-spgw-0:/lib/modules#
>
>
> Is it possible to have the contents of the /lib/modules (224M) from the
> host to the sub-jacent LXC?
>
> Please advise.
>
> THanks
> BR,
> NS
>
> On Jun 29, 

Re: juju enable-ha with lxd servers

[John Meinel]

Are these 3 LXD containers on one machine, or 3 different host machines
where you want to run LXD containers?

At present we don't support scheduling across LXD hosts, so the easier way
would probably be to treat 3 host machines as separate 'manually
provisioned' machines, and then deploy to containers on those machines.
Which would be more:

 $ juju bootstrap manual/HOST1
 $ juju switch controller
 $ juju add-machine ssh:HOST2 # shows up as machine 1
 $ juju add-machine ssh:HOST3 # shows up as machine 2
 $ juju enable-ha -n3 --to 1,2

At which point you should be able to do things like:
 $ juju deploy APP --to lxd:0
 $ juju add-unit APP --to lxd:1
etc.

Juju itself doesn't have a way to decide to schedule to machine 0 vs 1 vs
2, which is why you have to do manual scheduling (deploy this application
to a container on this specific machine).

LXD provider (vs manual provider deploying into containers) is a bit
different, but would only support a single host machine.

I believe there is ongoing work in LXD itself to support clustering host
machines and do simple scheduling across them. But I don't think that work
is quite at the point where you could just point Juju at an LXD cluster and
have it all 'JustWork'.

John
=:->


On Fri, Jun 30, 2017 at 4:43 AM, Daniel Bidwell  wrote:

> I have 3 lxd servers, lxd0,lxd1, and lxd2.  I did a "juju bootstrap lxd
> lxd-prod" on lxd0.  Now I would like to enable juju high availability
> with machines lxd1 and lxd2 as secondary juju controllers.  I see that
> I want something like "juju enable-ha -n 3 -server lxd1 lxd2".  What
> form do I need lxd1 and lxd2 in to do this?
>
> I tried doing "juju add-machine ssh:root@lxd1"
> --
> 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: docker -> lxdbr0

[John Meinel]

Gotcha. Though I will say that looks more like its a bogus comment about a
file that this isn't. But I see what you're doing.

John
=:->


On Wed, Jun 21, 2017 at 5:29 PM, James Beedy <jamesbe...@gmail.com> wrote:

> It's in the comments at the top of the gist.
>
> On Jun 20, 2017, at 10:31 PM, John Meinel <j...@arbash-meinel.com> wrote:
>
> This definitely sounds interesting.
>
> You included the layer python code, but not the "daemon.json.j2" file.
> Isn't that part of getting the networking config in place?
>
> John
> =:->
>
>
> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> On integrating docker and lxd deployed apps ...
>>
>> My charm includes layer-docker, and exposes a simple api wrapping
>> docker-py to allow the charm to login to dockerhub, pull and run docker
>> images, and a few other standard docker ops. My dockerized apps talk to
>> elasticsearch, mysql, and redis, all of which get deployed via Juju in
>> production, but the developer envs don't have an easy time getting the
>> whole bunch up on their laptops due to some lxd <-> docker integration.
>> Today, I thought to deploy the mysql, elasticsearch, and redis to lxd aside
>> the docker containers on the same host for local development - I was
>> hitting a bump in the road getting the docker containers to talk to the
>> lxd, so I looked into how to set the default docker bridge, and came up
>> with this https://gist.github.com/jamesbeedy/39829a14fdc64583dfda
>> 4a6be1812aea
>>
>> ~James
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: docker -> lxdbr0

[John Meinel]

Gotcha. Though I will say that looks more like its a bogus comment about a
file that this isn't. But I see what you're doing.

John
=:->


On Wed, Jun 21, 2017 at 5:29 PM, James Beedy <jamesbe...@gmail.com> wrote:

> It's in the comments at the top of the gist.
>
> On Jun 20, 2017, at 10:31 PM, John Meinel <j...@arbash-meinel.com> wrote:
>
> This definitely sounds interesting.
>
> You included the layer python code, but not the "daemon.json.j2" file.
> Isn't that part of getting the networking config in place?
>
> John
> =:->
>
>
> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> On integrating docker and lxd deployed apps ...
>>
>> My charm includes layer-docker, and exposes a simple api wrapping
>> docker-py to allow the charm to login to dockerhub, pull and run docker
>> images, and a few other standard docker ops. My dockerized apps talk to
>> elasticsearch, mysql, and redis, all of which get deployed via Juju in
>> production, but the developer envs don't have an easy time getting the
>> whole bunch up on their laptops due to some lxd <-> docker integration.
>> Today, I thought to deploy the mysql, elasticsearch, and redis to lxd aside
>> the docker containers on the same host for local development - I was
>> hitting a bump in the road getting the docker containers to talk to the
>> lxd, so I looked into how to set the default docker bridge, and came up
>> with this https://gist.github.com/jamesbeedy/39829a14fdc64583dfda
>> 4a6be1812aea
>>
>> ~James
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: docker -> lxdbr0

[John Meinel]

This definitely sounds interesting.

You included the layer python code, but not the "daemon.json.j2" file.
Isn't that part of getting the networking config in place?

John
=:->


On Wed, Jun 21, 2017 at 6:16 AM, James Beedy  wrote:

> On integrating docker and lxd deployed apps ...
>
> My charm includes layer-docker, and exposes a simple api wrapping
> docker-py to allow the charm to login to dockerhub, pull and run docker
> images, and a few other standard docker ops. My dockerized apps talk to
> elasticsearch, mysql, and redis, all of which get deployed via Juju in
> production, but the developer envs don't have an easy time getting the
> whole bunch up on their laptops due to some lxd <-> docker integration.
> Today, I thought to deploy the mysql, elasticsearch, and redis to lxd aside
> the docker containers on the same host for local development - I was
> hitting a bump in the road getting the docker containers to talk to the
> lxd, so I looked into how to set the default docker bridge, and came up
> with this https://gist.github.com/jamesbeedy/
> 39829a14fdc64583dfda4a6be1812aea
>
> ~James
>
> --
> 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: multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

[John Meinel]

If you have started the machine yourself, you should be able to "juju
add-machine ssh:IP_ADDRESS" and then use that as a "juju deploy --to X"
target.

However, you will still need to tear down the machine when you're done. We
don't yet support multi-provider models. Likely we won't, but we will
support cross-model relations, which would let you have some of your
workloads on different providers. Though if you wanted it to be logically 1
application, with units in different providers, that wouldn't quite work
the way you wanted.

John
=:->

On Fri, Jun 16, 2017 at 1:05 PM, Patrizio Bassi 
wrote:

> Hi All,
>
> I have a need somehow similar (at least in the background) to what
> reported in the thread "How to Move a machine and its application from a
> Model to Another "(https://lists.ubuntu.com/arc
> hives/juju/2017-June/009111.html ).
>
> I deployed an openstack environment using juju bundles, this cloud hosts
> several applications and tenants.
>
> Coming to the Kubernates deploy, openstack is a "nested" provider for
> juju, the cloud is created and bootstrapped setting the openstack
> tenant/project (juju "tenant-name") we called "shared tenant". A minimal
> Kubernates setup is installed in this "shared" tenant. So far so good!
>
> We would like to deploy some kubernates-workers in other tenants, so each
> project can benefit the "shared" installation, monitoring, admin console,
> but run their own workload in their tenant space, so charge-back and quotas
> apply for instance.
>
> juju add-unit kubernates-worker can only allow in the same model, so the
> same cloud.
>
> Can we just force with --to statement? while for MaaS managed machine it's
> enough to have a known "ready" machine, it's not clear to me if in
> openstack i can do the same.
> 1) create a xenial ubuntu instance with network connectivity to
> juju-controller in "shared tenant"
> 2) tell juju to deploy the kubernates-worker units in that instance
>
> For instance, in case of unit-destroy, i would expect juju not to have the
> rights because the "tenant-name" is different.
>
> I saw the add-unit has a -m switch. Can, as far as the user is allowed to
> deploy, the -m switch be used to do a sort of "federation" between
> controllers?
> If not, any plan to implement something like that?
>
> Of course now i'm refering to the same cloud provider, but maybe in future
> this can led to hybrid multi-cloud installation.
>
> Thank you
>
> Patrizio
>
>
>
>
> --
> 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 with a series

[John Meinel]

"juju show-machine 10" is likely to tell you why we are failing to
provision the machine.

My guess is that we acctually need the alias to be "juju/centos7/amd64" for
Juju to recognize that it is the container image we want to be starting.

John
=:->


On Thu, Jun 15, 2017 at 8:37 PM, Daniel Bidwell  wrote:

> I am trying to deploy a charm that I am writing for both ubuntu and
> centos.  "lxc image alias list" produces:
>
> lxc image alias list
> +---+--+---+
> |   ALIAS   | FINGERPRINT  |DESCRIPTION|
> +---+--+---+
> | centos7   | 41c7bb494bbd | centos7   |
> +---+--+---+
> | juju/xenial/amd64 | 1e59027d1d58 | juju/xenial/amd64 |
> +---+--+---+
> | ubuntu-xenial | 1e59027d1d58 | ubuntu-xenial |
> +---+--+---+
>
> "juju deploy ~/charms/xenial/aubase1 --series centos7 aubasecentos"
> looks like it is starting, but a "juju status" produces:
>
> juju status
> ModelController  Cloud/Region Version
> default  lxd-testlocalhost/localhost  2.1.2
>
> App   Version  Status   Scale  CharmStore  Rev  OS  Notes
> aubase1active   1  aubase1  local5  ubuntu
> aubasecentos   waiting0/1  aubase1  local4  centos
>
> UnitWorkload  Agent   Machine  Public
> address  Ports  Message
> aubase1/4*  activeidle910.130.54.192
> aubasecentos/4  waiting   allocating  10  waiting
> for machine
>
> Machine  StateDNSInst idSeries   AZ
> 9started  10.130.54.192  juju-a0c4c9-9  xenial
> 10   downpendingcentos7
>
> What do I need to do to deploy a centos lxd container with my charm?
> --
> 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: Maximum AllWatcher frame size?

[John Meinel]

In 2.1 we did not chunk, in 2.2 we switch to gorilla/websocket which does
support chunking into frames. I don't think we do any internal "well that
would be too much information so we wont send it all".

John
=:->


On Wed, Jun 14, 2017 at 7:11 PM, Cory Johns 
wrote:

> https://github.com/juju/python-libjuju/issues/136 raises the issue that,
> for large models, the initial AllWatcher response frame can be large enough
> that it overruns the default maximum frame size of the websocket library
> (1MB).  We can increase this limit fairly easily, but I wanted to find out
> whether there is any maximum size from the Juju size and if large enough
> frames could get chunked into multiple frames?
>
> --
> 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: killing old dead controllers

[John Meinel]

If the machines are just gone (you manually destroyed them via 'lxc
stop/delete'). You can just do:
 juju unregister lxd-test

It will remove it from the local registry without trying to tear anything
down.

John
=:->


On Tue, Jun 13, 2017 at 8:17 AM, Daniel Bidwell  wrote:

> I have a machine with 2 dead controllers that I can't figure out how to
> delete.  A "juju controllers" produces the following:
>
> root@juju:~# juju controllers
> Use --refresh flag with this command to see the latest information.
>
> Controller  ModelUser   Access Cloud/Region
>   Models  MachinesHA  Version
> lxd-test-admin  superuser  lxd/localhost
>2 1  none  2.0.2
> test-lxd*   default  admin  superuser  localhost/
> localhost   2 1  none  2.1.3
>
> lxc list produces:
>
> root@juju:~# lxc list
> +--+---+--+--+--+---+
> | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
> +--+---+--+--+--+---+
>
> Any attemtp to remove, delete, kill, or destroy results in the command
> hanging and never coming back.  I have been trying to develop some
> local charms using lxd.  I know that this kind of testing and
> developemnt is hard on vms/containers, but throwing away the vm and
> reinstalling ubuntu is probably not the desired behaviour.
> --
> 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: killing old dead controllers

[John Meinel]

If the machines are just gone (you manually destroyed them via 'lxc
stop/delete'). You can just do:
 juju unregister lxd-test

It will remove it from the local registry without trying to tear anything
down.

John
=:->


On Tue, Jun 13, 2017 at 8:17 AM, Daniel Bidwell  wrote:

> I have a machine with 2 dead controllers that I can't figure out how to
> delete.  A "juju controllers" produces the following:
>
> root@juju:~# juju controllers
> Use --refresh flag with this command to see the latest information.
>
> Controller  ModelUser   Access Cloud/Region
>   Models  MachinesHA  Version
> lxd-test-admin  superuser  lxd/localhost
>2 1  none  2.0.2
> test-lxd*   default  admin  superuser  localhost/
> localhost   2 1  none  2.1.3
>
> lxc list produces:
>
> root@juju:~# lxc list
> +--+---+--+--+--+---+
> | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
> +--+---+--+--+--+---+
>
> Any attemtp to remove, delete, kill, or destroy results in the command
> hanging and never coming back.  I have been trying to develop some
> local charms using lxd.  I know that this kind of testing and
> developemnt is hard on vms/containers, but throwing away the vm and
> reinstalling ubuntu is probably not the desired behaviour.
> --
> 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: Is there a way to login to lxd containers of existing openstack?

[John Meinel]

'ssh ubuntu@IPADDRESS' generally works, as the 'ubuntu' user is the one
that is configured with .ssh/authorized_keys that match the keys described
by the model. I don't know what ssh keys you added to the model/what it was
bootstrapped with, but as long as you still have access to one of those ssh
keys you should be able to go in directly.

John
=:->


On Tue, Jun 6, 2017 at 9:15 AM, Sathyashankara bhat 
wrote:

> Hi,
> I did deploy openstack using Autopilot and it was all fine.
> However last week the server on which juju controller for openstack setup
> was running got bricked. So, lost a way to juju ssh to any of the openstack
> hypervisors. Is there a way ssh to the openstack in absence of old juju
> controller?
>
>
> --
> 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

[John Meinel]

...


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


Its essentially the 'manual provider', which is explicitly about you have
to tell Juju about the machines you might want to use.  I wouldn't think it
would be hard to create a model that used manual provisioning, but its
probably not something we've been driving as a great use case. Things like
needing the right routing, etc, mean its easy for people to add machines
that won't actually work, so it isn't something we've pushed.

John
=:->
-- 
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

[John Meinel]

...


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


Its essentially the 'manual provider', which is explicitly about you have
to tell Juju about the machines you might want to use.  I wouldn't think it
would be hard to create a model that used manual provisioning, but its
probably not something we've been driving as a great use case. Things like
needing the right routing, etc, mean its easy for people to add machines
that won't actually work, so it isn't something we've pushed.

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

Re: Exiting an unconditional juju debug-hooks session

[John Meinel]

Doesn't the equivalent of ^A ^D (from screen) also work to just disconnect
all sessions? (http://www.dayid.org/comp/tm.html says it would be ^B d). Or
switching to session 0 and exiting that one first?

I thought we had a quick way to disconnect, but its possible you have to
exit 2x and that fast firing hooks always catch a new window before you can
exit a second time.

John
=:->


On Sun, Jun 4, 2017 at 5:56 PM, Dmitrii Shcherbakov <
dmitrii.shcherba...@canonical.com> wrote:

> Hi everybody,
>
> Currently if you do
>
> juju debug-hooks  # no event (hook) in particular
>
> each time there is a new event you will get a new tmux window open and
> this will be done serially as there is no parallelism in hook
> execution on a given logical machine. This is all good and intentional
> but when you've observed the charm behavior and want to let it work
> without your interference again, you need to end your tmux session.
> This can be hard via `exit [status]` shell builtin when you get a lot
> of events (think of an OpenStack HA deployment) - each time you do
>
> ./hooks/$JUJU_HOOK_NAME && exit
>
> you are dropped into a session '0' and a new session is created for a
> queued event for which you have to manually execute a hook and exit
> again until you process the backlog.
>
> tmux list-windows
> 0: bash- (1 panes) [239x62] [layout bbde,239x62,0,0,1] @1 # <---
> dropping here after `exit`
> 1: update-status* (1 panes) [239x62] [layout bbe0,239x62,0,0,3] @3 (active)
>
> https://jujucharms.com/docs/stable/authors-hook-debug#
> running-a-debug-session
> "Note: To allow Juju to continue processing events normally, you must
> exit the hook execution with a zero return code (using the exit
> command), otherwise all further events on that unit may be blocked
> indefinitely."
>
> My initial thought was something like this - send SIGTERM to a child
> of sshd which will terminate your ssh session:
> unset n ; p=`pgrep -f 'tmux attach-session.*'$JUJU_UNIT_NAME` ; while
> [ "$n" != "sshd" ] ; do pc=$p ; p=$(ps -o ppid= $p | tr -d ' ') ; echo
> $p ; n=`basename $(readlink /proc/$p/exe || echo -n none)` ; done &&
> kill $pc
>
> as an agent waits for an SSH client to exit:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L53
>
> After thinking about it some more, I thought it would be cleaner to
> just kill a specific tmux session:
>
> tmux list-sessions
> gluster/0: 2 windows (created Fri Jun  2 20:22:30 2017) [239x62] (attached)
>
> ./hooks/$JUJU_HOOK_NAME && tmux kill-session -t $JUJU_UNIT_NAME
> [exited]
> Cleaning up the debug session
> no server running on /tmp/tmux-0/default
> Connection to 10.10.101.77 closed.
>
> The cleanup message comes from debugHooksClientScript that simply sets
> up a bash trap on EXIT:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/client.go#L51
>
> Judging by the code, it should be pretty safe to do so - unless there
> is a debug session in a debug context for a particular unit, other
> hooks will be executed regularly by an agent instead of creating a new
> tmux window:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/runner.go#L225
> debugctx := debug.NewHooksContext(runner.context.UnitName())
> if session, _ := debugctx.FindSession(); session != nil &&
> session.MatchHook(hookName) {
> logger.Infof("executing %s via debug-hooks", hookName)
> err = session.RunHook(hookName, runner.paths.GetCharmDir(), env)
> } else {
> err = runner.runCharmHook(hookName, env, charmLocation)
> }
> return runner.context.Flush(hookName, err)
>
> There are two scripts:
>
> - a client script executed via an ssh client when you run juju debug-hooks
> - a server script which is executed in the `RunHook` function by an
> agent and creates a new window for an existing tmux session.
>
> client side:
> https://github.com/juju/juju/blob/develop/cmd/juju/
> commands/debughooks.go#L137
> script := base64.StdEncoding.EncodeToString([]byte(unitdebug.ClientScript(
> debugctx,
> c.hooks)))
> innercmd := fmt.Sprintf(`F=$(mktemp); echo %s | base64 -d > $F; . $F`,
> script)
> args := []string{fmt.Sprintf("sudo /bin/bash -c '%s'", innercmd)}
> c.Args = args
> return c.sshCommand.Run(ctx)
>
> Server script:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L90
> Client script:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/client.go#L49
>
> A worker waits until a client exists by monitoring a file lock at
> ClientExitFileLock:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L34
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L53
> A path of a lock itself for a particular session:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/common.go#L24
>
> ---
>
> If this approach with killing a tmux session is fine then I could
> create a PR for the doc repo and for the description in the
> 

Re: Exiting an unconditional juju debug-hooks session

[John Meinel]

Doesn't the equivalent of ^A ^D (from screen) also work to just disconnect
all sessions? (http://www.dayid.org/comp/tm.html says it would be ^B d). Or
switching to session 0 and exiting that one first?

I thought we had a quick way to disconnect, but its possible you have to
exit 2x and that fast firing hooks always catch a new window before you can
exit a second time.

John
=:->


On Sun, Jun 4, 2017 at 5:56 PM, Dmitrii Shcherbakov <
dmitrii.shcherba...@canonical.com> wrote:

> Hi everybody,
>
> Currently if you do
>
> juju debug-hooks  # no event (hook) in particular
>
> each time there is a new event you will get a new tmux window open and
> this will be done serially as there is no parallelism in hook
> execution on a given logical machine. This is all good and intentional
> but when you've observed the charm behavior and want to let it work
> without your interference again, you need to end your tmux session.
> This can be hard via `exit [status]` shell builtin when you get a lot
> of events (think of an OpenStack HA deployment) - each time you do
>
> ./hooks/$JUJU_HOOK_NAME && exit
>
> you are dropped into a session '0' and a new session is created for a
> queued event for which you have to manually execute a hook and exit
> again until you process the backlog.
>
> tmux list-windows
> 0: bash- (1 panes) [239x62] [layout bbde,239x62,0,0,1] @1 # <---
> dropping here after `exit`
> 1: update-status* (1 panes) [239x62] [layout bbe0,239x62,0,0,3] @3 (active)
>
> https://jujucharms.com/docs/stable/authors-hook-debug#
> running-a-debug-session
> "Note: To allow Juju to continue processing events normally, you must
> exit the hook execution with a zero return code (using the exit
> command), otherwise all further events on that unit may be blocked
> indefinitely."
>
> My initial thought was something like this - send SIGTERM to a child
> of sshd which will terminate your ssh session:
> unset n ; p=`pgrep -f 'tmux attach-session.*'$JUJU_UNIT_NAME` ; while
> [ "$n" != "sshd" ] ; do pc=$p ; p=$(ps -o ppid= $p | tr -d ' ') ; echo
> $p ; n=`basename $(readlink /proc/$p/exe || echo -n none)` ; done &&
> kill $pc
>
> as an agent waits for an SSH client to exit:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L53
>
> After thinking about it some more, I thought it would be cleaner to
> just kill a specific tmux session:
>
> tmux list-sessions
> gluster/0: 2 windows (created Fri Jun  2 20:22:30 2017) [239x62] (attached)
>
> ./hooks/$JUJU_HOOK_NAME && tmux kill-session -t $JUJU_UNIT_NAME
> [exited]
> Cleaning up the debug session
> no server running on /tmp/tmux-0/default
> Connection to 10.10.101.77 closed.
>
> The cleanup message comes from debugHooksClientScript that simply sets
> up a bash trap on EXIT:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/client.go#L51
>
> Judging by the code, it should be pretty safe to do so - unless there
> is a debug session in a debug context for a particular unit, other
> hooks will be executed regularly by an agent instead of creating a new
> tmux window:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/runner.go#L225
> debugctx := debug.NewHooksContext(runner.context.UnitName())
> if session, _ := debugctx.FindSession(); session != nil &&
> session.MatchHook(hookName) {
> logger.Infof("executing %s via debug-hooks", hookName)
> err = session.RunHook(hookName, runner.paths.GetCharmDir(), env)
> } else {
> err = runner.runCharmHook(hookName, env, charmLocation)
> }
> return runner.context.Flush(hookName, err)
>
> There are two scripts:
>
> - a client script executed via an ssh client when you run juju debug-hooks
> - a server script which is executed in the `RunHook` function by an
> agent and creates a new window for an existing tmux session.
>
> client side:
> https://github.com/juju/juju/blob/develop/cmd/juju/
> commands/debughooks.go#L137
> script := base64.StdEncoding.EncodeToString([]byte(unitdebug.ClientScript(
> debugctx,
> c.hooks)))
> innercmd := fmt.Sprintf(`F=$(mktemp); echo %s | base64 -d > $F; . $F`,
> script)
> args := []string{fmt.Sprintf("sudo /bin/bash -c '%s'", innercmd)}
> c.Args = args
> return c.sshCommand.Run(ctx)
>
> Server script:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L90
> Client script:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/client.go#L49
>
> A worker waits until a client exists by monitoring a file lock at
> ClientExitFileLock:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L34
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/server.go#L53
> A path of a lock itself for a particular session:
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/debug/common.go#L24
>
> ---
>
> If this approach with killing a tmux session is fine then I could
> create a PR for the doc repo and for the description in the
> 

Re: OS X VMS on JAAS

[John Meinel]

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.

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.

John
=:->


On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@canonical.com> wrote:

> I do not understand how this works. Could someone with knowledge of how
> jujud on a  controller communicates with jujud agents on units describe how
> that is done?
>
> My limited understanding must be wrong give that James has this working.
>
> This is what I thought:
>
> On most cloud providers: add-machine instructs the cloud provider to start
> a new instance and the cloud-config passed to cloud-init includes how to
> download jujud agent and run it and configure it with public key trust of
> the juju controller.
>
> On manually added machine: same thing only instead of cloud-init and
> cloud-config an ssh connection is used to perform the same commands.
>
> I had thought the juju controller was initiating the ssh-connection to the
> address given in the add-machine command and that a non-internet routable
> address would simply not work as the controller cannot open any TCP
> connection to it. This is where my understanding stops.
>
> Please, anyone, describe how this works?
> --
> Jay
>
>
> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> I think the primary advantage being less clutter to the end user. The
>> difference between the end user have to bootstrap and control things from
>> inside the vm vs from their host. For some reason this small change made
>> some of my users who were previously not really catching on, far more apt
>> to jump in. I personally like it because these little vms go further when
>> they don't have the controller on them as well. @jameinel totally, possibly
>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>> possibly in another.
>>
>> ~James
>>
>> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com> wrote:
>>
>> Interesting. I wouldn't have thought to use a manually added machine to
>> use JAAS to deploy applications to your local virtualbox. Is there a reason
>> this is easier than just "juju bootstrap lxd" from inside the VM?
>>
>> I suppose our default lxd provider puts the new containers on a NAT
>> bridge, though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
>>
>> John
>> =:->
>>
>>
>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-cont
>>> ainers-to-virtualbox-vms-on-os-x-a06a8046756a
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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

[John Meinel]

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.

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.

John
=:->


On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@canonical.com> wrote:

> I do not understand how this works. Could someone with knowledge of how
> jujud on a  controller communicates with jujud agents on units describe how
> that is done?
>
> My limited understanding must be wrong give that James has this working.
>
> This is what I thought:
>
> On most cloud providers: add-machine instructs the cloud provider to start
> a new instance and the cloud-config passed to cloud-init includes how to
> download jujud agent and run it and configure it with public key trust of
> the juju controller.
>
> On manually added machine: same thing only instead of cloud-init and
> cloud-config an ssh connection is used to perform the same commands.
>
> I had thought the juju controller was initiating the ssh-connection to the
> address given in the add-machine command and that a non-internet routable
> address would simply not work as the controller cannot open any TCP
> connection to it. This is where my understanding stops.
>
> Please, anyone, describe how this works?
> --
> Jay
>
>
> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> I think the primary advantage being less clutter to the end user. The
>> difference between the end user have to bootstrap and control things from
>> inside the vm vs from their host. For some reason this small change made
>> some of my users who were previously not really catching on, far more apt
>> to jump in. I personally like it because these little vms go further when
>> they don't have the controller on them as well. @jameinel totally, possibly
>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>> possibly in another.
>>
>> ~James
>>
>> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com> wrote:
>>
>> Interesting. I wouldn't have thought to use a manually added machine to
>> use JAAS to deploy applications to your local virtualbox. Is there a reason
>> this is easier than just "juju bootstrap lxd" from inside the VM?
>>
>> I suppose our default lxd provider puts the new containers on a NAT
>> bridge, though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
>>
>> John
>> =:->
>>
>>
>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-cont
>>> ainers-to-virtualbox-vms-on-os-x-a06a8046756a
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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: OS X VMS on JAAS

[John Meinel]

Interesting. I wouldn't have thought to use a manually added machine to use
JAAS to deploy applications to your local virtualbox. Is there a reason
this is easier than just "juju bootstrap lxd" from inside the VM?

I suppose our default lxd provider puts the new containers on a NAT bridge,
though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.

John
=:->


On Fri, Jun 2, 2017 at 8:33 AM, James Beedy  wrote:

> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-
> virtualbox-vms-on-os-x-a06a8046756a
>
> --
> 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: OS X VMS on JAAS

[John Meinel]

Interesting. I wouldn't have thought to use a manually added machine to use
JAAS to deploy applications to your local virtualbox. Is there a reason
this is easier than just "juju bootstrap lxd" from inside the VM?

I suppose our default lxd provider puts the new containers on a NAT bridge,
though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.

John
=:->


On Fri, Jun 2, 2017 at 8:33 AM, James Beedy  wrote:

> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-
> virtualbox-vms-on-os-x-a06a8046756a
>
> --
> 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 test doesn't work

[John Meinel]

I'm pretty sure 'charm' tools have moved over to using 'snap install charm'
as the preferred method for getting the charm tools. I'm not sure that
there is a way to deprecate/remove the versions that are in the archives.
For something like Zesty, it probably would have been possible to just
remove it, I think it was just an oversight.

I'm not sure about 'juju test' itself. It is actually a plugin supplied by
the charm tools (I believe) rather than something that is part of the core
'juju' packaging. (The binary is actually /usr/bin/juju-test, and a while
back people asked that anything we find in $PATH as 'juju-foo' can be
called as just 'juju foo')

It does seem like the 'juju-test' plugin has not been kept up-to-date for
juju-2.X charm development. Or maybe it has but you need to 'snap install
charm' rather than using a debian package. (offhand I doubt it, because a
snap install charm would not give you a juju-test in your path).

I *do* believe that there was a push to actually split "tools for Charm
developers" away from "tools for people operating software with Juju". So
likely there is something like "charm test" that you should actually be
using, rather than an old, deprecated 'juju-test' that we shouldn't be
installing anymore.

John
=:->



On Wed, May 31, 2017 at 11:57 AM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:

> I prepared two min charms which I needed for a customer.
> cs:~tilmanbaumann/logstash-conf-d-1
> https://github.com/tbaumann/charm-logstash-conf-d
> cs:~tilmanbaumann/logstash-input-elasticsearch-1
> https://github.com/tbaumann/charm-logstash-input-elasticsearch
>
> Those are subordninate charms that can be used like plugins to load
> custom configurations in logstash (/etc/logstash/conf.d/)
> Or to connect logstash to elasticsearch via relations.
>
> During this development I found a number of bugs that made it quite hard
> to be productive.
> Charm tools is broken. Thank god there is a custom ppa for it.
> https://bugs.launchpad.net/ubuntu/+source/charm-tools/+bug/1660004
>
> And juju test doesn't work. That is why my charms don't have tests yet.
> https://bugs.launchpad.net/juju/+bug/1608723
>
> I felt quite confident about my manual tests and I see no reason to
> believe #1608723 will be gone soon, so I decided to submit my charms for
> review anyway.
> Probably wasting your time. But I was eager to see some feedback.
>
> But, I couldn't. The review form at https://review.jujucharms.com/ will
> respond with a empty response (Firefox says https protocol error. Chrome
> says empty response.)
> Where would I report that as a bug?
>
> So you see, right now quite a lot is broken for charm developers. At
> least those running Zesty.
>
>
> Please excuse my mini rant about infrastructure. I suppose this will get
> better again.
> But perhaps someone can offer some opinions about my charms? :D
>
>
> Cheers
>  Tilman Baumann
>
>
> PS: https://github.com/tbaumann/charm-logstash-conf-d has a tests branch
> with a initial testing idea. But I could never test it...
> The layer code is slightly more current than the published charms. I
> found a few typos I think.
>
> --
> 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: database-relation-join not invoked

[John Meinel]

It depends if your hook goes into 'error' state or 'blocked'.
Error should generally be avoided because it is a signal to Juju that you
can no longer make forward progress (generally meant to mean there is a
logic bug/typo/etc in your charm). With Error Juju may retry the hook that
failed but it will not run other hooks until error is cleared (juju
resolved)

Using 'status-set blocked [message]' you can report to the user that you
are missing a relation, but Juju will continue to fire other hooks as
normal.

John
=:->

On May 25, 2017 21:00, "Giuseppe Attardi"  wrote:

> I have written a charm for OpenStack Gnocchi.
> The service requires a postgresql database relation.
>
> The start hook fails, of course, because the relation is not set.
>
> I expected that, but I expected that when I issue
>
> juju add-relation gnocchi postgresql:db
>
> it will invoke the database-relation-joined hook, which does set the
> required parameter and then start would work.
> However the hook is not invoked: as a sanity check I set a juju-log
> message in it and it does not run at all.
>
> Is it correct to assume that add-relation will always trigger
> database-relation-join?
>
> A second question, I would like to avoid to start the service until the
> relation has been joined.
> What is the best way to test for the relation to be present?
>
> I tried with
>
> db=`relation-get -r database host`
>
> but it fails with:
>
> INFO start error: invalid value "database" for flag -r: invalid
> relation id
>
> I am using juju-2.1.2
>
> Thanks for the help.
>
> — 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

Re: charm build -s centos7 does nothing special?

[John Meinel]

I would imagine it would be something like that, but I don't actually know
how 'series' is wired into the charm build tool.

John
=:->


On Wed, May 24, 2017 at 4:35 AM, fengxia <fx...@lenovo.com> wrote:

> Interesting. So you mean the diff is really depending on what I put in
> scripts. If so, my immediate thought is that charm build does nothing
> special for series then, since I'm coding the "if series=='ubuntu'...
> else:", the build script cannot touch my code, right?
>
> On 05/20/2017 03:17 AM, John Meinel wrote:
>
> I would guess the charm can define series specific build instructions, but
> that layer-basic doesn't, itself, have different instructions for centos7.
>
> John
> =:->
>
>
> On Sat, May 20, 2017 at 10:07 AM, fengxia <fx...@lenovo.com> wrote:
>
>> Hi Juju,
>>
>> I made a hello world charm based on charm tutorial, which includes
>> layer-basic. I noticed that "charm build" can take a switch "-s series". I
>> specified "-s centos7", and diff the result from default built which is
>> "trusty". There is no material different between two builds.
>>
>> Is this expected?
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794
>> 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/mailm
>> an/listinfo/juju
>>
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794fx...@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

Re: JUJU_UNIT_NAME no longer set in env

[John Meinel]

juju run --application runs as every unit of the application, thus we have
individual units (if you have 2 units of an application on a machine it
will run twice on that machine). 'juju run --unit" obviously runs as a
unit. 'juju machine' can't, because we don't have any unit associated with
it.

John
=:->


On Tue, May 23, 2017 at 5:12 PM, Jay Wren  wrote:

> I was under the impression that `juju run --unit` does run in a hook
> context. In fact, the help for `juju help run` explicitly says:
>
> ```
> Commands run for applications or units are executed in a 'hook context' for
> the unit.
> ```
>
> A quick test:
>
> ```
> >  juju run --unit u4/0 'echo $JUJU_UNIT_NAME'
> u4/0
> ```
>
> So indeed, $JUJU_UNIT_NAME is set when using `juju run --unit`.
>
> However, another quick test shows that it is not set in the machine case:
>
> ```
> >  juju run --machine 0 'echo $JUJU_UNIT_NAME'
>
> ```
>
> But it is set when using --application, which surprised me:
> ```
> juju run --application u4 'echo $JUJU_UNIT_NAME'
> - Stdout: |
> u4/0
>   UnitId: u4/0
> - Stdout: |
> u4/1
>   UnitId: u4/1
> ```
>
> James, maybe you have used ssh to get shell on the machine instead of
> using juju run?
>
> --
> Jay
>
> On Tue, May 23, 2017 at 7:57 AM, Nick Veitch 
> wrote:
>
>>
>>
>> On 23 May 2017 at 11:23, Junien Fridrick 
>> wrote:
>>
>>>
>>> You can run some hooks like config-changed with e.g. :
>>>
>>> $ juju run --unit foo/0 hooks/config-changed
>>>
>>
>> You can run any hook like that, but if it requires a hook context (as in
>> the example of trying to read $JUJU_UNIT_NAME ) it won't work. A lot of
>> hooks in common charms don't need context, but you can't guarantee that.
>>
>> N.B. Also when using `juju debug-hooks` once any hook fires and you are
>> in the hook environment, you can then execute any hook (not just the one
>> that has been triggered), if you need to test them.
>>
>> --
>> Nick Veitch,
>> Documentation
>> Canonical
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: JUJU_UNIT_NAME no longer set in env

[John Meinel]

So you're running the 'install' hook directly, are you currently in a 'juju
debug-hooks' session, or are you just changing into that directory?

Juju sets it during the run of a charm hook, but it is not set globally on
the machine (we can't set UNIT globally anyway, because you can colocate
many units on one machine).

If you need to run the install hook, I *think* you could get into a charm
context with "juju-run ???/install". I don't know whether you'd need to
give the full path, just the last bit of the hook path, or what exactly. I
*think* the hook context actually runs in the directory just above 'hooks',
but I'm not 100% positive.

John
=:->


On Tue, May 23, 2017 at 9:49 AM, Ian Booth  wrote:

> FWIW, Juju itself still sets JUJU_UNIT_NAME
>
> https://github.com/juju/juju/blob/develop/worker/uniter/
> runner/context/context.go#L582
>
> On 23/05/17 05:59, James Beedy wrote:
> > Juju 2.1.2
> >
> > I'm getting this "JUJU_UNIT_NAME not in env" error on legacy-non-reactive
> > xenial charm using service_name() from hookenv.
> >
> > http://paste.ubuntu.com/24626263/
> >
> > Did we remove this?
> >
> > ~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

Re: Scale testing analysis

[John Meinel]

>
> ...
>


> We have most of the responsive nature of Juju is driven off the watchers.
> These watchers watch the mongo oplog for document changes. What happened
> was that there were so many mongo operations, the capped collection of the
> oplog was completely replaced between our polled watcher delays. The
> watchers then errored out in a new unexpected way.
>
> Effectively the watcher infrastructure needs an internal reset button that
> it can hit when this happens that invalidates all the watchers. This should
> cause all the workers to be torn down and restarted from a known good state.
>

Tim and I discussed this a bit. It probably wasn't the 'oplog' that
overflowed, but actually the 'txns.log' collection. Which is also a capped
collection at 10MB in size.
The issue is likely that the 'txnsLogWorker' automatically restarted on an
error, but the error actually meant that we're missing events, which means
that all the watchers/workers that are relying on the event stream should
be restarted. (we obviously can't know what events we're missing, cause
they're missing.)

So one argument is that txnsLogWorker should *not* be automatically
restarted. Instead failures of that worker should actually be critical
failures in the process and just cause the whole process to restart.
The alternative is that we introduce a mechanism to cause all workers to
restart (since they need to start fresh anyway), but restarting the agent
has a similar effect.

It is possible that we could whitelist some known errors that don't
indicate we need a full restart, but those really should be a whitelist.

John
=:->


>
> There was a model that got stuck being destroyed, this is tracked back to
> a worker that should be doing the destructions not noticing.
>
> All the CPU usage can be tracked back to the 139 models in the apiserver
> state pools each still running leadership and base watcher workers. The
> state pool should have removed all these instances, but it didn't notice
> they were gone.
>
> There are some other bugs around logging things as errors that really
> aren't errors that contributed to log noise, but the fundamental error here
> is not being robust in the face of too much change at once.
>
> This needs to be fixed for the 2.2 release candidate, so it may well push
> that out past the end of this week.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: django charm broken or am I just doing it wrong?

[John Meinel]

I believe Tim Penhey makes active use of the python-django charm, but it's
possible he uses it in a different fashion.

John
=:->

On May 21, 2017 14:25, "Erik Lönroth"  wrote:

> Hello!
>
> I'm trying out the django charm to deploy a django website I was going to
> try to create with juju.
>
> * I followed the instructions here: https://jujucharms.com/python-django/
>
> * My website repo is here: https://github.com/erik78se/dsite
>
> It has installed the website from github but there is an error:
>
> unit-dsite-1: 12:22:13 INFO unit.dsite/1.pgsql-relation-changed 0
> upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> unit-dsite-1: 12:22:14 DEBUG unit.dsite/1.juju-log pgsql:2: found django
> admin: /usr/bin/django-admin
> unit-dsite-1: 12:22:14 DEBUG unit.dsite/1.juju-log pgsql:2:
> PYTHONPATH=/srv/dsite/../ /usr/bin/django-admin syncdb --noinput
> --settings=dsite.settings
> unit-dsite-1: 12:22:14 ERROR unit.dsite/1.juju-log pgsql:2: status=1,
> output=Traceback (most recent call last):
>   File "/usr/bin/django-admin", line 5, in 
> management.execute_from_command_line()
>   File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
> line 399, in execute_from_command_line
> utility.execute()
>   File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
> line 392, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
> line 261, in fetch_command
> commands = get_commands()
>   File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
> line 107, in get_commands
> apps = settings.INSTALLED_APPS
>   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line
> 54, in __getattr__
> self._setup(name)
>   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line
> 49, in _setup
> self._wrapped = Settings(settings_module)
>   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line
> 132, in __init__
> % (self.SETTINGS_MODULE, e)
> ImportError: Could not import settings 'dsite.settings' (Is it on
> sys.path? Is there an import error in the settings file?): No module named
> dsite.settings
>
> unit-dsite-1: 12:22:14 ERROR juju.worker.uniter.operation hook
> "pgsql-relation-changed" failed: exit status 1
> unit-dsite-1: 12:22:14 INFO juju.worker.uniter awaiting error resolution
> for "relation-changed" hook
>
> As I'm not sure if I'm doing anything wrong or the charm is broken, I
> wonder what your suggestion is in how to resolve this issue or if I'm just
> doing it wrong.
>
> /Erik Lönroth
>
> --
> 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 build -s centos7 does nothing special?

[John Meinel]

I would guess the charm can define series specific build instructions, but
that layer-basic doesn't, itself, have different instructions for centos7.

John
=:->


On Sat, May 20, 2017 at 10:07 AM, fengxia  wrote:

> Hi Juju,
>
> I made a hello world charm based on charm tutorial, which includes
> layer-basic. I noticed that "charm build" can take a switch "-s series". I
> specified "-s centos7", and diff the result from default built which is
> "trusty". There is no material different between two builds.
>
> Is this expected?
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> 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/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

[John Meinel]

I would actually prefer if it shows up in 'juju status' but that we
suppress it from 'juju status-log' by default. (*possibly* we could show it
with a flag, but I'm not sure that it is worth tracking or not.)

John
=:->


On Fri, May 19, 2017 at 9:42 PM, Gregory Lutostanski <
gregory.lutostan...@canonical.com> wrote:

> What would happen if the update-status hook hangs here? I know it only is
> supposed to be for short-duration status messages (but charm bugs are known
> to happen).
>
> In addition, it will also block other hooks/actions from happening until
> completed and it will remain in a stuck state with the status reporting as
> "all good". Is there some middle ground rather than not exposing that the
> unit is working in this situation?
>
> Not to be a nay-sayer just want it more thoroughly looked at from a user's
> least surprise in not-great situations where the deployment is wedged.
>
> We would not know that from the status right? Only from the debug-log.
>
> On May 19, 2017 3:46 AM, "John Meinel" <j...@arbash-meinel.com> wrote:
>
>> All agents start up in DEBUG until they can talk to the controller and
>> read what the current logging config is set to. Otherwise you wouldn't be
>> able to debug startup issues.
>> That said, I think there was a request to cache the last-known value in
>> agent.conf which would let restarts be less noisy.
>>
>> John
>> =:->
>>
>>
>> On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <
>> samuel.cozan...@canonical.com> wrote:
>>
>>> +1
>>>
>>> Maybe one good thing would also be removing the default --debug flag
>>> from all juju machine startup scripts.
>>> It seems hard coded, and requires edition on most deployment.
>>>
>>> ++
>>> Sam
>>>
>>>
>>> On May 19, 2017 10:12, "Adam Collard" <adam.coll...@canonical.com>
>>> wrote:
>>>
>>> On Fri, 19 May 2017 at 03:14 Tim Penhey <tim.pen...@canonical.com>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Currently juju will update the status of any hook execution for any unit
>>>> to show that it is busy doing things. This was all well and good until
>>>> we do things based on time.
>>>>
>>>> Every five minutes (or so) each unit will have the update-status hook
>>>> executed to allow the unit to set or update the workload status based on
>>>> what is currently going on with that unit.
>>>>
>>>> Since all hook executions are stored, this means that the
>>>> show-status-log will show the unit jumping from executing update-status
>>>> to ready and back every five minutes.
>>>>
>>>> The proposal is to special case the update-status hook and show in
>>>> status (or the status-log) that the hook is being executed. debug-log
>>>> will continue to show the hook executing if you are looking.
>>>>
>>>> This will reduce noise in the status-log, simplify some of our code
>>>> around dealing with status-log, and reduce load on controllers looking
>>>> after hundreds or thousands of units.
>>>>
>>>
>>> +1
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

[John Meinel]

I would actually prefer if it shows up in 'juju status' but that we
suppress it from 'juju status-log' by default. (*possibly* we could show it
with a flag, but I'm not sure that it is worth tracking or not.)

John
=:->


On Fri, May 19, 2017 at 9:42 PM, Gregory Lutostanski <
gregory.lutostan...@canonical.com> wrote:

> What would happen if the update-status hook hangs here? I know it only is
> supposed to be for short-duration status messages (but charm bugs are known
> to happen).
>
> In addition, it will also block other hooks/actions from happening until
> completed and it will remain in a stuck state with the status reporting as
> "all good". Is there some middle ground rather than not exposing that the
> unit is working in this situation?
>
> Not to be a nay-sayer just want it more thoroughly looked at from a user's
> least surprise in not-great situations where the deployment is wedged.
>
> We would not know that from the status right? Only from the debug-log.
>
> On May 19, 2017 3:46 AM, "John Meinel" <j...@arbash-meinel.com> wrote:
>
>> All agents start up in DEBUG until they can talk to the controller and
>> read what the current logging config is set to. Otherwise you wouldn't be
>> able to debug startup issues.
>> That said, I think there was a request to cache the last-known value in
>> agent.conf which would let restarts be less noisy.
>>
>> John
>> =:->
>>
>>
>> On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <
>> samuel.cozan...@canonical.com> wrote:
>>
>>> +1
>>>
>>> Maybe one good thing would also be removing the default --debug flag
>>> from all juju machine startup scripts.
>>> It seems hard coded, and requires edition on most deployment.
>>>
>>> ++
>>> Sam
>>>
>>>
>>> On May 19, 2017 10:12, "Adam Collard" <adam.coll...@canonical.com>
>>> wrote:
>>>
>>> On Fri, 19 May 2017 at 03:14 Tim Penhey <tim.pen...@canonical.com>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Currently juju will update the status of any hook execution for any unit
>>>> to show that it is busy doing things. This was all well and good until
>>>> we do things based on time.
>>>>
>>>> Every five minutes (or so) each unit will have the update-status hook
>>>> executed to allow the unit to set or update the workload status based on
>>>> what is currently going on with that unit.
>>>>
>>>> Since all hook executions are stored, this means that the
>>>> show-status-log will show the unit jumping from executing update-status
>>>> to ready and back every five minutes.
>>>>
>>>> The proposal is to special case the update-status hook and show in
>>>> status (or the status-log) that the hook is being executed. debug-log
>>>> will continue to show the hook executing if you are looking.
>>>>
>>>> This will reduce noise in the status-log, simplify some of our code
>>>> around dealing with status-log, and reduce load on controllers looking
>>>> after hundreds or thousands of units.
>>>>
>>>
>>> +1
>>>
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: PROPOSAL: stop recording 'executing update-status hook'

[John Meinel]

All agents start up in DEBUG until they can talk to the controller and read
what the current logging config is set to. Otherwise you wouldn't be able
to debug startup issues.
That said, I think there was a request to cache the last-known value in
agent.conf which would let restarts be less noisy.

John
=:->


On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <
samuel.cozan...@canonical.com> wrote:

> +1
>
> Maybe one good thing would also be removing the default --debug flag from
> all juju machine startup scripts.
> It seems hard coded, and requires edition on most deployment.
>
> ++
> Sam
>
>
> On May 19, 2017 10:12, "Adam Collard"  wrote:
>
> On Fri, 19 May 2017 at 03:14 Tim Penhey  wrote:
>
>> Hi folks,
>>
>> Currently juju will update the status of any hook execution for any unit
>> to show that it is busy doing things. This was all well and good until
>> we do things based on time.
>>
>> Every five minutes (or so) each unit will have the update-status hook
>> executed to allow the unit to set or update the workload status based on
>> what is currently going on with that unit.
>>
>> Since all hook executions are stored, this means that the
>> show-status-log will show the unit jumping from executing update-status
>> to ready and back every five minutes.
>>
>> The proposal is to special case the update-status hook and show in
>> status (or the status-log) that the hook is being executed. debug-log
>> will continue to show the hook executing if you are looking.
>>
>> This will reduce noise in the status-log, simplify some of our code
>> around dealing with status-log, and reduce load on controllers looking
>> after hundreds or thousands of units.
>>
>
> +1
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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: PROPOSAL: stop recording 'executing update-status hook'

[John Meinel]

All agents start up in DEBUG until they can talk to the controller and read
what the current logging config is set to. Otherwise you wouldn't be able
to debug startup issues.
That said, I think there was a request to cache the last-known value in
agent.conf which would let restarts be less noisy.

John
=:->


On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <
samuel.cozan...@canonical.com> wrote:

> +1
>
> Maybe one good thing would also be removing the default --debug flag from
> all juju machine startup scripts.
> It seems hard coded, and requires edition on most deployment.
>
> ++
> Sam
>
>
> On May 19, 2017 10:12, "Adam Collard"  wrote:
>
> On Fri, 19 May 2017 at 03:14 Tim Penhey  wrote:
>
>> Hi folks,
>>
>> Currently juju will update the status of any hook execution for any unit
>> to show that it is busy doing things. This was all well and good until
>> we do things based on time.
>>
>> Every five minutes (or so) each unit will have the update-status hook
>> executed to allow the unit to set or update the workload status based on
>> what is currently going on with that unit.
>>
>> Since all hook executions are stored, this means that the
>> show-status-log will show the unit jumping from executing update-status
>> to ready and back every five minutes.
>>
>> The proposal is to special case the update-status hook and show in
>> status (or the status-log) that the hook is being executed. debug-log
>> will continue to show the hook executing if you are looking.
>>
>> This will reduce noise in the status-log, simplify some of our code
>> around dealing with status-log, and reduce load on controllers looking
>> after hundreds or thousands of units.
>>
>
> +1
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to build juju for centOS

[John Meinel]

Also, while agents can be built for CentOS we don't support Controllers on
CentOS at this point. So bootstrap I believe only supports Ubuntu.

John
=:->

On May 10, 2017 11:44, "Andrew Wilkins" 
wrote:

> On Wed, May 10, 2017 at 3:08 PM fengxia  wrote:
>
>> I have followed dev instruction and can build Juju binaries for Ubuntu.
>> The dev machine is also Ubuntu.
>>
>> $ go install -v github.com/juju/juju/…
>>
>> Using the same binaries will not however bootstrap with "--config
>> default-series=centos", nor "add-machine --series centos". Both failed at
>> "no tools founds".
>>
>> How to build an agent for centos?
>>
> For a start, you should use "centos7", not "centos". "juju add-machine
> --series=centos" *should* give you an immediate error indicating that
> that's not a valid series, and ideally inform you of the closest match(es);
> I'll file a bug to get that fixed.
>
> Do you need to build from source? If you're using a released version of
> Juju, then the agents are available on streams.canonical.com.
>
> For dev builds, we don't have a nice, supported solution. The supported
> solution is to create agent tarballs and generate simplestreams metadata. I
> wrote a plugin a while ago that you can use to build and upload agent
> tarballs to the controller directly, but you shouldn't use it in production
> systems:
>
> $ go get github.com/axw/juju-tools
> $ juju tools build 2.2-beta4.1-centos7-amd64
> building: juju-2.2-beta4.1-centos7-amd64.tgz
> $ juju tools upload -m controller juju-2.2-beta4.1-centos7-amd64.tgz
> uploading "juju-2.2-beta4.1-centos7-amd64.tgz"
> $ juju add-machine --series=centos7
>
> Cheers,
> Andrew
>
>> --
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju deploy same application twice, failed "application already exist"

[John Meinel]

You can already do that without the extra flag:
  juju deploy app [name]
You can name any app any name, we just default to the app name if it is not
supplied.

John
=:->

On Apr 21, 2017 18:12, "Patrizio Bassi"  wrote:

> Dear All
>
> this conversation led me to an interesting (for me at least!) speculation
> about nova-compute charm.
>
> At the moment the nova-compute charm has "virt-type" param supporting kvm,
> xen, uml, lxc, qemu, lxd.
> At the same time we have nova-compute-vmware charm which is an indipendent
> app.
>
> So, in case i may want to have an openstack with kvm and vmware mixed,
> juju allows it (just talking about juju, not considering openstack
> opportunity to have them really working).
>
> What if i want to have two nova-compute installations, one unit with kvm
> and one with lxd? As far i know we cannot.
> So it would be nice to add a feature such as:
>
> juju deploy  which defaults the deployed app to charm name
> juju deploy  -name 
>
> so all units will be in mycustomname/00XXX format, we kee the original
> charm reference (for upgrades for instance) and we can use multiple
> configurations under a different "umbrella"
>
> ie.
> nova-compute/0 (with default kvm)
> nova-compute/1 (with default kvm)
> nova-compute/2 (with default kvm)
> mynova-compute/0 (with lxd)
> mynova-compute/1 (with lxd)
> mynova-compute/2 (with lxd)
>
> regards,
> Patrizio
>
>
> 2017-04-21 9:55 GMT+02:00 Mark Shuttleworth :
>
>> On 20/04/17 13:36, fengxia wrote:
>> >
>> > I c. So I should have used add-unit command instead of "deploy". Is
>> > that right?
>> >
>>
>> Yup :)
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.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: How to add openstack cloud to juju 2.1.2-xenial

[John Meinel]

So while tools would need to be 'agent' it actually needs to be
'image-metadata-url' for what you are doing, and it looks like the docs are
already updated just waiting to be published into HTML:
 https://github.com/juju/docs/blob/master/src/en/howto-privatecloud.md

John
=:->


On Wed, Apr 12, 2017 at 9:56 AM, John Meinel <j...@arbash-meinel.com> wrote:

> It sounds like the docs are out of date. The key should be
> "agent-metadata-url" 'tools' was a much older name.
>
> John
> =:->
>
>
> On Wed, Apr 12, 2017 at 7:32 AM, Daniel Bidwell <drbidw...@gmail.com>
> wrote:
>
>> This gets me down to:
>>
>> juju bootstrap acauits acauits-controller --config tools-metadata-url=h
>> ttp://10.20.9.139:80/swift/v1
>>
>> where it gives me:
>>
>> WARNING unknown config field "tools-metadata-url"
>> Creating Juju controller "acauits-controller" on acauits/RegionOne
>> ERROR failed to bootstrap model: no image metadata found
>>
>> I am running juju 2.1.2-xenial-amd64
>>
>> On Tue, 2017-04-11 at 22:26 -0400, Heather Lanigan wrote:
>> > Here is a link on generating the image metadata: https://jujucharms.c
>> > om/docs/stable/howto-privatecloud
>> >
>> > -Heather
>> >
>> > > On Apr 11, 2017, at 10:20 PM, Daniel Bidwell <drbidw...@gmail.com>
>> > > wrote:
>> > >
>> > > I am making progress.  My openstack cloud has been added now.
>> > >
>> > > When I do "juju bootstrap acauits"  it comes back with:
>> > >
>> > > Creating Juju controller "acauits-RegionOne" on acauits/RegionOne
>> > > ERROR failed to bootstrap model: no image metadata found
>> > >
>> > > How do I get/generate image metadata?
>> > >
>> > > I tried "juju metadata generate-tools", but "juju metadata
>> > > generate-
>> > > image" complains that the controller isn't ready yet.
>> > >
>> > > On Tue, 2017-04-11 at 13:27 -0500, Matthew Helmke wrote:
>> > > > I have an OpenStack deployment. In my novarc file, I have this
>> > > > line:
>> > > > export OS_AUTH_URL=http://FAKEURLFORTHISEMAIL.com:5000/v2.0
>> > > >
>> > > > Look for a similar line in your novarc.
>> > > >
>> > > > On Tue, Apr 11, 2017 at 1:22 PM, Daniel Bidwell <drbidwell@gmail.
>> > > > com>
>> > > > wrote:
>> > > > > juju add-cloud asks:
>> > > > >
>> > > > > Enter the API endpoint url for the cloud:
>> > > > > https://openstack.example.com:35574/v3.0/
>> > > > >
>> > > > > What openstack service is it asking for?  Is it asking for the
>> > > > > dashboard, nova, or what?
>> > > > >
>> > > > > If I have only one region now, do I give it the same url for
>> > > > > both
>> > > > > the
>> > > > > cloud and region?
>> > > > >
>> > > > > My cloud is up and I can create vm's with the dashboard.  I
>> > > > > just
>> > > > > want
>> > > > > to tie it to juju now.
>> > > > >
>> > > > > Thanks.
>> > > > >
>> > > > > On Tue, 2017-04-11 at 06:28 -0500, Matthew Helmke wrote:
>> > > > > > The Juju documentation includes a page dedicated to your
>> > > > > > task.
>> > > > > Here
>> > > > > > is the link: https://jujucharms.com/docs/stable/help-openstac
>> > > > > > k.
>> > > > > >
>> > > > > > The tl;dr for your specific question is that if you want to
>> > > > > > use
>> > > > > the
>> > > > > > authentication from your existing OpenStack cloud, then
>> > > > > > during
>> > > > > `juju
>> > > > > > add-cloud` you choose the `userpass` auth type and enter the
>> > > > > > URL
>> > > > > for
>> > > > > > the API. This is typically found in your existing novarc
>> > > > > > file.
>> > > > > Follow
>> > > > > > that by running `juju autoload-credentials` and you will be
>> > > > > > all
>> > > > > set.
>> > > > > >
>

Re: How to add openstack cloud to juju 2.1.2-xenial

[John Meinel]

It sounds like the docs are out of date. The key should be
"agent-metadata-url" 'tools' was a much older name.

John
=:->


On Wed, Apr 12, 2017 at 7:32 AM, Daniel Bidwell  wrote:

> This gets me down to:
>
> juju bootstrap acauits acauits-controller --config tools-metadata-url=h
> ttp://10.20.9.139:80/swift/v1
>
> where it gives me:
>
> WARNING unknown config field "tools-metadata-url"
> Creating Juju controller "acauits-controller" on acauits/RegionOne
> ERROR failed to bootstrap model: no image metadata found
>
> I am running juju 2.1.2-xenial-amd64
>
> On Tue, 2017-04-11 at 22:26 -0400, Heather Lanigan wrote:
> > Here is a link on generating the image metadata: https://jujucharms.c
> > om/docs/stable/howto-privatecloud
> >
> > -Heather
> >
> > > On Apr 11, 2017, at 10:20 PM, Daniel Bidwell 
> > > wrote:
> > >
> > > I am making progress.  My openstack cloud has been added now.
> > >
> > > When I do "juju bootstrap acauits"  it comes back with:
> > >
> > > Creating Juju controller "acauits-RegionOne" on acauits/RegionOne
> > > ERROR failed to bootstrap model: no image metadata found
> > >
> > > How do I get/generate image metadata?
> > >
> > > I tried "juju metadata generate-tools", but "juju metadata
> > > generate-
> > > image" complains that the controller isn't ready yet.
> > >
> > > On Tue, 2017-04-11 at 13:27 -0500, Matthew Helmke wrote:
> > > > I have an OpenStack deployment. In my novarc file, I have this
> > > > line:
> > > > export OS_AUTH_URL=http://FAKEURLFORTHISEMAIL.com:5000/v2.0
> > > >
> > > > Look for a similar line in your novarc.
> > > >
> > > > On Tue, Apr 11, 2017 at 1:22 PM, Daniel Bidwell  > > > com>
> > > > wrote:
> > > > > juju add-cloud asks:
> > > > >
> > > > > Enter the API endpoint url for the cloud:
> > > > > https://openstack.example.com:35574/v3.0/
> > > > >
> > > > > What openstack service is it asking for?  Is it asking for the
> > > > > dashboard, nova, or what?
> > > > >
> > > > > If I have only one region now, do I give it the same url for
> > > > > both
> > > > > the
> > > > > cloud and region?
> > > > >
> > > > > My cloud is up and I can create vm's with the dashboard.  I
> > > > > just
> > > > > want
> > > > > to tie it to juju now.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > On Tue, 2017-04-11 at 06:28 -0500, Matthew Helmke wrote:
> > > > > > The Juju documentation includes a page dedicated to your
> > > > > > task.
> > > > > Here
> > > > > > is the link: https://jujucharms.com/docs/stable/help-openstac
> > > > > > k.
> > > > > >
> > > > > > The tl;dr for your specific question is that if you want to
> > > > > > use
> > > > > the
> > > > > > authentication from your existing OpenStack cloud, then
> > > > > > during
> > > > > `juju
> > > > > > add-cloud` you choose the `userpass` auth type and enter the
> > > > > > URL
> > > > > for
> > > > > > the API. This is typically found in your existing novarc
> > > > > > file.
> > > > > Follow
> > > > > > that by running `juju autoload-credentials` and you will be
> > > > > > all
> > > > > set.
> > > > > >
> > > > > > On Mon, Apr 10, 2017 at 4:11 PM, Daniel Bidwell  > > > > > ail.
> > > > > com>
> > > > > > wrote:
> > > > > > > I need to add openstack as a cloud to juju 2.1.2-xenial.  I
> > > > > don't
> > > > > > > seem
> > > > > > > to find the right howto.  What authentication method do I
> > > > > > > use?
> > > > > And
> > > > > > > where do I get the authentication string?  User name and
> > > > > password
> > > > > > > for
> > > > > > > dashboard user?
> > > > > > > --
> > > > > > > Daniel Bidwell 
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Juju mailing list
> > > > > > > Juju@lists.ubuntu.com
> > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com
> > > > > > > /mai
> > > > > lman
> > > > > > > /listinfo/juju
> > > > > > >
> > > > > > --
> > > > > > Matthew Helmke
> > > > > > Documentation
> > > > > > Canonical
> > > > > --
> > > > > Daniel Bidwell 
> > > > >
> > > > >
> > > > --
> > > > Matthew Helmke
> > > > Documentation
> > > > Canonical
> > > --
> > > Daniel Bidwell 
> > >
> > >
> > > --
> > > 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

Fwd: Quick analysis of 'stale' transactions

[John Meinel]

We're trying to look at reasons why we end up with some stale transaction
ids in the txn-queue. I did find a machine with 18 entries in its txn
queue, all of which are '6: applied'.

I ended up discovering that SetLinkLayerDevices and SetDeviceAddresses are
both causes of a fair number of assert-only transactions (especially
against the model object).
https://bugs.launchpad.net/juju/+bug/1677619

I also found out that it isn't just assert-only transactions. Transactions
that have an "update" field, but are ultimately updating the content to the
content that is already there *also* end up sticking around.
SetAgentVersion is guilty of this.

In the production database, I found a machine with 18 transactions in the
queue, but worse I found 4000 transactions in the model queue.

A couple of interesting aggregation queries:
   db.models.aggregate([
{$project: {_id: 1, "size": {$size: "$txn-queue"}}},
{$sort: {"size": -1}}])

this gives you a descending list of object ids sorted by the number of
entries in the ten-queue.

  db.models.aggregate([{$match: {"_id": SPECIFICID}},
 {"$project": {"_id": 0, "q": "$txn-queue"}},
 {$unwind: "$q"}, {$sample: {size: 20}}])

This lets you get a random subset of 20 ids out of one of those 4000 long
queue so you can go around poking at what those transactions are doing
without getting just the beginning or just the end.
Ideally it would actually do something to transform the transaction + nonce
ids into just transaction ObjectIds so that you could easily do deeper
queries, but its a start. (I can print those and transform them in an
editor.)

Another interesting query, aggregating 36M records takes a while, but
sampling them can give you a reasonable subset and feel like you still are
getting answers:
juju:PRIMARY> db.txns.aggregate([{$sample: {size: 10}},
  {$match: {"s": 6}},
  {$project: {"_id": 0, "c": "$o.c"}},
  {"$unwind": "$c"},
  {$group: {"_id": "$c", "count": {$sum: 1}}}, {$sort: {"count": -1}}])
{ "_id" : "leases", "count" : 118946 }
{ "_id" : "statuses", "count" : 32947 }
{ "_id" : "linklayerdevices", "count" : 2294 }
{ "_id" : "units", "count" : 1435 }
{ "_id" : "machines", "count" : 1409 }
{ "_id" : "ip.addresses", "count" : 1073 }
{ "_id" : "actions", "count" : 1054 }
{ "_id" : "models", "count" : 1053 }
{ "_id" : "settings", "count" : 1013 }
{ "_id" : "actionnotifications", "count" : 960 }
{ "_id" : "refcounts", "count" : 787 }
...

So out of 100,000 records, there are 118 references to leases (if a
collection is mentioned multiple times in a transaction it gets counted
twice by this aggregation). But leases and statuses are certainly the #1
cause of transactions, LinkLayerDevices is next, which is one that I have a
patch up for (its a lot of records that aren't actually changing anything).
Status/Leases are at least renewing timestamps.

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

Re: Network Space Binding Changes After Deployment or Upgrades

[John Meinel]

On Mon, Mar 27, 2017 at 3:31 PM, Dmitrii Shcherbakov <
dmitrii.shcherba...@canonical.com> wrote:

> Hi everybody,
>
> As far as I can see, there is no way to change a network space binding or
> add a new one after a charm has been deployed.
>

The one caveat here is that in 2.1.2+ if you used a 'default' binding (juju
deploy --bind foo) then all new endpoints for a charm will also be bound
into whatever the default was for that application.


That is currently correct. We have been discussing it, and how we want to
concretely model the evolution of spaces over time. One of the particular
points of concern is whether we would ever want to allow multiple units of
the same application to be configured differently.
For example:
  $ juju deploy app --constraints mem=4G
  $ juju set-constraints app mem=2G
  $ juju add-unit app

You'll now have 2 units, where they have different expected memory.
However, we feel that supporting that for bindings would be a net negative,
because it complicates the *user's* mental model of where everything
exists. An other applications that relate to the app need more complex
thoughts when it comes to "am I able to talk to all of the units?".

Complications like that are what led to us not implementing rebinding from
the beginning.

Our current plan is to have some sort of "rebind an endpoint" command
(name-to-be-determined juju set-binding, juju rebind, etc). This would
include a sanity check that all of the units that are currently deployed
have access to the space that you are requesting. eg:
 juju deploy app --bind foo --constraints spaces=baz
 juju rebind app blah=baz
Would be allowed, because all units of "app" must be in both "foo" and
"baz" spaces.

We should also support "--bind" as a parameter to "juju upgrade-charm",
since the set of endpoints that we know about can be changing, and you
should be able to specify values for the new entries, rather than inherit
the default and then need to be updated.

The caveat is that if all units don't have access to the new space, then we
should fail. Which would still let you "remove units not in the space I
want" (which may be all of them), "rebind", "add-units back to however many
I want".

The other complexity that I know is lurking around the corner is that as
soon as we have the ability to rebind, people are going to want to do:
  juju add-machine --constraints spaces=foo,bar
  juju deploy app --bind foo --to lxd:0
  juju rebind app bar

Which will require us to change the network bindings of a running
container. Which is ultimately something I think we want, but will also
likely not be in the first implementation of rebind. (For anything like an
SDN we should be able to rebind to whatever spaces that machine can have
access to, rather than what spaces it is currently connected to.)


> What I encountered is a situation where you either want to add a new
> endpoint (and bind it to a space) after a charm upgrade or modify an
> existing one. With the current approach this is not possible without a full
> redeployment of an application (remove-application -> deploy & bind ->
> add-unit).
>
> However, for deployments with large uptime requirements this is not a
> feasible solution.
>
> My view of the problem:
>
>- Juju doesn't know how a charm code have used binding information
>during a deployment;
>- Juju can expose an event which should be handled in the charm code;
>- There is a distinction between "binding-changed" and "upgrade"
>events as the latter may include binding changes but needs a mechanism to
>learn which bindings have changed.
>
> --
> Only the deployment-related code has handling of bindings:
> https://github.com/juju/juju/blob/master/cmd/juju/
> application/deploy.go#L615
> https://github.com/juju/juju/blob/staging/cmd/juju/
> application/bundle.go#L382
>
> 
>
> Nothing about bindings here:
> https://github.com/juju/juju/blob/master/cmd/juju/
> application/upgradecharm.go
> ---
>
> I realize that this is a complex feature and will require code on the
> charm side but I think it is important as it makes deployments less rigid
> and more update-friendly.
>
> Has it been discussed before?
>

It has certainly been discussed, we're just not there yet.

John
=:->


>
>

> Any feedback is appreciated - thanks in advance.
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
>
> --
> 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!

[John Meinel]

Did you "juju expose mediawiki" ?

That should have Juju update the security group on the mediawiki machines
to expose port 80.

John
=:->

On Sun, Mar 26, 2017 at 10:58 PM, Giuseppe Attardi  wrote:

> I solved the problem by using Chrome instead of Safari.
>
> I was able then to deploy a mediawiki bundle on AWS.
> It deployed two machines and the mediawiki unit was given these addresses:
>
> Public addresses:
> • 52.55.114.200:80
> IP addresses:
> • 172.31.19.141:80
>
> But none of them is reachable.
>
> Normally when I deploy charms to AWS, I noticed that they use a security
> group that only allows ssh connections.
>
> $ ssh 52.55.114.200
> Permission denied (publickey).
>
> $ telnet 52.55.114.200 80
> Trying 52.55.114.200…
>
> I normally add a security group for accessing port 80, and then I can use
> the machine.
> I would need access to the AWS dashboard to do this though.
> How can I do it?
>
> — Attardi
>
>
>
> On 26 mar 2017, at 00:30, Jeff Pihach  wrote:
>
> Hi, sorry about that. When visiting the login page directly it will
> attempt to open another tab to allow you to log in to your Ubuntu account.
> Check that you've allowed jujucharms.com to open new tabs.
>
>
> On Sat, Mar 25, 2017 at 6:15 AM, Giuseppe Attardi  garr.it> wrote:
> Nice.
> But
> https://jujucharms.com/login/
> runs into a loop of:
>
> Requesting code… Rendering the GUI… Requesting code
>
> — 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: Can't juju deploy p2.xlarge in aws/us-east-1

[John Meinel]

Preferring a VPC if there is a single one that exists, even if it isn't
flagged as "default" for a region would probably be reasonable, and
probably not a lot of effort. If there are multiple, I wonder if we could
refuse to bootstrap/add-model unless one is specified.

John
=:->


On Tue, Mar 21, 2017 at 3:04 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Mon, Mar 20, 2017 at 10:17 PM Junien Fridrick <
> junien.fridr...@canonical.com> wrote:
>
>> And once/if you have no Classic instance running in a region, you should
>> file a ticket to AWS Support asking for a default VPC creation. Once
>> it's done, you don't need to supply the VPC ID anymore.
>>
>> Could juju maybe be instructed to use a VPC if and only if a single VPC
>> exist in a region, without specifying its ID ? For example, --config
>> "force-vpc=true" or something.
>>
>
> Yes we could do that. I'd like to go a bit further; what I would like to
> have happen is:
>
> 1. juju will use the VPC specified in config, if any
> 2. else, Juju will look for a VPC called (say) "juju-default-vpc"
> 3. else, Juju will create a VPC with the same name, if it can*, and use
> that
> 4. else, Juju will use the default VPC, if available
> 5. else, bootstrap/add-model will fail
>
> The outcome being that Juju will then *always* use VPC, and the user
> shouldn't need to do a thing. This would also allow the provider to be
> cleaned up (assuming there's a migration path for existing deployments),
> and new features to be implemented more easily (e.g. support for EFS).
>
> Everyone on the team is currently fully booked, so I can't give you an
> estimate of when that'll come to fruition yet. We could do everything
> except have Juju fail pretty easily I would think.
>
> * "if it can", because there are pretty severe limits on the number of
> VPCs you can create: 5 per region.
>
> Cheers,
> Andrew
>
>
>> On Thu, Mar 16, 2017 at 08:04:22AM -0400, Tim Van Steenburgh wrote:
>> > A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to
>> `juju
>> > bootstrap`, I can now deploy p2 instance types. Thanks Andrew!
>> >
>> > On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet <
>> > samuel.cozan...@canonical.com> wrote:
>> >
>> > > Aaah whaow. I have a default VPC myself, so that may explain the
>> problem
>> > > Tim is having. Early adopters problem!!
>> > >
>> > >
>> > > --
>> > > Samuel Cozannet
>> > > Cloud, Big Data and IoT Strategy Team
>> > > Business Development - Cloud and ISV Ecosystem
>> > > Changing the Future of Cloud
>> > > Ubuntu   / Canonical UK LTD 
>> /
>> > > Juju 
>> > > samuel.cozan...@canonical.com
>> > > mob: +33 616 702 389
>> > > skype: samnco
>> > > Twitter: @SaMnCo_23
>> > > [image: View Samuel Cozannet's profile on LinkedIn]
>> > > 
>> > >
>> > > On Thu, Mar 16, 2017 at 9:17 AM, Andrew Wilkins <
>> > > andrew.wilk...@canonical.com> wrote:
>> > >
>> > >> On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
>> > >> samuel.cozan...@canonical.com> wrote:
>> > >>
>> > >>> I am using the default settings, no change as far as I know to what
>> Juju
>> > >>> would do by default.
>> > >>>
>> > >>
>> > >> What Juju will do depends on what is available in your EC2 account.
>> Not
>> > >> all EC2 accounts were born alike.
>> > >>
>> > >> If your account has a default VPC, that will be used by Juju. In that
>> > >> case, you'll have p2 instance types available. I expect this to be
>> the case
>> > >> for most people - all accounts created since 2013-12-04 will have a
>> default
>> > >> VPC.
>> > >>
>> > >> If you've got an older account, then you may or may not have a
>> default
>> > >> VPC. If you do not, then Juju will fall back to EC2 Classic. In that
>> case,
>> > >> no p2 instance types.
>> > >>
>> > >> Cheers,
>> > >> Andrew
>> > >>
>> > >>
>> > >>> --
>> > >>> Samuel Cozannet
>> > >>> Cloud, Big Data and IoT Strategy Team
>> > >>> Business Development - Cloud and ISV Ecosystem
>> > >>> Changing the Future of Cloud
>> > >>> Ubuntu   / Canonical UK LTD <
>> http://canonical.com> /
>> > >>> Juju 
>> > >>> samuel.cozan...@canonical.com
>> > >>> mob: +33 616 702 389
>> > >>> skype: samnco
>> > >>> Twitter: @SaMnCo_23
>> > >>> [image: View Samuel Cozannet's profile on LinkedIn]
>> > >>> 
>> > >>>
>> > >>> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
>> > >>> andrew.wilk...@canonical.com> wrote:
>> > >>>
>> > >>> On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh <
>> > >>> tim.van.steenbu...@canonical.com> wrote:
>> > >>>
>> > >>> 2.1.1 juju client and controller, controller bootstrapped in
>> > >>> aws/us-east-1:
>> > >>>
>> > >>> juju deploy ./kubernetes-worker --constraints
>> "instance-type=p2.xlarge" kubernetes-worker-gpu
>> > >>> Deploying charm "local:xenial/kubernetes-worker-1".
>> > >>> ERROR cannot add application "kubernetes-worker-gpu": 

Re: Can't juju deploy p2.xlarge in aws/us-east-1

[John Meinel]

Preferring a VPC if there is a single one that exists, even if it isn't
flagged as "default" for a region would probably be reasonable, and
probably not a lot of effort. If there are multiple, I wonder if we could
refuse to bootstrap/add-model unless one is specified.

John
=:->


On Tue, Mar 21, 2017 at 3:04 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Mon, Mar 20, 2017 at 10:17 PM Junien Fridrick <
> junien.fridr...@canonical.com> wrote:
>
>> And once/if you have no Classic instance running in a region, you should
>> file a ticket to AWS Support asking for a default VPC creation. Once
>> it's done, you don't need to supply the VPC ID anymore.
>>
>> Could juju maybe be instructed to use a VPC if and only if a single VPC
>> exist in a region, without specifying its ID ? For example, --config
>> "force-vpc=true" or something.
>>
>
> Yes we could do that. I'd like to go a bit further; what I would like to
> have happen is:
>
> 1. juju will use the VPC specified in config, if any
> 2. else, Juju will look for a VPC called (say) "juju-default-vpc"
> 3. else, Juju will create a VPC with the same name, if it can*, and use
> that
> 4. else, Juju will use the default VPC, if available
> 5. else, bootstrap/add-model will fail
>
> The outcome being that Juju will then *always* use VPC, and the user
> shouldn't need to do a thing. This would also allow the provider to be
> cleaned up (assuming there's a migration path for existing deployments),
> and new features to be implemented more easily (e.g. support for EFS).
>
> Everyone on the team is currently fully booked, so I can't give you an
> estimate of when that'll come to fruition yet. We could do everything
> except have Juju fail pretty easily I would think.
>
> * "if it can", because there are pretty severe limits on the number of
> VPCs you can create: 5 per region.
>
> Cheers,
> Andrew
>
>
>> On Thu, Mar 16, 2017 at 08:04:22AM -0400, Tim Van Steenburgh wrote:
>> > A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to
>> `juju
>> > bootstrap`, I can now deploy p2 instance types. Thanks Andrew!
>> >
>> > On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet <
>> > samuel.cozan...@canonical.com> wrote:
>> >
>> > > Aaah whaow. I have a default VPC myself, so that may explain the
>> problem
>> > > Tim is having. Early adopters problem!!
>> > >
>> > >
>> > > --
>> > > Samuel Cozannet
>> > > Cloud, Big Data and IoT Strategy Team
>> > > Business Development - Cloud and ISV Ecosystem
>> > > Changing the Future of Cloud
>> > > Ubuntu   / Canonical UK LTD 
>> /
>> > > Juju 
>> > > samuel.cozan...@canonical.com
>> > > mob: +33 616 702 389
>> > > skype: samnco
>> > > Twitter: @SaMnCo_23
>> > > [image: View Samuel Cozannet's profile on LinkedIn]
>> > > 
>> > >
>> > > On Thu, Mar 16, 2017 at 9:17 AM, Andrew Wilkins <
>> > > andrew.wilk...@canonical.com> wrote:
>> > >
>> > >> On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
>> > >> samuel.cozan...@canonical.com> wrote:
>> > >>
>> > >>> I am using the default settings, no change as far as I know to what
>> Juju
>> > >>> would do by default.
>> > >>>
>> > >>
>> > >> What Juju will do depends on what is available in your EC2 account.
>> Not
>> > >> all EC2 accounts were born alike.
>> > >>
>> > >> If your account has a default VPC, that will be used by Juju. In that
>> > >> case, you'll have p2 instance types available. I expect this to be
>> the case
>> > >> for most people - all accounts created since 2013-12-04 will have a
>> default
>> > >> VPC.
>> > >>
>> > >> If you've got an older account, then you may or may not have a
>> default
>> > >> VPC. If you do not, then Juju will fall back to EC2 Classic. In that
>> case,
>> > >> no p2 instance types.
>> > >>
>> > >> Cheers,
>> > >> Andrew
>> > >>
>> > >>
>> > >>> --
>> > >>> Samuel Cozannet
>> > >>> Cloud, Big Data and IoT Strategy Team
>> > >>> Business Development - Cloud and ISV Ecosystem
>> > >>> Changing the Future of Cloud
>> > >>> Ubuntu   / Canonical UK LTD <
>> http://canonical.com> /
>> > >>> Juju 
>> > >>> samuel.cozan...@canonical.com
>> > >>> mob: +33 616 702 389
>> > >>> skype: samnco
>> > >>> Twitter: @SaMnCo_23
>> > >>> [image: View Samuel Cozannet's profile on LinkedIn]
>> > >>> 
>> > >>>
>> > >>> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
>> > >>> andrew.wilk...@canonical.com> wrote:
>> > >>>
>> > >>> On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh <
>> > >>> tim.van.steenbu...@canonical.com> wrote:
>> > >>>
>> > >>> 2.1.1 juju client and controller, controller bootstrapped in
>> > >>> aws/us-east-1:
>> > >>>
>> > >>> juju deploy ./kubernetes-worker --constraints
>> "instance-type=p2.xlarge" kubernetes-worker-gpu
>> > >>> Deploying charm "local:xenial/kubernetes-worker-1".
>> > >>> ERROR cannot add application "kubernetes-worker-gpu": 

Re: Constraints for Additional Units

[John Meinel]

Correct. Putting the constraints on the machines is equivalent to doing:
  juju add-machine --constraints mem=4gb
  juju deploy mysql --to $MACHINE

Rather than doing:
 juju deploy mysql --constraints mem=4gb

Constraints on an Application will affect all new units of an application,
but constraints on a single machine only effect provisioning that machine.

John
=:->


On Fri, Mar 17, 2017 at 7:24 AM, James Beedy  wrote:

> I think I see *my* issue here. I have placed the constraints on the
> machines (to which the charms are mapped) in my bundle, and not on the
> actual applications themselves. I guess I shouldn't expect the constraints
> to be associated with the charms in that case. Does this sound correct?
>
> On Thu, Mar 16, 2017 at 8:13 PM, James Beedy  wrote:
>
>> With the following spaces and subnets http://paste.ubuntu.com/24192913/
>>
>> I deploy my haproxy units to the igw subnets, and keep the rest of the
>> components of my applications behind the nat gateway on the nat subnets. I
>> tag the appropriate spaces on the machines in my bundle, but following a
>> bundle deploy, the units don't scale out with the correct constraints (e.g.
>> end up in the wrong space) if I go to add any additional units. As can be
>> seen here (http://paste.ubuntu.com/24192930/) the additional unit of
>> 'feed-web' obviously does not end up on one of my nat gateway subnets hence
>> it has a public ip.
>>
>> On Thu, Mar 16, 2017 at 8:01 PM, Tim Penhey 
>> wrote:
>>
>>> On 17/03/17 14:23, James Beedy wrote:
>>>
 Currently, if I scale the units of my application, the new units do not
 have the same constraints as the previously deployed units.

>>>
>>> Well, I certainly think they should be carrying over the constraints as
>>> the constraints are set on the application, not the unit.
>>>
>>> If this isn't working, I believe it is a bug.
>>>
>>> Can you give an example of what is not working?
>>>
>>> Cheers,
>>> Tim
>>>
>>>
>>> Moreover, it
 doesn't seem there is anyway to specify constraints for additional
 units. I'm thinking the 'add-unit' command needs to be able to accept
 constraints, or constraints need to be carried forward for additional
 units of the same application.  This is a request for the 'add-unit'
 command to accept constraints, or for constraints to grow some sort of
 associativity/sensitivity to applications. Also, this is a huge blocker
 for me right now. Any insight as to how we might solve this issue would
 be greatly appreciated.

 Thanks

 https://bugs.launchpad.net/juju/+bug/1673639



>>
>
> --
> 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: maas how to add-cloud to a zone

[John Meinel]

Zones are generally meant to be used to provide fault domains such that you
should be spreading your applications across zones. I can see how zones
could be used differently but it does feel like it would be going against
the grain.

John
=:->

On Mar 15, 2017 13:01, "Menno Smits"  wrote:

Hi Christian,

Someone who knows more about Juju's MAAS support may disagree with me but I
just had a quick look through the code I don't see any way to specify the
MAAS zone as part of a MAAS cloud definition.

- Menno

On 14 March 2017 at 13:26,  wrote:

> Hi
>
> Is it possible to add-cloud a maas cloud to a specific zone?
> like
>
> juju bootstrap --to zone=foozone
> juju enable-ha --to zone=foozone
> juju deploy --to zone=foozone
>
> I'm using 2.1.1 devel version.
>
> BR
>
> Christian
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>


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

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

We should as soon as I have it landed in the 2.1 branch and CI starts to
run we can use it's deb.

John
=:->

On Mar 9, 2017 09:48, "Patrizio Bassi" <patrizio.ba...@gmail.com> wrote:

> Fantastic job John!
>
> do you have a .deb i can already test on my environment?
>
> Patrizio
>
> 2017-03-09 16:24 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>
>> I do have a fix up for review:
>>   https://github.com/juju/juju/pull/7081
>> And I have tested it live against a local maas, though my maas doesn't
>> have multiple interfaces, I can see the bindings get requested
>> appropriately and not fail with the "empty binding name" failure.
>>
>> I'm pushing to get a 2.1.2 out to include this fix once it lands for
>> review and CI, etc. If it all goes well then 2.1.2 will be out later this
>> week.
>>
>> John
>> =:->
>>
>>
>> On Thu, Mar 9, 2017 at 8:40 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>>
>>> @John
>>> great. i'm using juju 2.1.1 and maas 2.1.3.
>>>
>>> Regarding the workaround...it's not a matter of a particular charm, it's
>>> a matter of all (i will deploy openstack-telemetry charm with some
>>> modifications), because when we allocate a machine with juju i would like
>>> it to pick a public (dns) name, the one on the --bind , no matter
>>> which extra binding is declared in the charm, if any.
>>>
>>> Plus: i would even add another option, such as bind to a particular net
>>> interface as a machine may have 2 subnet belonging to the same space
>>> address (ok, we may model this in maas by designing 1-to-1 subnet-to-space).
>>>
>>> Again: some charms may use the juju network spaces, but it would be
>>> great juju to be charm agnostic when asking resources to maas (with bind
>>> constraint of course).
>>>
>>> I'm ready to test if you have a fix.
>>>
>>> Patrizio
>>>
>>>
>>> 2017-03-09 15:05 GMT+01:00 Sandor Zeestraten <zando...@gmail.com>:
>>>
>>>> Where do we find which bindings a charm has so they can be specified
>>>> directly?
>>>> According to the docs on the metadata (https://jujucharms.com/docs/s
>>>> table/authors-charm-metadata) there's a section called extra-bindings
>>>> but that only seems to be used in some charms.
>>>>
>>>> --
>>>> Sandor Zeestraten
>>>>
>>>> On Thu, Mar 9, 2017 at 2:34 PM, John Meinel <j...@arbash-meinel.com>
>>>> wrote:
>>>>
>>>>> In the meantime, you can work around it by specifying the bindings
>>>>> directly: so in the case of mysql that would be:
>>>>>  juju deploy mysql --bind "db=db-space monitors=db-space ha=db-space
>>>>> ..."
>>>>>
>>>>> John
>>>>> =:->
>>>>>
>>>>>
>>>>> On Thu, Mar 9, 2017 at 7:25 AM, John Meinel <j...@arbash-meinel.com>
>>>>> wrote:
>>>>>
>>>>>> "juju deploy mysql --bind db-space" is exactly the syntax that should
>>>>>> be working, and I'm seeing it failing now. I will work to fix that and 
>>>>>> make
>>>>>> sure we don't regress here. We certainly should have caught that before
>>>>>> release.
>>>>>>
>>>>>> John
>>>>>> =:->
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 9, 2017 at 1:47 AM, Patrizio Bassi <
>>>>>> patrizio.ba...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Ante,
>>>>>>>
>>>>>>> no that is not working, but i think it's by design.
>>>>>>> That constraint means: pick up a machine that has a leg in the
>>>>>>> db-space leg.
>>>>>>>
>>>>>>> So my machine with 2 eth ports in two different spaces satisfy that 
>>>>>>> constraint,
>>>>>>> it is picked, but the IP is wrong.
>>>>>>>
>>>>>>> Another option i tried is:
>>>>>>>
>>>>>>> juju deploy mysql --constraints spaces=db-space,^space_i_dont_want
>>>>>>>
>>>>>>> in that case the machine is filtered out, because, as i said before,
>>>>>>> it means "a machine that is in db-space sp

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

I do have a fix up for review:
  https://github.com/juju/juju/pull/7081
And I have tested it live against a local maas, though my maas doesn't have
multiple interfaces, I can see the bindings get requested appropriately and
not fail with the "empty binding name" failure.

I'm pushing to get a 2.1.2 out to include this fix once it lands for review
and CI, etc. If it all goes well then 2.1.2 will be out later this week.

John
=:->


On Thu, Mar 9, 2017 at 8:40 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:

> @John
> great. i'm using juju 2.1.1 and maas 2.1.3.
>
> Regarding the workaround...it's not a matter of a particular charm, it's a
> matter of all (i will deploy openstack-telemetry charm with some
> modifications), because when we allocate a machine with juju i would like
> it to pick a public (dns) name, the one on the --bind , no matter
> which extra binding is declared in the charm, if any.
>
> Plus: i would even add another option, such as bind to a particular net
> interface as a machine may have 2 subnet belonging to the same space
> address (ok, we may model this in maas by designing 1-to-1 subnet-to-space).
>
> Again: some charms may use the juju network spaces, but it would be great
> juju to be charm agnostic when asking resources to maas (with bind
> constraint of course).
>
> I'm ready to test if you have a fix.
>
> Patrizio
>
>
> 2017-03-09 15:05 GMT+01:00 Sandor Zeestraten <zando...@gmail.com>:
>
>> Where do we find which bindings a charm has so they can be specified
>> directly?
>> According to the docs on the metadata (https://jujucharms.com/docs/s
>> table/authors-charm-metadata) there's a section called extra-bindings
>> but that only seems to be used in some charms.
>>
>> --
>> Sandor Zeestraten
>>
>> On Thu, Mar 9, 2017 at 2:34 PM, John Meinel <j...@arbash-meinel.com>
>> wrote:
>>
>>> In the meantime, you can work around it by specifying the bindings
>>> directly: so in the case of mysql that would be:
>>>  juju deploy mysql --bind "db=db-space monitors=db-space ha=db-space ..."
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Thu, Mar 9, 2017 at 7:25 AM, John Meinel <j...@arbash-meinel.com>
>>> wrote:
>>>
>>>> "juju deploy mysql --bind db-space" is exactly the syntax that should
>>>> be working, and I'm seeing it failing now. I will work to fix that and make
>>>> sure we don't regress here. We certainly should have caught that before
>>>> release.
>>>>
>>>> John
>>>> =:->
>>>>
>>>>
>>>> On Thu, Mar 9, 2017 at 1:47 AM, Patrizio Bassi <
>>>> patrizio.ba...@gmail.com> wrote:
>>>>
>>>>> Hi Ante,
>>>>>
>>>>> no that is not working, but i think it's by design.
>>>>> That constraint means: pick up a machine that has a leg in the
>>>>> db-space leg.
>>>>>
>>>>> So my machine with 2 eth ports in two different spaces satisfy that 
>>>>> constraint,
>>>>> it is picked, but the IP is wrong.
>>>>>
>>>>> Another option i tried is:
>>>>>
>>>>> juju deploy mysql --constraints spaces=db-space,^space_i_dont_want
>>>>>
>>>>> in that case the machine is filtered out, because, as i said before,
>>>>> it means "a machine that is in db-space space but not in space_i_dont_want
>>>>> space".
>>>>>
>>>>> i just want it to pick the right ip!
>>>>>
>>>>> I checked the json coming from maas: it seems sorting ipv4 addresses
>>>>> from "smallest" to biggest and juju just picks the first one. in juju
>>>>> status i continue to see "dns-name" set to the wrong ip address, which
>>>>> doesn't resolve too.
>>>>>
>>>>> even using --to fqdn it doesn't get the right ip
>>>>>
>>>>> So i think there are two bugs:
>>>>> 1) juju deploy --bind cannot find space name reporting "empty names"
>>>>> error msg
>>>>> 2) juju doesn't try to resolve ips/hostname to check what's the
>>>>> machine name
>>>>>
>>>>> can you reproduce it?
>>>>>
>>>>> Patrizio
>>>>>
>>>>>
>>>>> 2017-03-09 8:39 GMT+01:00 Ante Karamatić <ante.karama...@canonical.com
>>>>&g

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

In the meantime, you can work around it by specifying the bindings
directly: so in the case of mysql that would be:
 juju deploy mysql --bind "db=db-space monitors=db-space ha=db-space ..."

John
=:->


On Thu, Mar 9, 2017 at 7:25 AM, John Meinel <j...@arbash-meinel.com> wrote:

> "juju deploy mysql --bind db-space" is exactly the syntax that should be
> working, and I'm seeing it failing now. I will work to fix that and make
> sure we don't regress here. We certainly should have caught that before
> release.
>
> John
> =:->
>
>
> On Thu, Mar 9, 2017 at 1:47 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi Ante,
>>
>> no that is not working, but i think it's by design.
>> That constraint means: pick up a machine that has a leg in the db-space
>> leg.
>>
>> So my machine with 2 eth ports in two different spaces satisfy that 
>> constraint,
>> it is picked, but the IP is wrong.
>>
>> Another option i tried is:
>>
>> juju deploy mysql --constraints spaces=db-space,^space_i_dont_want
>>
>> in that case the machine is filtered out, because, as i said before, it
>> means "a machine that is in db-space space but not in space_i_dont_want
>> space".
>>
>> i just want it to pick the right ip!
>>
>> I checked the json coming from maas: it seems sorting ipv4 addresses from
>> "smallest" to biggest and juju just picks the first one. in juju status i
>> continue to see "dns-name" set to the wrong ip address, which doesn't
>> resolve too.
>>
>> even using --to fqdn it doesn't get the right ip
>>
>> So i think there are two bugs:
>> 1) juju deploy --bind cannot find space name reporting "empty names"
>> error msg
>> 2) juju doesn't try to resolve ips/hostname to check what's the machine
>> name
>>
>> can you reproduce it?
>>
>> Patrizio
>>
>>
>> 2017-03-09 8:39 GMT+01:00 Ante Karamatić <ante.karama...@canonical.com>:
>>
>>> Hi Patrizio,
>>>
>>> this is exactly what I saw yesterday too, unrelated to this thread. What
>>> you could do is:
>>>
>>> juju deploy mysql --constraints spaces=db-space
>>>
>>> Let me know if the constraints workaround works for you.
>>>
>>> On Thu, Mar 9, 2017 at 8:28 AM Patrizio Bassi <patrizio.ba...@gmail.com>
>>> wrote:
>>>
>>>> Hi John,
>>>>
>>>> i simply would like to do what's written in https://jujucharms.com/docs
>>>> /2.1/charms-deploying
>>>>
>>>> "When deploying an application to a target with multiple spaces, the
>>>> operator must specify which space to use because ambiguous bindings will
>>>> result in a provisioning failure."
>>>>
>>>> This is exactly my case: a machine with 2 eth ports, two different
>>>> subnets in two different spaces.
>>>>
>>>> the doc says i may do (c/p): $ juju deploy mysql --bind db-space
>>>>
>>>> and so bind a maas space for all the application. Unfortunately it
>>>> seems not working (i get the "empty names" error).
>>>>
>>>> Patrizio
>>>>
>>>> 2017-03-08 20:40 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>>>
>>>> So without bindings, I would expect the behavior, the question is why
>>>> you would be seeing:
>>>>  "cannot run instances: cannot run instance:  interface bindings
>>>> cannot have empty names"
>>>>
>>>> Can you open a bug on https://bugs.launchpad.net/juju/+filebug and
>>>> include some more information like the logs from the controller machine?
>>>>
>>>> I'm not quite sure I understand what you mean by "my binding should be
>>>> global for a local bundle charm".
>>>>
>>>> John
>>>> =:->
>>>>
>>>>
>>>> On Wed, Mar 8, 2017 at 9:36 AM, Patrizio Bassi <
>>>> patrizio.ba...@gmail.com> wrote:
>>>>
>>>> i just upgraded to 2.1.1-xenial-amd64, same behaviour unfortunately.
>>>>
>>>> As i'm going to deploy openstack services (now i'm using ceph-osd just
>>>> to test, than my binding should be global for a local bundle charm) i would
>>>> like to say: all juju endpoint (bare metal/lxd containers) just get a
>>>> 10.xxx address, not 192.xxx.
>>>>
>>>> Patrizio
>&

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

"juju deploy mysql --bind db-space" is exactly the syntax that should be
working, and I'm seeing it failing now. I will work to fix that and make
sure we don't regress here. We certainly should have caught that before
release.

John
=:->


On Thu, Mar 9, 2017 at 1:47 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:

> Hi Ante,
>
> no that is not working, but i think it's by design.
> That constraint means: pick up a machine that has a leg in the db-space
> leg.
>
> So my machine with 2 eth ports in two different spaces satisfy that 
> constraint,
> it is picked, but the IP is wrong.
>
> Another option i tried is:
>
> juju deploy mysql --constraints spaces=db-space,^space_i_dont_want
>
> in that case the machine is filtered out, because, as i said before, it
> means "a machine that is in db-space space but not in space_i_dont_want
> space".
>
> i just want it to pick the right ip!
>
> I checked the json coming from maas: it seems sorting ipv4 addresses from
> "smallest" to biggest and juju just picks the first one. in juju status i
> continue to see "dns-name" set to the wrong ip address, which doesn't
> resolve too.
>
> even using --to fqdn it doesn't get the right ip
>
> So i think there are two bugs:
> 1) juju deploy --bind cannot find space name reporting "empty names" error
> msg
> 2) juju doesn't try to resolve ips/hostname to check what's the machine
> name
>
> can you reproduce it?
>
> Patrizio
>
>
> 2017-03-09 8:39 GMT+01:00 Ante Karamatić <ante.karama...@canonical.com>:
>
>> Hi Patrizio,
>>
>> this is exactly what I saw yesterday too, unrelated to this thread. What
>> you could do is:
>>
>> juju deploy mysql --constraints spaces=db-space
>>
>> Let me know if the constraints workaround works for you.
>>
>> On Thu, Mar 9, 2017 at 8:28 AM Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>>
>>> Hi John,
>>>
>>> i simply would like to do what's written in https://jujucharms.com/docs
>>> /2.1/charms-deploying
>>>
>>> "When deploying an application to a target with multiple spaces, the
>>> operator must specify which space to use because ambiguous bindings will
>>> result in a provisioning failure."
>>>
>>> This is exactly my case: a machine with 2 eth ports, two different
>>> subnets in two different spaces.
>>>
>>> the doc says i may do (c/p): $ juju deploy mysql --bind db-space
>>>
>>> and so bind a maas space for all the application. Unfortunately it seems
>>> not working (i get the "empty names" error).
>>>
>>> Patrizio
>>>
>>> 2017-03-08 20:40 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>>
>>> So without bindings, I would expect the behavior, the question is why
>>> you would be seeing:
>>>  "cannot run instances: cannot run instance:  interface bindings cannot
>>> have empty names"
>>>
>>> Can you open a bug on https://bugs.launchpad.net/juju/+filebug and
>>> include some more information like the logs from the controller machine?
>>>
>>> I'm not quite sure I understand what you mean by "my binding should be
>>> global for a local bundle charm".
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Wed, Mar 8, 2017 at 9:36 AM, Patrizio Bassi <patrizio.ba...@gmail.com
>>> > wrote:
>>>
>>> i just upgraded to 2.1.1-xenial-amd64, same behaviour unfortunately.
>>>
>>> As i'm going to deploy openstack services (now i'm using ceph-osd just
>>> to test, than my binding should be global for a local bundle charm) i would
>>> like to say: all juju endpoint (bare metal/lxd containers) just get a
>>> 10.xxx address, not 192.xxx.
>>>
>>> Patrizio
>>>
>>>
>>> 2017-03-08 16:27 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>>
>>> Is it possible for you to test with Juju 2.1? I haven't seen that
>>> particular bug with binding, but I have done a lot more testing with 2.1. I
>>> didn't think we changed the particular "empty space" differences.
>>>
>>> The other possibility is to try and explicitly list the endpoints:
>>>
>>>   juju deploy ceph-osd --bind "public=XXX cluster=YYY"
>>>
>>> I would have thought you would want something more like:
>>>
>>>   juju deploy ceph-osd --bind "management public=PUBLIC"
>>>
&g

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

What version of MAAS? Just in case the problem is a mismatch with all the
tests I've been doing so far.

John
=:->

On Mar 9, 2017 07:05, wrote:

We intentionally use "" to mean the default value for everything else,
which is why I need to understand where we are actually getting the error.
I'll try to reproduce it today.

John
=:->

On Mar 9, 2017 01:28, "Patrizio Bassi" <patrizio.ba...@gmail.com> wrote:

Hi John,

i simply would like to do what's written in https://jujucharms.com/
docs/2.1/charms-deploying

"When deploying an application to a target with multiple spaces, the
operator must specify which space to use because ambiguous bindings will
result in a provisioning failure."

This is exactly my case: a machine with 2 eth ports, two different subnets
in two different spaces.

the doc says i may do (c/p): $ juju deploy mysql --bind db-space

and so bind a maas space for all the application. Unfortunately it seems
not working (i get the "empty names" error).

Patrizio

2017-03-08 20:40 GMT+01:00 John Meinel <j...@arbash-meinel.com>:

> So without bindings, I would expect the behavior, the question is why you
> would be seeing:
>  "cannot run instances: cannot run instance:  interface bindings cannot
> have empty names"
>
> Can you open a bug on https://bugs.launchpad.net/juju/+filebug and
> include some more information like the logs from the controller machine?
>
> I'm not quite sure I understand what you mean by "my binding should be
> global for a local bundle charm".
>
> John
> =:->
>
>
> On Wed, Mar 8, 2017 at 9:36 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> i just upgraded to 2.1.1-xenial-amd64, same behaviour unfortunately.
>>
>> As i'm going to deploy openstack services (now i'm using ceph-osd just to
>> test, than my binding should be global for a local bundle charm) i would
>> like to say: all juju endpoint (bare metal/lxd containers) just get a
>> 10.xxx address, not 192.xxx.
>>
>> Patrizio
>>
>>
>> 2017-03-08 16:27 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>
>>> Is it possible for you to test with Juju 2.1? I haven't seen that
>>> particular bug with binding, but I have done a lot more testing with 2.1. I
>>> didn't think we changed the particular "empty space" differences.
>>>
>>> The other possibility is to try and explicitly list the endpoints:
>>>
>>>   juju deploy ceph-osd --bind "public=XXX cluster=YYY"
>>>
>>> I would have thought you would want something more like:
>>>
>>>   juju deploy ceph-osd --bind "management public=PUBLIC"
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Wed, Mar 8, 2017 at 9:22 AM, Patrizio Bassi <patrizio.ba...@gmail.com
>>> > wrote:
>>>
>>>> It looks like it's not working
>>>>
>>>> $ juju deploy ceph-osd --bind "management"
>>>>
>>>> $ juju show-machine 0  shows
>>>> "message: 'failed to start instance (cannot run instances: cannot run
>>>> instance:  interface bindings cannot have empty names), retrying in 10s (3
>>>> more attempts)'
>>>>
>>>> ...than after some seconds it fails. juju spaces sees the spaces from
>>>> MaaS without issues.
>>>>
>>>> without forcing bindings
>>>>
>>>> $ juju show-machine 0
>>>> model: openstack
>>>> machines:
>>>>   "0":
>>>> juju-status:
>>>>   current: pending
>>>>   since: 08 Mar 2017 15:14:55Z
>>>> dns-name: 192.168.0.2
>>>> ip-addresses:
>>>> - 192.168.0.2
>>>> - 10.0.8.12
>>>> instance-id: abkgqx
>>>> machine-status:
>>>>   current: allocating
>>>>   message: Deploying
>>>>   since: 08 Mar 2017 15:15:09Z
>>>> series: xenial
>>>> hardware: arch=amd64 cores=4 mem=8192M tags=virtual
>>>> availability-zone=primary
>>>>
>>>> it looks a bug, or better, the bug: dns-name is 192.x.x.x but it's not
>>>> true, 10.0.8.12 is the real hostname provided by external dns.
>>>>
>>>> Patrizio
>>>>
>>>> 2017-03-08 14:57 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>>>
>>>>> You should be using "juju deploy application --bind space" to declare
>>>>> which set of addresses you want the appl

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

We intentionally use "" to mean the default value for everything else,
which is why I need to understand where we are actually getting the error.
I'll try to reproduce it today.

John
=:->

On Mar 9, 2017 01:28, "Patrizio Bassi" <patrizio.ba...@gmail.com> wrote:

> Hi John,
>
> i simply would like to do what's written in https://jujucharms.com/
> docs/2.1/charms-deploying
>
> "When deploying an application to a target with multiple spaces, the
> operator must specify which space to use because ambiguous bindings will
> result in a provisioning failure."
>
> This is exactly my case: a machine with 2 eth ports, two different subnets
> in two different spaces.
>
> the doc says i may do (c/p): $ juju deploy mysql --bind db-space
>
> and so bind a maas space for all the application. Unfortunately it seems
> not working (i get the "empty names" error).
>
> Patrizio
>
> 2017-03-08 20:40 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>
>> So without bindings, I would expect the behavior, the question is why you
>> would be seeing:
>>  "cannot run instances: cannot run instance:  interface bindings cannot
>> have empty names"
>>
>> Can you open a bug on https://bugs.launchpad.net/juju/+filebug and
>> include some more information like the logs from the controller machine?
>>
>> I'm not quite sure I understand what you mean by "my binding should be
>> global for a local bundle charm".
>>
>> John
>> =:->
>>
>>
>> On Wed, Mar 8, 2017 at 9:36 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>>
>>> i just upgraded to 2.1.1-xenial-amd64, same behaviour unfortunately.
>>>
>>> As i'm going to deploy openstack services (now i'm using ceph-osd just
>>> to test, than my binding should be global for a local bundle charm) i would
>>> like to say: all juju endpoint (bare metal/lxd containers) just get a
>>> 10.xxx address, not 192.xxx.
>>>
>>> Patrizio
>>>
>>>
>>> 2017-03-08 16:27 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>>
>>>> Is it possible for you to test with Juju 2.1? I haven't seen that
>>>> particular bug with binding, but I have done a lot more testing with 2.1. I
>>>> didn't think we changed the particular "empty space" differences.
>>>>
>>>> The other possibility is to try and explicitly list the endpoints:
>>>>
>>>>   juju deploy ceph-osd --bind "public=XXX cluster=YYY"
>>>>
>>>> I would have thought you would want something more like:
>>>>
>>>>   juju deploy ceph-osd --bind "management public=PUBLIC"
>>>>
>>>> John
>>>> =:->
>>>>
>>>>
>>>> On Wed, Mar 8, 2017 at 9:22 AM, Patrizio Bassi <
>>>> patrizio.ba...@gmail.com> wrote:
>>>>
>>>>> It looks like it's not working
>>>>>
>>>>> $ juju deploy ceph-osd --bind "management"
>>>>>
>>>>> $ juju show-machine 0  shows
>>>>> "message: 'failed to start instance (cannot run instances: cannot run
>>>>> instance:  interface bindings cannot have empty names), retrying in 10s (3
>>>>> more attempts)'
>>>>>
>>>>> ...than after some seconds it fails. juju spaces sees the spaces from
>>>>> MaaS without issues.
>>>>>
>>>>> without forcing bindings
>>>>>
>>>>> $ juju show-machine 0
>>>>> model: openstack
>>>>> machines:
>>>>>   "0":
>>>>> juju-status:
>>>>>   current: pending
>>>>>   since: 08 Mar 2017 15:14:55Z
>>>>> dns-name: 192.168.0.2
>>>>> ip-addresses:
>>>>> - 192.168.0.2
>>>>> - 10.0.8.12
>>>>> instance-id: abkgqx
>>>>> machine-status:
>>>>>   current: allocating
>>>>>   message: Deploying
>>>>>   since: 08 Mar 2017 15:15:09Z
>>>>> series: xenial
>>>>> hardware: arch=amd64 cores=4 mem=8192M tags=virtual
>>>>> availability-zone=primary
>>>>>
>>>>> it looks a bug, or better, the bug: dns-name is 192.x.x.x but it's not
>>>>> true, 10.0.8.12 is the real hostname provided by external dns.
>>>>>
>>>&g

MySQL charm bugs

[John Meinel]

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

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

So without bindings, I would expect the behavior, the question is why you
would be seeing:
 "cannot run instances: cannot run instance:  interface bindings cannot
have empty names"

Can you open a bug on https://bugs.launchpad.net/juju/+filebug and include
some more information like the logs from the controller machine?

I'm not quite sure I understand what you mean by "my binding should be
global for a local bundle charm".

John
=:->


On Wed, Mar 8, 2017 at 9:36 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:

> i just upgraded to 2.1.1-xenial-amd64, same behaviour unfortunately.
>
> As i'm going to deploy openstack services (now i'm using ceph-osd just to
> test, than my binding should be global for a local bundle charm) i would
> like to say: all juju endpoint (bare metal/lxd containers) just get a
> 10.xxx address, not 192.xxx.
>
> Patrizio
>
>
> 2017-03-08 16:27 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>
>> Is it possible for you to test with Juju 2.1? I haven't seen that
>> particular bug with binding, but I have done a lot more testing with 2.1. I
>> didn't think we changed the particular "empty space" differences.
>>
>> The other possibility is to try and explicitly list the endpoints:
>>
>>   juju deploy ceph-osd --bind "public=XXX cluster=YYY"
>>
>> I would have thought you would want something more like:
>>
>>   juju deploy ceph-osd --bind "management public=PUBLIC"
>>
>> John
>> =:->
>>
>>
>> On Wed, Mar 8, 2017 at 9:22 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>>
>>> It looks like it's not working
>>>
>>> $ juju deploy ceph-osd --bind "management"
>>>
>>> $ juju show-machine 0  shows
>>> "message: 'failed to start instance (cannot run instances: cannot run
>>> instance:  interface bindings cannot have empty names), retrying in 10s (3
>>> more attempts)'
>>>
>>> ...than after some seconds it fails. juju spaces sees the spaces from
>>> MaaS without issues.
>>>
>>> without forcing bindings
>>>
>>> $ juju show-machine 0
>>> model: openstack
>>> machines:
>>>   "0":
>>> juju-status:
>>>   current: pending
>>>   since: 08 Mar 2017 15:14:55Z
>>> dns-name: 192.168.0.2
>>> ip-addresses:
>>> - 192.168.0.2
>>> - 10.0.8.12
>>> instance-id: abkgqx
>>> machine-status:
>>>   current: allocating
>>>   message: Deploying
>>>   since: 08 Mar 2017 15:15:09Z
>>> series: xenial
>>> hardware: arch=amd64 cores=4 mem=8192M tags=virtual
>>> availability-zone=primary
>>>
>>> it looks a bug, or better, the bug: dns-name is 192.x.x.x but it's not
>>> true, 10.0.8.12 is the real hostname provided by external dns.
>>>
>>> Patrizio
>>>
>>> 2017-03-08 14:57 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>>
>>>> You should be using "juju deploy application --bind space" to declare
>>>> which set of addresses you want the applications to use.  Does that not
>>>> work?
>>>>
>>>> John
>>>> =:->
>>>>
>>>>
>>>> On Wed, Mar 8, 2017 at 4:44 AM, Patrizio Bassi <
>>>> patrizio.ba...@gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I'm quite new the juju and it's charms. On ubuntu 16.04 LTS I have
>>>>> juju 2.0.2 using maas (2.1.3) cloud as provider.
>>>>>
>>>>> In maas I have configured (ready status) some machines, each one has 2
>>>>> eth ports, one with a public ip (same as juju client/controller 10.x.x.x)
>>>>> which resolves to machine hostname and the other meant to be private
>>>>> (192.x.x.x) and without a public gateway for instance.
>>>>>
>>>>> When deploying any application juju gets the machine from maas and
>>>>> starts using as public ip the 192.x.x.x one.
>>>>>
>>>>> I could not find any way to deploy using the 10.x.x.x, the guide in
>>>>> https://jujucharms.com/docs/2.0/network-spaces seems not appliable to
>>>>> my case (spaces/network are already correctly provided by maas).
>>>>>
>>>>> Can you please address me? Unfortunately I'm stuck with deploy
>>>>> Thank you
>>>>>
>>>>> Patrizio
>>>>>
>>>>> --
>>>>> Juju mailing list
>>>>> Juju@lists.ubuntu.com
>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>> an/listinfo/juju
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Patrizio Bassi
>>> www.patriziobassi.it
>>> http://piazzadelpopolo.patriziobassi.it
>>>
>>
>>
>
>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

Is it possible for you to test with Juju 2.1? I haven't seen that
particular bug with binding, but I have done a lot more testing with 2.1. I
didn't think we changed the particular "empty space" differences.

The other possibility is to try and explicitly list the endpoints:

  juju deploy ceph-osd --bind "public=XXX cluster=YYY"

I would have thought you would want something more like:

  juju deploy ceph-osd --bind "management public=PUBLIC"

John
=:->


On Wed, Mar 8, 2017 at 9:22 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:

> It looks like it's not working
>
> $ juju deploy ceph-osd --bind "management"
>
> $ juju show-machine 0  shows
> "message: 'failed to start instance (cannot run instances: cannot run
> instance:  interface bindings cannot have empty names), retrying in 10s (3
> more attempts)'
>
> ...than after some seconds it fails. juju spaces sees the spaces from MaaS
> without issues.
>
> without forcing bindings
>
> $ juju show-machine 0
> model: openstack
> machines:
>   "0":
> juju-status:
>   current: pending
>   since: 08 Mar 2017 15:14:55Z
> dns-name: 192.168.0.2
> ip-addresses:
> - 192.168.0.2
> - 10.0.8.12
> instance-id: abkgqx
> machine-status:
>   current: allocating
>   message: Deploying
>   since: 08 Mar 2017 15:15:09Z
> series: xenial
> hardware: arch=amd64 cores=4 mem=8192M tags=virtual
> availability-zone=primary
>
> it looks a bug, or better, the bug: dns-name is 192.x.x.x but it's not
> true, 10.0.8.12 is the real hostname provided by external dns.
>
> Patrizio
>
> 2017-03-08 14:57 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>
>> You should be using "juju deploy application --bind space" to declare
>> which set of addresses you want the applications to use.  Does that not
>> work?
>>
>> John
>> =:->
>>
>>
>> On Wed, Mar 8, 2017 at 4:44 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm quite new the juju and it's charms. On ubuntu 16.04 LTS I have juju
>>> 2.0.2 using maas (2.1.3) cloud as provider.
>>>
>>> In maas I have configured (ready status) some machines, each one has 2
>>> eth ports, one with a public ip (same as juju client/controller 10.x.x.x)
>>> which resolves to machine hostname and the other meant to be private
>>> (192.x.x.x) and without a public gateway for instance.
>>>
>>> When deploying any application juju gets the machine from maas and
>>> starts using as public ip the 192.x.x.x one.
>>>
>>> I could not find any way to deploy using the 10.x.x.x, the guide in
>>> https://jujucharms.com/docs/2.0/network-spaces seems not appliable to
>>> my case (spaces/network are already correctly provided by maas).
>>>
>>> Can you please address me? Unfortunately I'm stuck with deploy
>>> Thank you
>>>
>>> Patrizio
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

You should be using "juju deploy application --bind space" to declare which
set of addresses you want the applications to use.  Does that not work?

John
=:->


On Wed, Mar 8, 2017 at 4:44 AM, Patrizio Bassi 
wrote:

> Hi All,
>
> I'm quite new the juju and it's charms. On ubuntu 16.04 LTS I have juju
> 2.0.2 using maas (2.1.3) cloud as provider.
>
> In maas I have configured (ready status) some machines, each one has 2 eth
> ports, one with a public ip (same as juju client/controller 10.x.x.x) which
> resolves to machine hostname and the other meant to be private (192.x.x.x)
> and without a public gateway for instance.
>
> When deploying any application juju gets the machine from maas and starts
> using as public ip the 192.x.x.x one.
>
> I could not find any way to deploy using the 10.x.x.x, the guide in
> https://jujucharms.com/docs/2.0/network-spaces seems not appliable to my
> case (spaces/network are already correctly provided by maas).
>
> Can you please address me? Unfortunately I'm stuck with deploy
> Thank you
>
> Patrizio
>
> --
> 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: Issue with Amulet testing

[John Meinel]

Seems more like just a python thing, vs anything to do with Amulet.
 https://github.com/kennethreitz/requests/issues/2214
Says you can do some magic around disabled warnings

A better goal might be to have the charm optionally take the config of a
cert to use and configure your tests to include that as a valid certificate.

http://docs.python-requests.org/en/master/user/advanced/
Indicates a few ways you should be able to describe the certificate
authority that you should trust.

John
=:->

On Mar 2, 2017 15:15, "Suchitra Venugopal1"  wrote:

> Hi
>
>  I am trying to run the following amulet test on my charm  where it
> verifies a particular url.
>
> self.assertTrue(self.d.deployed)
> unit = self.d.sentry['ibm-mobilefirst-server'][0]
> url = 'http://%s:9081/appcenterconsole' % unit.info
> ['public-address']
> https_url = 'https://%s:9443/appcenterconsole' % unit.info
> ['public-address']
> print('Url is %s' % url)
> response = requests.get(url, verify=False)
> response = requests.get(https_url, verify=False)
> # Raise an exception if the url was not a valid web page.
> response.raise_for_status()
>
>
> While running amulet, it throws an error as "InsecureRequestWarning:
> Unverified HTTPS request is being made". Can anyone please let me know how
> to resolve this ?
>
> E2017-03-02 01:00:38 Starting deployment of lxd-testing:admin/default
> 2017-03-02 01:00:38 Deploying applications...
> 2017-03-02 01:00:43 Config specifies num units for subordinate:
> ibm-mobilefirst-server
> 2017-03-02 01:00:44 Adding relations...
> 2017-03-02 01:00:44 Deployment complete in 6.19 seconds
> Url is http://:9081/appcenterconsole
> 
> /usr/lib/python3/dist-packages/urllib3/connectionpool.py:794:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.org/en/latest/security.html
>   InsecureRequestWarning)
>
> I tried to install some additional packages as mentioned in the link
> https://urllib3.readthedocs.org/en/latest/security.html. But that doesn't
> help.
>
> *Suchitra Venugopal*
>
> *Project ManagerJuju Charms*
> --
> *Phone: **+91-80-494-93581*
> *Mobile: **+91-966-312-6000*
> *E-mail: **suchv...@in.ibm.com* 
> *Product Transformation Centre* 
>
> *INDIA SOFTWARE LABS, IBM SYSTEMS,EGL C, 6th FLOOR, BANGALORE*
>
>
>
> --
> 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