conjure-up dev summary: aws native integration, vsphere <3, and ADDONS

[Adam Stokes]

New dev summary is out!

http://blog.astokes.org/conjure-up-dev-summary-aws-cloud-native-integration-and-vsphere-3/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Question about deploying Openstack with juju

[Adam Stokes]

Can you elaborate? Do you mean running inside a virtual machine? If so, you
want to make sure you have enough memory and disk space allocated (~16G RAM
and 100G HDD)

On Thu, Aug 10, 2017 at 1:56 PM wahi <w...@sci.am> wrote:

> Hi Adam,
>
> Thanks for your reply.
>
> Actually I know about it, but it is not working with virtual machines, am
> I right ?
>
> On 08/10/2017 09:23 PM, Adam Stokes wrote:
>
> Wahi,
>
> https://conjure-up.io will allow you to do a full OpenStack deployment on
> a single machine. Please have a look and see if that gets you what you want.
>
> On Thu, Aug 10, 2017 at 12:28 PM wahi <w...@sci.am> wrote:
>
>> Dear all,
>>
>> I am trying to find some tutorial or resources about installing
>> Openstack using juju. Let say some simple experimental environment with
>> three nodes or virtual machines (controller, compute and neutron).
>>
>> Could you please point me to any helpful resources to be used for this
>> purpose.
>>
>> Thank you very much in advance.
>>
>>
>>
>> Regards,
>>   Wahi
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Question about deploying Openstack with juju

[Adam Stokes]

Wahi,

https://conjure-up.io will allow you to do a full OpenStack deployment on a
single machine. Please have a look and see if that gets you what you want.

On Thu, Aug 10, 2017 at 12:28 PM wahi  wrote:

> Dear all,
>
> I am trying to find some tutorial or resources about installing
> Openstack using juju. Let say some simple experimental environment with
> three nodes or virtual machines (controller, compute and neutron).
>
> Could you please point me to any helpful resources to be used for this
> purpose.
>
> Thank you very much in advance.
>
>
>
> Regards,
>   Wahi
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Promulgate request: dokuwiki

[Adam Stokes]

Hi,

Could I get cs:~adam-stokes/dokuwiki-32 promulgated?

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

Re: conjure-up status: conjure-up is currently broken

[Adam Stokes]

Follow up, if you haven't done a fresh install of Ubuntu (meaning you've
had a previous version of the snap core) you may be able to get around this
by running `sudo snap revert core` until a proper solution can be found.

On Mon, Jul 17, 2017 at 8:27 PM Adam Stokes <adam.sto...@canonical.com>
wrote:

> The details can be found here:
> https://forum.snapcraft.io/t/snapd-2-26-9-and-conjure-up-no-longer-work/1348
>
> I've pinged the snappy team and waiting to hear back on what the next
> course of action is.
>
> I'll send out another email once this issue is resolved.
>
> Thank you for your patience
> Adam
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

conjure-up status: conjure-up is currently broken

[Adam Stokes]

The details can be found here:
https://forum.snapcraft.io/t/snapd-2-26-9-and-conjure-up-no-longer-work/1348

I've pinged the snappy team and waiting to hear back on what the next
course of action is.

I'll send out another email once this issue is resolved.

Thank you for your patience
Adam
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Adam Stokes]

conjure-up was merged into hombrew last night, please give the macOS
version a try and let us know if there are any issues:

brew install conjure-up

Thanks!

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

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

Re: Juju 2.2-alpha and conjure-up, are here!

[Adam Stokes]

Thanks for the heads up, this is now fixed

$ sudo snap refresh conjure-up --beta

On Fri, Mar 17, 2017 at 9:49 AM Mark Shuttleworth  wrote:

> On 16/03/17 14:19, Curtis Hovey-Canonical wrote:
> > ## How do I get it?
> >
> > If you are running Ubuntu, you can get Juju from the juju stable ppa:
> >
> >sudo add-apt-repository ppa:juju/devel; sudo apt-get update
> >
> >sudo apt-get install juju
> >
> > Or install Juju from the snap store:
> >
> >snap install juju --classic --beta
> >
> > Install conjure-up from the snap store:
> >
> >snap install conjure-up --classic --edge
>
> Can we release conjure-up 2.2a1 to --beta too please? I was surprised
> not to get it automatically. Since it's an actual milestone it should
> make it out of --edge into one of the other channels.
>
> Mark
>
> --
> 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: [lxc-users] Kubernetes Storage Provisioning using LXD

[Adam Stokes]

Cross posting to juju lists. It is my understanding that if you add ceph
units to your juju environment or setup an NFS export that kubernetes can
make use of both of those. Someone from the containers team would know more.

On Thu, Feb 16, 2017 at 3:08 PM Eric  wrote:

> That's is what I've also been trying to do
>
> Kubernetes has a list of supported persistent volume types, of which the
> only one's that aren't cloud-based that I've tried are NFS, CephFS,
> Glusterfs, and HostPath
>
>
> https://kubernetes.io/docs/user-guide/persistent-volumes/#types-of-persistent-volumes
>
> With LXC + ZFS you can't:
>
> - provide a raw block device (/dev/sad) to heketi, or a loopback device
> (/dev/loop0). so glusterfs is out of the picture (
> https://github.com/heketi/heketi/issues/665)
> - cephfs is like glusterfs, so cephfs is out
> - NFS requires kernel modules, so nfs is out
> - HostPath doesn't work over multiple nodes
>
> So your only option is to use KVM
>
> I use Proxmox. I knew LXC/LXD wasn't going to be able to fulfill what I
> needed to do on a single server, so I looked for a hypervisor that had a
> polished UI for creating both LXC and KVM VM
>
> I'm still going to go with glusterfs, which will also need heketi, and
> will be running it in a fedora kvm. And the using it as a persistent volume
> for kubernetes
>
>
>
>
> On Wed, Feb 15, 2017 at 4:16 AM, Butch Landingin 
> wrote:
>
> Hi all,
>
> I've been trying out Canonical Kubernetes via conjure-up and juju charms on
> a local LXD cluster. Following the tutorials, I've set up the cluster
> running on lxd with a zfs file system.
>
> Everything's been great and I've pretty much exhausted the tutorials
> (running microbot, etc).
>
> I'm now at the point where I want to try provisioning some persistent
> volumes or even trying
> dynamic storage allocation.
>
> By this time, I'm 99 percent sure the answer is no (and I've searched
> extensively) ,
> but is there anyway to create Kubernetes persistent volumes on a multi
> node set up (not using hostpath)
> on a local LXD cluster?
>
> If there isn't,  does Canonical have this in their roadmap?
>
> Best regards,
> Butch
>
>
> ___
> lxc-users mailing list
> lxc-us...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
> ___
> lxc-users mailing list
> lxc-us...@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: I still can't upload resources to the Charm store.

[Adam Stokes]

I think your issue is the one that Cory reported on about the resource
being to big of a blob for the charm store to process. I think his resource
was at 90M while yours is 720M. See here:
https://github.com/CanonicalLtd/jujucharms.com/issues/332

According to the bug it doesn't seem like a trivial fix so it may take some
time but the right people are aware of it and will get it addressed.

On Sun, Feb 5, 2017 at 10:58 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Update: Specified the specific revision in my push command and now it
> fails in a different way:
>
>
> $charm attach ~tengu-team/apache-nifi-1
> apache-nifi=./nifi-1.1.1-bin.tar.gz
> ERROR can't upload resource: cannot post resource: cannot unmarshal error
> response " 2.0//EN\">\n\n502 Proxy
> Error\n\nProxy Error\nThe proxy server
> received an invalid\r\nresponse from an upstream server.\r\nThe proxy
> server could not handle the request  href=\"/charmstore/v5/~tengu-team/apache-nifi-1/resource/apache-nifi\">POST/charmstore/v5/~tengu-team/apache-nifi-1/resource/apache-nifi.\nReason:
> Error reading from remote
> server\n\nApache/2.4.7 (Ubuntu) Server at
> api.jujucharms.com Port 443\n\n": invalid
> character '<' looking for beginning of value
>
>
>
> 2017-02-05 15:51 GMT+01:00 Adam Stokes <adam.sto...@canonical.com>:
>
> https://github.com/juju/charmstore-client/issues/96
>
> No one from that team has provided any additional input, even though I've
> been asking and this is obviously a huge problem for users in general.
>
> On Sun, Feb 5, 2017, 8:13 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
> Hi all
>
>
> Uploading resources to the Charm store still fails for me. It seems this
> is still the same error that I had back in Juli:
> https://bugs.launchpad.net/ubuntu/+source/charm/+bug/1592822.
>
> What I run:
>
> wget http://apache.belnet.be/nifi/1.1.1/nifi-1.1.1-bin.tar.gz
> charm attach ~tengu-team/apache-nifi apache-nifi=./nifi-1.1.1-bin.tar.gz
>
> What I get:
>
> ERROR can't upload resource: cannot post resource: cannot unmarshal error
> response " 2.0//EN\">\n\n502 Bad
> Gateway\n\nBad Gateway\nThe proxy server
> received an invalid\r\nresponse from an upstream server. />\r\n\n\nApache/2.4.7 (Ubuntu) Server at
> api.jujucharms.com Port 443\n\n": invalid
> character '<' looking for beginning of value
>
>
> --
> 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: I still can't upload resources to the Charm store.

[Adam Stokes]

https://github.com/juju/charmstore-client/issues/96

No one from that team has provided any additional input, even though I've
been asking and this is obviously a huge problem for users in general.

On Sun, Feb 5, 2017, 8:13 AM Merlijn Sebrechts 
wrote:

> Hi all
>
>
> Uploading resources to the Charm store still fails for me. It seems this
> is still the same error that I had back in Juli:
> https://bugs.launchpad.net/ubuntu/+source/charm/+bug/1592822.
>
> What I run:
>
> wget http://apache.belnet.be/nifi/1.1.1/nifi-1.1.1-bin.tar.gz
> charm attach ~tengu-team/apache-nifi apache-nifi=./nifi-1.1.1-bin.tar.gz
>
> What I get:
>
> ERROR can't upload resource: cannot post resource: cannot unmarshal error
> response " 2.0//EN\">\n\n502 Bad
> Gateway\n\nBad Gateway\nThe proxy server
> received an invalid\r\nresponse from an upstream server. />\r\n\n\nApache/2.4.7 (Ubuntu) Server at
> api.jujucharms.com Port 443\n\n": invalid
> character '<' looking for beginning of value
>
>
> --
> 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: Removing the single point of failure

[Adam Stokes]

Circling back around to this. Do we have an ETA or any updates on the
progress of interfaces.juju.solutions being folded into jujucharms.com?

On Sat, Nov 12, 2016, 11:20 AM Marco Ceppi 
wrote:

> Hey everyone,
>
> We're aware of the outage and working to bring the service back online.
> This is unfortunate, but we're in the process of getting the
> interfaces.juju.solutions site, folded into the charm store properly. This
> service has done it's job in providing the initial indexing but as we see
> today it's become integral to the operation of charm authorship and should
> be as robust as the charm store itself.
>
> To address concerns about "what if". Juju, the interfaces site, the charm
> layers, are all open source projects. While some items aren't directly
> configurable if we ever did enter a period where Canonical wasn't directly
> maintaining infrastructure for Juju and Charms the community could uphold
> these projects and elect to run them directly. Juju is a key platform to
> Canonical just as it is to you all. While outages like this may occur, we
> are iterating quickly to make sure projects like the interfaces site are
> folded into jujucharms.com and served with the same level SLA and HA as
> you've come to expect.
>
> Marco
>
> On Sat, Nov 12, 2016 at 10:44 AM Tom Barber  wrote:
>
> I don't really think Mark is going to do one, my point is that for
> platforms like this to survive if they depend on central services for
> build/running etc, the services shouldn't just be maintained by a single
> entity.
>
> HA sure will solve some issues but I also think that distributing
> ownership also mitigates risk.
>
> On 12 Nov 2016 16:39, "James Beedy"  wrote:
>
> Here's something thats been troubling me for a while, Canonical are the
> single point of failure with juju. For example, this morning
> interfaces.juju.solutions appears to be offline, thats not the end of the
> world but of course I can't download layers from it.
>
> I entirely second this. Interfaces.juju.solutions needs to have some kind
> of uptime guarantee, and probably need each component deployed in
> HA/federated to ensure the uptime.
>
> Companies/people are building infrastructure around the charm store,
> interfaces.juju.solutions, and juju itself, what happens when 100 entities
> realize that their CI (or any critical infrastructure) has been down for an
> amount of time? For many, this could stunt development and increase budget
> expenditures.
>
>
> Similarly, if Mark for whatever reason decided he couldn't be bothered with
> Juju any more and went and did something else, the users would be without
> resource that is vital to people building stuff.
>
>
> I have to disagree with you here. Mark is an amazing driver for these
> technologies and technology communities, but they exist outside of, and
> disparate of Mark and Canonical. While the world (as well as these
> technologies) would undoubtedly not be same if not for Mark's
> contribution(s), I think the idea here is that the majority of the software
> in Canonical stack has enough wind under it to survive in the wild.
>
> Does mirroring capabilities exist for other people to mirror
> interfaces.juju.solutions and can you tell juju to use another portal? That
> way, much like maven central, those of us with bandwidth could mirror
> resources that are vital for smooth running of Juju operations.
>
> True, mirroring would be huge, but shouldn't be a solution . We should
> deploy the site across multiple az/regions if you ask me :-)
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] conjure-up classic snap available

[Adam Stokes]

Conjure-up is a power tool for getting started with big software.

Conjure-up lets you summon up a big-software stack as a “spell” - a model
of the stack, combined with extra know-how to get you from an installed
stack to a fully usable one. Start using your big software instead of
learning how to deploy it.

To install run:

$ sudo snap install conjure-up --classic --beta

* Note: snapd v2.21 is required and was released to xenial-updates
yesterday so please make sure you're on the latest version for classic
installs to work.

Getting started:

$ conjure-up

To teardown any deployments run:

$ conjure-down

I plan on having this the recommended way to deploy big software, so please
help me in ironing out any potential issues that may be seen while running
this as a snap.

The snap source can be found @ https://github.com/conjure-up/conjure-up-snap
conjure-up website @ http://conjure-up.io

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

Re: using a bundle with manually added machines (redux)

[Adam Stokes]

We have a feature coming in conjure-up that supports pinning and deploying
to specific machines if on MAAS. You can test this out by adding the
`ppa:conjure-up/daily-git` ppa and pressing the 'Architecture' button on
the charm deploy screen.

This will allow you to do 2 things:

1. Pin applications to machines that have already been defined in the
bundle itself (effectively editing the bundle)

2. Allow you to select a MAAS machine to deploy the application to along
with giving you the ability to set the container type to either bare metal,
kvm, or lxd.

On Thu, Dec 29, 2016, 2:17 PM Vance Morris  wrote:

I'm going to assume that it's not working for me because I'm not using a
cloud provider and instead manually adding the machines to Juju prior to
deploying the bundle.

I would think that this is a supported approach, but maybe I'm outside the
bounds here...

Thanks,
Vance

-Merlijn Sebrechts  wrote: -
To: Vance Morris/Dallas/IBM@IBMUS
From: Merlijn Sebrechts 
Date: 12/29/2016 11:09AM
Cc: "juju@lists.ubuntu.com" 
Subject: Re: using a bundle with manually added machines (redux)

Sorry, didn't see that, I was on my phone.

The bundle looks correct to me, and everything seems in order when I import
it into demo.jujucharms.com so I'm not sure why it doesn't work for you..

2016-12-29 17:13 GMT+01:00 Vance Morris :
Greets Merlijn,

 The bundle was attached to the original message, sorry I didn't call it
out.

 See here:
https://lists.ubuntu.com/archives/juju/attachments/20161229/8b65108b/attachment.obj

 Thanks,
 Vance


 -Merlijn Sebrechts  wrote: -
 To: Vance Morris/Dallas/IBM@IBMUS
 From: Merlijn Sebrechts 
 Date: 12/29/2016 08:33AM
 Cc: "juju@lists.ubuntu.com" 
 Subject: Re: using a bundle with manually added machines (redux)


 Defining the machines and defining the correct machines for each
application using `to` should work.

 The error message looks like some applications don't define machines so
juju tries to create new machines which obviously fails. Is it possible to
share the bundle that produces this error message and show the command you
use to deploy that bundle?

 Note that if an application has multiple units, you must specify multiple
machines to deploy to.

 Op donderdag 29 december 2016 heeft Vance Morris  het
volgende geschreven:
 > Whoops, sorry for that last message -- let's try this again!
 >
 > Hi all,
 >
 > Is it possible to use a bundle.yaml in conjunction with manually added
machines?
 >
 > $ juju version
 > 2.0.2-xenial-s390x
 >
 > $ juju status
 > << snip >>
 > Machine  StateDNS   Inst id   Series  AZ
 > 0started  REDACTED  manual:REDACTED   xenial
 > 1started  REDACTED  manual:REDACTED   xenial
 > 2started  REDACTED  manual:REDACTED   xenial
 > << snip >>
 >
 > When I go to deploy a bundle that defines machines 0, 1, and 2 and
describes deployment of services to these machines, the charms are
deployed, but no units are created.
 >
 > ERROR cannot deploy bundle: cannot create machine for holding aodh,
ceilometer, ceph-mon, ceph-osd, cinder, glance, keystone, mongodb, mysql,
neutron-api, neutron-gateway, nova-cloud-controller, nova-compute,
openstack-dashboard, rabbitmq-server, swift-proxy and swift-storage-z1
units: cannot add a new machine: use "juju add-machine ssh:[user@]"
to provision machines
 >
 > If I manually deploy charms to the manually added machines, it's happy
to oblige. Any suggestions?
 >
 >
 > Sincerely,
 >
 > Vance Morris
 > 1-720-349-9450 <(720)%20349-9450>
 > vmor...@us.ibm.com
 >





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

Re: errors in my juju deploy of canonical distribution of kubernetes

[Adam Stokes]

Hey Brian

You'll want to use conjure-up for the localhost (LXD) as we provide some
alterations to the lxc profile that houses those charms.

On Sun, Jan 1, 2017, 2:26 PM brian mullan  wrote:

> Environment:
>
> ubuntu 16.04 server VM (in kvm)
>
> 50GB disk
> 8 GB ram
> 4 cpu core
>
> I followed the instructions at:
> https://jujucharms.com/canonical-kubernetes/
> but I will retry with the conjure-up kubernetes method as well...
>
> which resulted in the following "juju status (note errors w/Flannel):
>
> ModelController  Cloud/Region Version
> default  lxd-testlocalhost/localhost  2.0.2
>
> AppVersion  Status   Scale  Charm
> Store   Rev  OS  Notes
> easyrsa3.0.1active   1  easyrsa
> jujucharms5  ubuntu
> etcd   2.2.5active   3  etcd
> jujucharms   21  ubuntu
> *flannel0.6.1error  *  4  flannel
> jujucharms7  ubuntu
> kubeapi-load-balancer  1.10.0   active   1  kubeapi-load-balancer
> jujucharms5  ubuntu  exposed
> kubernetes-master  1.5.1active   1  kubernetes-master
> jujucharms   10  ubuntu
> kubernetes-worker  1.5.1waiting  3  kubernetes-worker
> jujucharms   12  ubuntu  exposed
>
> Unit  Workload  Agent  Machine  Public address
> Ports Message
> easyrsa/0*activeidle   0
> 10.158.189.254Certificate Authority connected.
> etcd/0*   activeidle   110.158.189.107
> 2379/tcp  Healthy with 3 known peers.
> etcd/1activeidle   210.158.189.42
> 2379/tcp  Healthy with 3 known peers.
> etcd/2activeidle   310.158.189.223
> 2379/tcp  Healthy with 3 known peers.
> kubeapi-load-balancer/0*  activeidle   410.158.189.99
> 443/tcp   Loadbalancer ready.
> kubernetes-master/0*  activeidle   510.158.189.105
> 6443/tcp  Kubernetes master services ready.
>  * flannel/0*  error idle
> 10.158.189.105hook failed: "cni-relation-changed" for
> flannel:cni*
> kubernetes-worker/0   waiting   idle   6
> 10.158.189.132Waiting for kubelet to start.
>  * flannel/2   error idle
> 10.158.189.132hook failed: "etcd-relation-joined" for
> flannel:etcd*
> kubernetes-worker/1*  waiting   idle   7
> 10.158.189.37 Waiting for kubelet to start.
>  * flannel/1   error idle
> 10.158.189.37 hook failed: "etcd-relation-joined" for
> flannel:etcd*
> kubernetes-worker/2   waiting   idle   8
> 10.158.189.176Waiting for kubelet to start.
>  * flannel/3   error idle
> 10.158.189.176hook failed: "cni-relation-changed" for
> flannel:cni*
>
>
>
> --
> 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: Canonical Distribution of Kubernetes 1.5.1 is here

[Adam Stokes]

At least on the mobile site the install instructions are not properly
formatted (under getting started)

On Fri, Dec 16, 2016, 6:14 PM Jorge O. Castro  wrote:

> Hello everyone,
>
> I'm happy to announce that 1.5.1 is here, all charms have been pushed and
> it's ready to go. Please refer to this blog post for the lengthy changelog,
> enjoy!
>
>
> http://insights.ubuntu.com/2016/12/16/announcing-canonical-kubernetes-1-5-1/
>
> --
> Jorge Castro
> Canonical Ltd.
> http://ubuntu.com/cloud/kubernetes  - Pure
> upstream Kubernetes
> --
> 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: conjure-up Canonical Kubernetes in LXD

[Adam Stokes]

On Fri, Nov 18, 2016 at 3:49 AM Mark Shuttleworth  wrote:


Developers will love this, the ability to spin up k8s in multi-node mode
on a laptop is fantastic!

I wonder if it's worth providing a page of instructions for the sysctl
changes built-in to conjure-up?

Currently within the  UI the user is able to press 'r' and display the
spells readme which would have that information in there.


We should aim to have the thing we socialize be one command ("conjure-up
canonical-kubernetes") and not a URL to a page with instructions.
Ideally, conjure-up would be able to detect the status of the machine,
tell the user how to adjust, and block until these changes have been
actioned (or do them for the user with approval).

We've talked about this before and I've created an issue to track
https://github.com/conjure-up/conjure-up/issues/507 . Ultimately, we don't
want to have to make any modifications to the user's host system to get big
software deployed within localhost cloud type.

Either one of these suggestions is doable and I'll keep the bug updated
with what we come up with.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

conjure-up Canonical Kubernetes in LXD

[Adam Stokes]

Just pulled in changes to support deploying The Canonical Distribution of
Kubernetes on the localhost cloud type.

I've blogged about it here:

http://blog.astokes.org/conjure-up-canonical-kubernetes-under-lxd-today/

Please give it a shot deploy some workloads on it and let us know how it
goes.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Crashdump plugin

[Adam Stokes]

Nice, one thing you could do is tie this in with sosreport and just run
that against the machines. It already has support for juju, lxd, openstack,
etc.

https://github.com/sosreport/sos

And a list of all the plugins we support are here:
https://github.com/sosreport/sos/tree/master/sos/plugins

On Thu, Nov 3, 2016 at 10:39 PM Gregory Lutostanski <
gregory.lutostan...@canonical.com> wrote:

> Hey everybody...
>
> I cobbled together a new juju plugin "crashdump" and thought some of you
> might find it useful. I also took a stab at getting some packaging together
> for https://github.com/juju/plugins
>
> I use "juju crashdump" to get quick tarballs of broken deploys when in a
> bad state so I or someone else can check over them later without having to
> interactively poke the machines... Right now it should by default include
> all/most of the interesting logs for an OpenStack deployment, but I am very
> interested in making sure it works for any usecase...
>
> Anywho, it works with both the deb and snap version of juju (although in
> the later case you should invoke it with juju-crashdump till I get this all
> snapped up...)
>
> Give 'er a whirl:
> $ sudo add-apt-repository ppa:lutostag/juju-plugins && sudo apt update &&
> sudo apt install juju-plugins
> $ juju-crashdump -h
> usage: juju-crashdump [-h] [-d] [-m MODEL] [-f MAX_FILE_SIZE] [-b BUG]
>   [extra_dir [extra_dir ...]]
>
> positional arguments:
>   extra_dir Extra directories to snapshot
>
> optional arguments:
>   -h, --helpshow this help message and exit
>   -d, --description Output a short description of the plugin
>   -m MODEL, --model MODEL
> Model to act on
>   -f MAX_FILE_SIZE, --max-file-size MAX_FILE_SIZE
> The max file size (bytes) for included files
>   -b BUG, --bug BUG Upload crashdump to the given launchpad bug #
>
> This was just a first-pass, I know it needs a bit of polishing, but
> absolutely let me know if any of you guys & gals find this useful/think
> something should be added.
>
> Thanks and have fun!
> Greg Lutostanski
>
> --
> 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: lxd hook failed change-config

[Adam Stokes]

Heather,

A bug has been filed about this issue:
https://bugs.launchpad.net/charm-lxd/+bug/1635659

I've asked that it get top priority in order to have this fixed pushed into
the charmstore asap. I'll let you know once the updated charm is available
for deployment again.

Sorry for the inconvenience

On Thu, Oct 20, 2016 at 9:57 PM Heather Lanigan  wrote:

> I used conjure-up to deploy openstack-novalxd on a Xenial system.  Before
> deploying, the operating system was updated.  LXD init was setup with dir,
> not xfs.  All but one of the charms has a status of “unit is ready"
>
> The lxd/0 subordinate charm has a status of: hook failed:
> "config-changed”.  See details below.
>
> I can boot an instance within this OpenStack deployment.  However deleting
> the instance fails. A side effect of the lxd/0 issues?
>
> Juju version 2.0.0-xenial-amd64
> conjure-up version 2.0.2
> lxd charm version 2.0.5
>
> Any ideas?
>
> Thanks in advance,
> Heather
>
> ++
>
> The /var/log/juju/unit-lxd-0.log on the unit reports:
>
> 2016-10-21 01:09:33 INFO config-changed Traceback (most recent call last):
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 140, in
> 
> 2016-10-21 01:09:33 INFO config-changed main()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 134, in
> main
> 2016-10-21 01:09:33 INFO config-changed hooks.execute(sys.argv)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/hookenv.py",
> line 715, in execute
> 2016-10-21 01:09:33 INFO config-changed self._hooks[hook_name]()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 78, in
> config_changed
> 2016-10-21 01:09:33 INFO config-changed configure_lxd_host()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/decorators.py",
> line 40, in _retry_on_exception_inner_2
> 2016-10-21 01:09:33 INFO config-changed return f(*args, **kwargs)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/lxd_utils.py", line 429, in
> configure_lxd_host
> 2016-10-21 01:09:33 INFO config-changed with open(EXT4_USERNS_MOUNTS,
> 'w') as userns_mounts:
> 2016-10-21 01:09:33 INFO config-changed IOError: [Errno 30] Read-only file
> system: '/sys/module/ext4/parameters/userns_mounts'
> 2016-10-21 01:09:33 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "config-changed" failed: exit status 1
>
>
> root@juju-456efd-13:~# touch /sys/module/ext4/parameters/temp-file
> touch: cannot touch '/sys/module/ext4/parameters/temp-file': Read-only
> file system
> root@juju-456efd-13:~# df -h /sys/module/ext4/parameters/userns_mounts
> Filesystem  Size  Used Avail Use% Mounted on
> sys0 0 0- /dev/.lxc/sys
> root@juju-456efd-13:~# touch /home/ubuntu/temp-file
> root@juju-456efd-13:~# ls /home/ubuntu/temp-file
> /home/ubuntu/temp-file
> root@juju-456efd-13:~# df -h
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/mitaka--vg-root  165G   47G  110G  30% /
> none 492K 0  492K   0% /dev
> udev  16G 0   16G   0% /dev/fuse
> tmpfs 16G 0   16G   0% /dev/shm
> tmpfs 16G   49M   16G   1% /run
> tmpfs5.0M 0  5.0M   0% /run/lock
> tmpfs 16G 0   16G   0% /sys/fs/cgroup
> tmpfs3.2G 0  3.2G   0% /run/user/112
> tmpfs3.2G 0  3.2G   0% /run/user/1000
>
> +
>
> heather@mitaka:~$ nova boot --image d2eba22a-e1b1-4a2b-aa87-450ee9d9e492
> --flavor d --nic net-name=ubuntu-net --key-name keypair-admin
> xenial-instance
> heather@mitaka:~/goose-work/src/gopkg.in/goose.v1$ nova list
>
> +--+-+++-+---+
> | ID   | Name| Status | Task
> State | Power State | Networks  |
>
> +--+-+++-+---+
> | 80424b94-f24d-45ff-a330-7b67a911fbc6 | xenial-instance | ACTIVE | -
>  | Running | ubuntu-net=10.101.0.8 |
>
> +--+-+++-+---+
>
> heather@mitaka:~$ nova delete 80424b94-f24d-45ff-a330-7b67a911fbc6
> Request to delete server 80424b94-f24d-45ff-a330-7b67a911fbc6 has been
> accepted.
> heather@mitaka:~$ nova list
>
> 

Re: lxd hook failed change-config

[Adam Stokes]

This looks like it's due to the way we deploy OpenStack with NovaLXD in all
containers, this effectively breaks anyone wanting to do an all-in-one
install on their system.

On Fri, Oct 21, 2016 at 10:22 AM Adam Stokes <adam.sto...@canonical.com>
wrote:

> So it looks like a recent change to the LXD charm, see here:
>
>
> https://github.com/openstack/charm-lxd/commit/017246768e097c5fcd5283e23f19f075ff9f9d4e
>
> Chuck, are you aware of this issue?
>
> On Fri, Oct 21, 2016 at 10:19 AM Heather Lanigan <hmlani...@gmail.com>
> wrote:
>
> Adam,
>
> The entire container is not readonly.  Just /sys, the mount point for
> /dev/.lxc/sys.  I choose another charm (neutron-api) to look at, /sys on
> that unit is readonly as well.Is that normal?
>
> What would be different in my config?  My Xenial install is on a VM, but
> I’ve been running that way for weeks.  I did have the openstack-novalxd
> bundle successfully deployed on it previously using juju 2.0_rc1.
>
> -Heather
>
> On Oct 20, 2016, at 11:30 PM, Adam Stokes <adam.sto...@canonical.com>
> wrote:
>
> Odd it looks like the container has a read only file system? I ran through
> a full openstack-novalxd deployment today and one of the upstream
> maintainers ran through the same deployment and didn't run into any issues.
>
> On Thu, Oct 20, 2016, 10:02 PM Heather Lanigan <hmlani...@gmail.com>
> wrote:
>
>
> I used conjure-up to deploy openstack-novalxd on a Xenial system.  Before
> deploying, the operating system was updated.  LXD init was setup with dir,
> not xfs.  All but one of the charms has a status of “unit is ready"
>
> The lxd/0 subordinate charm has a status of: hook failed:
> "config-changed”.  See details below.
>
> I can boot an instance within this OpenStack deployment.  However deleting
> the instance fails. A side effect of the lxd/0 issues?
>
> Juju version 2.0.0-xenial-amd64
> conjure-up version 2.0.2
> lxd charm version 2.0.5
>
> Any ideas?
>
> Thanks in advance,
> Heather
>
> ++
>
> The /var/log/juju/unit-lxd-0.log on the unit reports:
>
> 2016-10-21 01:09:33 INFO config-changed Traceback (most recent call last):
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 140, in
> 
> 2016-10-21 01:09:33 INFO config-changed main()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 134, in
> main
> 2016-10-21 01:09:33 INFO config-changed hooks.execute(sys.argv)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/hookenv.py",
> line 715, in execute
> 2016-10-21 01:09:33 INFO config-changed self._hooks[hook_name]()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 78, in
> config_changed
> 2016-10-21 01:09:33 INFO config-changed configure_lxd_host()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/decorators.py",
> line 40, in _retry_on_exception_inner_2
> 2016-10-21 01:09:33 INFO config-changed return f(*args, **kwargs)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/lxd_utils.py", line 429, in
> configure_lxd_host
> 2016-10-21 01:09:33 INFO config-changed with open(EXT4_USERNS_MOUNTS,
> 'w') as userns_mounts:
> 2016-10-21 01:09:33 INFO config-changed IOError: [Errno 30] Read-only file
> system: '/sys/module/ext4/parameters/userns_mounts'
> 2016-10-21 01:09:33 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "config-changed" failed: exit status 1
>
>
> root@juju-456efd-13:~# touch /sys/module/ext4/parameters/temp-file
> touch: cannot touch '/sys/module/ext4/parameters/temp-file': Read-only
> file system
> root@juju-456efd-13:~# df -h /sys/module/ext4/parameters/userns_mounts
> Filesystem  Size  Used Avail Use% Mounted on
> sys0 0 0- /dev/.lxc/sys
> root@juju-456efd-13:~# touch /home/ubuntu/temp-file
> root@juju-456efd-13:~# ls /home/ubuntu/temp-file
> /home/ubuntu/temp-file
> root@juju-456efd-13:~# df -h
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/mitaka--vg-root  165G   47G  110G  30% /
> none 492K 0  492K   0% /dev
> udev  16G 0   16G   0% /dev/fuse
> tmpfs 16G 0   16G   0% /dev/shm
> tmpfs 16G   49M   16G   1% /run
> tmpfs 

Re: lxd hook failed change-config

[Adam Stokes]

So it looks like a recent change to the LXD charm, see here:

https://github.com/openstack/charm-lxd/commit/017246768e097c5fcd5283e23f19f075ff9f9d4e

Chuck, are you aware of this issue?

On Fri, Oct 21, 2016 at 10:19 AM Heather Lanigan <hmlani...@gmail.com>
wrote:

> Adam,
>
> The entire container is not readonly.  Just /sys, the mount point for
> /dev/.lxc/sys.  I choose another charm (neutron-api) to look at, /sys on
> that unit is readonly as well.Is that normal?
>
> What would be different in my config?  My Xenial install is on a VM, but
> I’ve been running that way for weeks.  I did have the openstack-novalxd
> bundle successfully deployed on it previously using juju 2.0_rc1.
>
> -Heather
>
> On Oct 20, 2016, at 11:30 PM, Adam Stokes <adam.sto...@canonical.com>
> wrote:
>
> Odd it looks like the container has a read only file system? I ran through
> a full openstack-novalxd deployment today and one of the upstream
> maintainers ran through the same deployment and didn't run into any issues.
>
> On Thu, Oct 20, 2016, 10:02 PM Heather Lanigan <hmlani...@gmail.com>
> wrote:
>
>
> I used conjure-up to deploy openstack-novalxd on a Xenial system.  Before
> deploying, the operating system was updated.  LXD init was setup with dir,
> not xfs.  All but one of the charms has a status of “unit is ready"
>
> The lxd/0 subordinate charm has a status of: hook failed:
> "config-changed”.  See details below.
>
> I can boot an instance within this OpenStack deployment.  However deleting
> the instance fails. A side effect of the lxd/0 issues?
>
> Juju version 2.0.0-xenial-amd64
> conjure-up version 2.0.2
> lxd charm version 2.0.5
>
> Any ideas?
>
> Thanks in advance,
> Heather
>
> ++
>
> The /var/log/juju/unit-lxd-0.log on the unit reports:
>
> 2016-10-21 01:09:33 INFO config-changed Traceback (most recent call last):
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 140, in
> 
> 2016-10-21 01:09:33 INFO config-changed main()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 134, in
> main
> 2016-10-21 01:09:33 INFO config-changed hooks.execute(sys.argv)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/hookenv.py",
> line 715, in execute
> 2016-10-21 01:09:33 INFO config-changed self._hooks[hook_name]()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 78, in
> config_changed
> 2016-10-21 01:09:33 INFO config-changed configure_lxd_host()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/decorators.py",
> line 40, in _retry_on_exception_inner_2
> 2016-10-21 01:09:33 INFO config-changed return f(*args, **kwargs)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/lxd_utils.py", line 429, in
> configure_lxd_host
> 2016-10-21 01:09:33 INFO config-changed with open(EXT4_USERNS_MOUNTS,
> 'w') as userns_mounts:
> 2016-10-21 01:09:33 INFO config-changed IOError: [Errno 30] Read-only file
> system: '/sys/module/ext4/parameters/userns_mounts'
> 2016-10-21 01:09:33 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "config-changed" failed: exit status 1
>
>
> root@juju-456efd-13:~# touch /sys/module/ext4/parameters/temp-file
> touch: cannot touch '/sys/module/ext4/parameters/temp-file': Read-only
> file system
> root@juju-456efd-13:~# df -h /sys/module/ext4/parameters/userns_mounts
> Filesystem  Size  Used Avail Use% Mounted on
> sys0 0 0- /dev/.lxc/sys
> root@juju-456efd-13:~# touch /home/ubuntu/temp-file
> root@juju-456efd-13:~# ls /home/ubuntu/temp-file
> /home/ubuntu/temp-file
> root@juju-456efd-13:~# df -h
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/mitaka--vg-root  165G   47G  110G  30% /
> none 492K 0  492K   0% /dev
> udev  16G 0   16G   0% /dev/fuse
> tmpfs 16G 0   16G   0% /dev/shm
> tmpfs 16G   49M   16G   1% /run
> tmpfs5.0M 0  5.0M   0% /run/lock
> tmpfs 16G 0   16G   0% /sys/fs/cgroup
> tmpfs3.2G 0  3.2G   0% /run/user/112
> tmpfs3.2G 0  3.2G   0% /run/user/1000
>

Re: lxd hook failed change-config

[Adam Stokes]

Odd it looks like the container has a read only file system? I ran through
a full openstack-novalxd deployment today and one of the upstream
maintainers ran through the same deployment and didn't run into any issues.

On Thu, Oct 20, 2016, 10:02 PM Heather Lanigan  wrote:

>
> I used conjure-up to deploy openstack-novalxd on a Xenial system.  Before
> deploying, the operating system was updated.  LXD init was setup with dir,
> not xfs.  All but one of the charms has a status of “unit is ready"
>
> The lxd/0 subordinate charm has a status of: hook failed:
> "config-changed”.  See details below.
>
> I can boot an instance within this OpenStack deployment.  However deleting
> the instance fails. A side effect of the lxd/0 issues?
>
> Juju version 2.0.0-xenial-amd64
> conjure-up version 2.0.2
> lxd charm version 2.0.5
>
> Any ideas?
>
> Thanks in advance,
> Heather
>
> ++
>
> The /var/log/juju/unit-lxd-0.log on the unit reports:
>
> 2016-10-21 01:09:33 INFO config-changed Traceback (most recent call last):
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 140, in
> 
> 2016-10-21 01:09:33 INFO config-changed main()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 134, in
> main
> 2016-10-21 01:09:33 INFO config-changed hooks.execute(sys.argv)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/hookenv.py",
> line 715, in execute
> 2016-10-21 01:09:33 INFO config-changed self._hooks[hook_name]()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/config-changed", line 78, in
> config_changed
> 2016-10-21 01:09:33 INFO config-changed configure_lxd_host()
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/charmhelpers/core/decorators.py",
> line 40, in _retry_on_exception_inner_2
> 2016-10-21 01:09:33 INFO config-changed return f(*args, **kwargs)
> 2016-10-21 01:09:33 INFO config-changed   File
> "/var/lib/juju/agents/unit-lxd-0/charm/hooks/lxd_utils.py", line 429, in
> configure_lxd_host
> 2016-10-21 01:09:33 INFO config-changed with open(EXT4_USERNS_MOUNTS,
> 'w') as userns_mounts:
> 2016-10-21 01:09:33 INFO config-changed IOError: [Errno 30] Read-only file
> system: '/sys/module/ext4/parameters/userns_mounts'
> 2016-10-21 01:09:33 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "config-changed" failed: exit status 1
>
>
> root@juju-456efd-13:~# touch /sys/module/ext4/parameters/temp-file
> touch: cannot touch '/sys/module/ext4/parameters/temp-file': Read-only
> file system
> root@juju-456efd-13:~# df -h /sys/module/ext4/parameters/userns_mounts
> Filesystem  Size  Used Avail Use% Mounted on
> sys0 0 0- /dev/.lxc/sys
> root@juju-456efd-13:~# touch /home/ubuntu/temp-file
> root@juju-456efd-13:~# ls /home/ubuntu/temp-file
> /home/ubuntu/temp-file
> root@juju-456efd-13:~# df -h
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/mitaka--vg-root  165G   47G  110G  30% /
> none 492K 0  492K   0% /dev
> udev  16G 0   16G   0% /dev/fuse
> tmpfs 16G 0   16G   0% /dev/shm
> tmpfs 16G   49M   16G   1% /run
> tmpfs5.0M 0  5.0M   0% /run/lock
> tmpfs 16G 0   16G   0% /sys/fs/cgroup
> tmpfs3.2G 0  3.2G   0% /run/user/112
> tmpfs3.2G 0  3.2G   0% /run/user/1000
>
> +
>
> heather@mitaka:~$ nova boot --image d2eba22a-e1b1-4a2b-aa87-450ee9d9e492
> --flavor d --nic net-name=ubuntu-net --key-name keypair-admin
> xenial-instance
> heather@mitaka:~/goose-work/src/gopkg.in/goose.v1$ nova list
>
> +--+-+++-+---+
> | ID   | Name| Status | Task
> State | Power State | Networks  |
>
> +--+-+++-+---+
> | 80424b94-f24d-45ff-a330-7b67a911fbc6 | xenial-instance | ACTIVE | -
>  | Running | ubuntu-net=10.101.0.8 |
>
> +--+-+++-+---+
>
> heather@mitaka:~$ nova delete 80424b94-f24d-45ff-a330-7b67a911fbc6
> Request to delete server 80424b94-f24d-45ff-a330-7b67a911fbc6 has been
> accepted.
> heather@mitaka:~$ nova list
>
> +--+-+++-+--+
> | ID   | Name| 

Re: [ANN] Mattermost and layer:lets-encrypt

[Adam Stokes]

This is very awesome!

On Sat, Oct 15, 2016, 12:07 PM Casey Marshall 
wrote:

> With a much appreciated recent contribution from James Beedy (bdx) our
> Mattermost charm cs:~cmars/mattermost[1] is working again!
>
> This encouraged me to add some followup improvements to the charm to make
> it even easier to deploy with secure defaults -- automatic registration
> with Let's Encrypt.
>
> I've broken out the Let's Encrypt integration to a separate reactive charm
> layer, layer:lets-encrypt[2], which extends layer:nginx. Practically any
> charm that uses layer:nginx should be able to use layer:lets-encrypt. When
> a config option `fqdn` is set, the layer will automatically register with
> LE and obtain certificates.
>
> With the epic release of Juju 2.0 this past week -- the Mattermost charm
> depends on several features new in Juju 2 -- it's now ready to share.
>
> I'm operating a deployment of cs:~cmars/mattermost at
> https://live.cmars.tech/. If you'd like to try it out, here's an invite:
> https://live.cmars.tech/signup_user_complete/?id=wccpdu6dqp88mjkqbngnws6ohc
>
> -Casey
>
> [1] https://jujucharms.com/u/cmars/mattermost
> https://github.com/cmars/juju-charm-mattermost
> [2] https://github.com/cmars/layer-lets-encrypt
> --
> 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: Canonical Distribution of Kubernetes - Update Release Notes (16.10 cycle)

[Adam Stokes]

Nice! One question though maybe I'm missing something but I didn't see
where the conjure-up instructions were shown on the jujucharms.com page?
https://jujucharms.com/canonical-kubernetes/ It is in the README though
https://github.com/juju-solutions/bundle-canonical-kubernetes/blob/master/README.md#interactive-deployment-using-conjure-up
so
I'm not sure if it's a caching issue or not?

On Thu, Oct 6, 2016 at 8:07 PM Charles Butler 
wrote:

> @mbruzek and I worked on the Canonical Distribution of Kubernetes this
> week. There are still quite a few work items in flight, but let’s focus on
> what made the early release today:
>
> Kubernetes Master
>
>
>-
>
>Normalized the end user messaging displayed during cluster operations
>(full stops, grammar).
>-
>
>Added more debug logging output making it clearer to trace problems as
>to the order of what was happening.
>
>
> Kubernetes Worker
>
>
>-
>
>Fixed status message so “Kubelet waiting to start” is not the last
>message.
>-
>
>Added debug logging output making it clearer to trace problems as to
>the order of what was happening.
>-
>
>Adjusted the kubelet systemd template to kill process-groups vs
>‘parent process’ which was orphaning inotify threads, exhausting the system
>of open files. (thanks @cynerva and @ryebot)
>-
>
>Removed the SDN Logic from the top most kubernetes-worker layer, into
>the layer-docker to ensure encapsulation.
>-
>
>Used ‘data_changed’ to prevent excessive restarts of the kubelet and
>kube-proxy processes.
>
>
>
> Flannel
>
>
>-
>
>Fixed a failing operation in flannel when it was attempting to remove
>files that had already been deleted.
>
>
>
> CDK Bundle
>
>
>-
>
>Updated the version the changed charms to their latest stable
>beta-releases.
>- Updated the Conjure-Up section in the README (thanks @mmc)
>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your application | www.jujucharms.com
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju @ conjure-up on Power8 , Free Trial on SoftLayer

[Adam Stokes]

Conjure-up is Juju 2.0, MAAS 2.0, and Xenial only.  You will need to use
the previous openstack-installer if on trusty.  Also if KVM is not
supported on power you'll need to use a different virt-type for
nova-compute.

On Mon, Aug 8, 2016, 6:23 AM John Meinel  wrote:

> I don't know if conjure-up supports Juju 1.0. In 1.0 the setting was in
> environments.yaml as 'default-series'. So something like:
>
> environments:
>   power8:
> type: ?
> default-series: trusty
>
> My memory is a bit hazy there, but that's roughly what I remember.
>
> John
> =:->
>
>
> On Mon, Aug 8, 2016 at 12:34 PM, Khairul Aizat Kamarudzzaman <
> fen...@ubuntu.com> wrote:
>
>> Thanks John for the advise.
>>
>> fenris@bigsoftware:~$ juju --version
>> 1.25.5-trusty-ppc64el
>> fenris@bigsoftware:~$ juju bootstrap --bootstrap-series=trusty
>> error: flag provided but not defined: --bootstrap-series
>>
>> On Mon, Aug 8, 2016 at 1:59 PM, John Meinel 
>> wrote:
>>
>>> You need Xenial if you want to use MAAS 2.0, but Juju can deploy to
>>> Trusty just fine. I'm not sure about kvm_intel, but you can do "juju
>>> bootstrap --bootstrap-series=trusty" to get a Trusty Controller, and then
>>> 'juju deploy --series trusty APP" to select a Trusty series there as well.
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Mon, Aug 8, 2016 at 7:35 AM, Khairul Aizat Kamarudzzaman <
>>> fen...@ubuntu.com> wrote:
>>>
 Hi,
 I've tried and its not possible to run conjure-up and container to
 deploy big software on Power8 Softlayer as current the hardware doesn't
 supported Xenial Xerus yet.

 event the kernel itself doesn't support kvm_intel module. Appreciate if
 someone can advise me how can I fully utilize the trial period and give
 feedback to improve for future Ubuntu support on Power8


 Thanks & Regards,
 Khairul Aizat Kamarudzzaman

 --
 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: Layer-Supervisor

[Adam Stokes]

looks good, one small nit pick, maybe change supervisorlib.py to just
supervisor.py. that seems to be the current naming scheme of things

On Thu, Jul 21, 2016 at 1:42 PM, James Beedy  wrote:

> A big thanks to those of you who gave feedback! I have made some revisions
> based on the suggestions I received from a few of you (thank you!), and
> would like to get a second round of feedback now the modifications  have
> been made -> [layer-supervisor](
> https://github.com/jamesbeedy/layer-supervisor).
>
> Thanks all!
>
> --
> 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: Layer-Supervisor

[Adam Stokes]

One thing (which I haven't done yet in some of my layers) is to place your
supervisorlib in `lib/charms/layer`. A nice first start though!

On Thu, Jul 21, 2016 at 4:39 AM, Stuart Bishop 
wrote:

> On 21 July 2016 at 10:40, James Beedy  wrote:
>
> > I'll take all the input/feedback/criticism I can get on this - thanks!
>
> Under Multi Application Support, the example references myapp1_ctxt
> and myapp2_ctxt variables but they are both undefined and there is no
> mention on what they are supposed to contain.
>
> From a charming perspective, I'm interested in if I should be using
> Supervisor or systemd to control my applications. If you want uptake,
> a simple Python API for generating simple templates is preferable to
> expecting us to read the Supervisor documentation and learn its
> configuration syntax ;)
>
> I think you want a wheelhouse.txt listing supervisor in your layer, so
> the dependency gets pulled in at 'charm build' time, or the Ubuntu
> package listed in layer.yaml under options->basic->packages. I don't
> see anywhere in the layer that is installing the dependency.
>
> --
> 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: grabbing resources when deploying via api Application.Deploy

[Adam Stokes]

There is also a open bug about the inconsistency between the 'resources'
facade and all other facades

https://launchpad.net/bugs/1597519

On Wed, Jun 29, 2016 at 4:56 PM, Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

>
> So just to follow up on our conversation in IRC:
>
> - You do need to upload resource metadata prior to deploying a charm. You
> can do so via the "resources" facade, version 1. Call "AddPendingResources".
> - This will give you a list of IDs back; associate these in a map of
> resource-name -> id, and include those in the deploy request.
>
> Hope this helps anyone else trying to use the resources feature
> programatically.
>
> Adam Stokes <adam.sto...@canonical.com> writes:
>
> > I've noticed a difference between calling:
> >
> > juju deploy cs:~containers/trusty/etcd-3
> >
> > And using the API:
> >
> > Application.Deploy({'applications': [{'constraints': {},
> > 'application': 'etcd', 'num-units': 3, 'charm-url':
> > 'cs:~containers/trusty/etcd-3'}]})
> >
> > Using the juju client it'll automatically pull down the resources
> > associated with it in the charmstore. Using the API call will not.
> >
> > Question is if this is intended? Do I need to pass something to my
> > Deploy call to grab those resources as well?
>
> --
> Katherine
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Conjure-up, an Introduction

[Adam Stokes]

Hi all,

We've recently released the next version of conjure-up. If you are not
familiar with conjure-up and how it can make your life that much more
productive please have a look at this blog post:

https://insights.ubuntu.com/2016/06/09/conjure-up-an-introduction/

We will be on a weekly release schedule until a GA release so now is the
perfect time to get involved and file bugs to help make this product the
go-to tool for deploying any and all big software. :)

Thanks,
Ubuntu Solutions Engineering Team
Adam Stokes, Mike McCracken, Daniel Westervelt
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

where is upstream code for charms displayed?

[Adam Stokes]

For whatever reason I'm having a difficult time figuring out where the
upstream source code is for a charm that I wish to contribute to.

For example, going here: https://jujucharms.com/elasticsearch/trusty/15

What should I be looking for or clicking on that'll take me to a place
where I can begin getting involved with that project? (This should also be
viewed from a perspective where someone is not familiar with Launchpad.)

Also, where's the Code link under the file list heading?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Bash completion

[Adam Stokes]

It looks like it still doesn't work, running

juju version
2.0-beta8.4022-xenial-amd64

I'm unable to juju to get a list of subcommands

On Mon, Jun 6, 2016 at 11:59 AM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Beta8 contains what I hope are some fixes for bash completion. It should
> complete properly for 'juju', whether /usr/bin/juju is pointed at juju2 or
> juju1. That solves bug #1 below I hope; #2 and #3 still need work. Comments
> appreciated!
>
> Nicholas
>
>
> On 06/02/2016 11:28 AM, Martin Packman wrote:
>
>> Hi all,
>>
>> We need someone who cares about bash completion to step up and make
>> sure it works well for juju 2.0. There are several reported issues and
>> changes needed:
>>
>> 1) Bash completion sometimes? doesn't work at all
>> 
>>
>> If you can reproduce this, please try adding 'set -x' to the top of
>> /usr/share/bash-completion/completions/juju2 and completing again, and
>> see if the output spam is enlightening. Add details to the bug.
>>
>> 2) Update to completion script
>> 
>>
>> JuanJo proposed some updates a while back, but the branch needs
>> picking up and finishing off. This is also a prerequisite for...
>>
>> 3) Bash completion for versioned juju commands
>> 
>>
>> When we're installing version-numbered aliases for juju, those should
>> also have completion scripts.
>>
>> Thanks,
>>
>> Martin
>>
>>
>
> --
> 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: rabbitmq-server hook "config-changed" failed (dns resolver)

[Adam Stokes]

I believe he's using the LXD provider, here is the status output:

https://paste.ubuntu.com/16640152/

He's running into this issue:

https://bugs.launchpad.net/juju-core/+bug/1574844

According to the bug a fix is in process and should hopefully make it into
beta8



On Mon, May 23, 2016 at 4:31 PM, James Page  wrote:

> Hi Khairul
>
> On Mon, 23 May 2016 at 21:00 Mark Shuttleworth  wrote:
>
>> Hi Khairul
>>
>> Thanks for the mail, let's see if Adam cc'd has any insight to share with
>> the list.
>>
>>
>> Mark
>>
>>
>> On 23/05/16 22:38, Khairul Aizat Kamarudzzaman wrote:
>>
>> Hi all,
>> Im getting error while running conjure-up openstack on xenial
>>
>> i've file a bug  
>> https://bugs.launchpad.net/bugs/1584582
>>
>> Appreciate if charmers can help me with this since im preparing demo
>> server for event  http://www.mosc.my this week ...
>>
>> if cant solve the bug, at least work around how to make it temp fixed and
>> other charms in the bundle can resume the adding the relationship.
>>
>>
> RabbitMQ is particularly sensitive to DNS misconfiguration - full forward
> and reverse hostname lookup are essential for erlang not to get confused;
>  with provider are you seeing this issue with?  if its MAAS, which version
> of MAAS?
>
>
>
> --
> 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: Introducing a Daily PPA for Juju

[Adam Stokes]

Also can we purge some of those PPA's that aren't being used any longer?
The list is pretty confusing as to which ppa should be used:

This is the current list of ppa's under Juju namespace:


0.5 Stable
0.6 Stable
1.22 Updates
1.22 Proposed
1.23 Updates
Juju Daily
juju devel packages
Juju Enablement
juju experimental packages
juju-golang
juju packages
juju proposed packages
juju stable packages
Juju Staging


On Thu, May 12, 2016 at 5:15 PM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> Nice but this version is a bit crazy:
>
> 2.0-beta7~20160512~3966~0bd48e6f-20160512+3966+0bd48e6f~16.04
>
> Maybe just drop -20160512+3966+0bd48e6f as it seems to be repetative
>
> On Thu, May 12, 2016 at 4:39 PM, Ryan Beisner <ryan.beis...@canonical.com>
> wrote:
>
>> Absolutely <3 this.
>>
>> On Thu, May 12, 2016 at 3:36 PM, Nicholas Skaggs <
>> nicholas.ska...@canonical.com> wrote:
>>
>>> Whether you want to track Juju development more closely, or simply like
>>> living on the edge, there is a new ppa available for you. Dubbed the Juju
>>> Daily ppa[1], it] contains the latest blessed builds from CI testing.
>>> Installing this ppa and upgrading regularly allows you to stay in sync with
>>> the absolute latest version of Juju that passes our CI testing. New
>>> packages are copied as soon as a blessed build is complete. This can occur
>>> multiple times a day should every build pass, or it may be several days
>>> between builds should new revisions contain failures.
>>>
>>>
>>> The Juju QA team don’t recommend running this ppa for production or
>>> critical system usage, but we are happy to hear about bugs[2] you may
>>> encounter while running these versions of Juju. To add the ppa, you will
>>> need to add ppa:juju/daily to your software sources.
>>>
>>>
>>> sudo add-apt-repository ppa:juju/daily
>>>
>>>
>>> Do be aware that adding this ppa will upgrade any version of Juju you
>>> may have installed. Also note this ppa contains builds without published
>>> streams, so you will need to generate or acquire streams on your own. For
>>> most users, this means you should pass --upload-tools during the bootstrap
>>> process. However you may also pass the agent-metadata-url and agent-stream
>>> as config options. See the ppa description and simplestreams documentation
>>> for more details[3].
>>>
>>>
>>> Finally, should you wish to revert to a stable version of Juju, you can
>>> use the ppa-purge tool[4] to remove the daily ppa and the installed version
>>> of Juju.
>>>
>>>
>>> We hope this proves useful to you, feedback welcome!
>>>
>>>
>>>
>>> Nicholas
>>>
>>> 1.
>>>
>>>https://launchpad.net/~Juju/+archive/ubuntu/daily
>>><https://launchpad.net/%7Ejuju/+archive/ubuntu/daily>
>>>
>>> 2.
>>>
>>>https://bugs.launchpad.net/juju-core/+filebug
>>>
>>> 3.
>>>
>>>
>>> https://github.com/juju/juju/blob/master/doc/simplestreams-metadata.txt
>>>
>>> 4.
>>>
>>>http://askubuntu.com/a/310
>>>
>>>
>>> --
>>> 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: Introducing a Daily PPA for Juju

[Adam Stokes]

Nice but this version is a bit crazy:

2.0-beta7~20160512~3966~0bd48e6f-20160512+3966+0bd48e6f~16.04

Maybe just drop -20160512+3966+0bd48e6f as it seems to be repetative

On Thu, May 12, 2016 at 4:39 PM, Ryan Beisner 
wrote:

> Absolutely <3 this.
>
> On Thu, May 12, 2016 at 3:36 PM, Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> Whether you want to track Juju development more closely, or simply like
>> living on the edge, there is a new ppa available for you. Dubbed the Juju
>> Daily ppa[1], it] contains the latest blessed builds from CI testing.
>> Installing this ppa and upgrading regularly allows you to stay in sync with
>> the absolute latest version of Juju that passes our CI testing. New
>> packages are copied as soon as a blessed build is complete. This can occur
>> multiple times a day should every build pass, or it may be several days
>> between builds should new revisions contain failures.
>>
>>
>> The Juju QA team don’t recommend running this ppa for production or
>> critical system usage, but we are happy to hear about bugs[2] you may
>> encounter while running these versions of Juju. To add the ppa, you will
>> need to add ppa:juju/daily to your software sources.
>>
>>
>> sudo add-apt-repository ppa:juju/daily
>>
>>
>> Do be aware that adding this ppa will upgrade any version of Juju you may
>> have installed. Also note this ppa contains builds without published
>> streams, so you will need to generate or acquire streams on your own. For
>> most users, this means you should pass --upload-tools during the bootstrap
>> process. However you may also pass the agent-metadata-url and agent-stream
>> as config options. See the ppa description and simplestreams documentation
>> for more details[3].
>>
>>
>> Finally, should you wish to revert to a stable version of Juju, you can
>> use the ppa-purge tool[4] to remove the daily ppa and the installed version
>> of Juju.
>>
>>
>> We hope this proves useful to you, feedback welcome!
>>
>>
>>
>> Nicholas
>>
>> 1.
>>
>>https://launchpad.net/~Juju/+archive/ubuntu/daily
>>
>>
>> 2.
>>
>>https://bugs.launchpad.net/juju-core/+filebug
>>
>> 3.
>>
>>
>> https://github.com/juju/juju/blob/master/doc/simplestreams-metadata.txt
>>
>> 4.
>>
>>http://askubuntu.com/a/310
>>
>>
>> --
>> 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: Status of cs:xenial/ceph-0 and cs:xenial/ceph-osd-0

[Adam Stokes]

Yea I was able to deploy ceph-osd using Juju 2 on Xenial. One thing to note
is I think the actual ceph charm is being phased out and you'll want to
deploy both ceph-osd and ceph-mon instead.

On Sat, May 7, 2016 at 2:34 PM, James Beedy <jamesbe...@gmail.com> wrote:

> Adam,
>
> Does `juju deploy cs:xenial/ceph-osd-0` succeed for you?
>
> On Sat, May 7, 2016 at 11:52 AM, ed bond <celpa.f...@gmail.com> wrote:
>
>> We tried for a week to get some bundles working with xenial-mitaka and
>> were having issues all over the place. Created some bugs, however was using
>> juju 1.25.
>>
>> On May 7, 2016, at 12:57 PM, Adam Stokes <adam.sto...@canonical.com>
>> wrote:
>>
>> We've been using it with conjure-up and it works well for us.
>>
>> On Sat, May 7, 2016, 1:56 PM James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> I have been testing out cs:xenial/ceph-0, and cs:xenial/ceph-osd-0, with
>>> no luck of getting either to deploy without error. Does anyone know the
>>> status of these charms?
>>> --
>>> 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: Status of cs:xenial/ceph-0 and cs:xenial/ceph-osd-0

[Adam Stokes]

We've been using it with conjure-up and it works well for us.

On Sat, May 7, 2016, 1:56 PM James Beedy  wrote:

> I have been testing out cs:xenial/ceph-0, and cs:xenial/ceph-osd-0, with
> no luck of getting either to deploy without error. Does anyone know the
> status of these charms?
> --
> 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: 16.04 OpenStack charm release

[Adam Stokes]

I'll update the getting started requirements to include the following
(geared towards laptops):

- Use of SSD throughout
- 16G RAM
- 4x CPU
- Swap double size of RAM
- and to make use of ZFS on a separate SSD block device and recommend a
size of 100G.


On Sat, Apr 23, 2016 at 11:42 AM, Dustin Kirkland <kirkl...@canonical.com>
wrote:

> On Sat, Apr 23, 2016 at 10:25 AM, Mark Shuttleworth <m...@ubuntu.com>
> wrote:
> > On 23/04/16 09:35, Adam Stokes wrote:
> >> I don't think it's a hard rule it is just the hardware I have at the
> >> time. I'm fixing a few things today and will test on my laptop's once
> >> I upgrade them to xenial. I can update that section of the site once I
> >> figure out the minimal requirements
> >>
> >
> > I think RAM is much more likely to be critical than cores. We should
> > also advise the use of an SSD because IO is a big bottleneck when you
> > are firing up many containers at the same time.
>
> Sorry, my last note got blocked to the list as I sent from my phone
>
> Here's some real data, from an actively deployed and running
> conjure-up openstack instance...
>
> - I have conjure-up working with 16GB of memory, though I'm pretty
> heavily pegged (79% used), so I'd recommend some swap space in
> addition (I used 32GB, which is 16% used).
>
> - I have conjure-up working on a Thinkpad laptop, with 2xi7 cores
> (hyperthreaded to 4 effective cores).  I've pegged the CPU frequency
> at max (2.9GHz).  Idling now, I'm running at 1.32 system load (33% cpu
> usage).  There are over 1191 active processes running, across the host
> OS and 16 LXD containers.
>
> - I have conjure-up working with SSD storage.  A small root filesystem
> (20GB is plenty sufficient, and uses 4.8GB for all of my Ubuntu 16.04
> LTS desktop).  I used a healthily sized zpool with an SSD backed block
> device (100GB allocated, 25.1GB used).
>
> Hopefully this helps.
>
> Dustin
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 16.04 OpenStack charm release

[Adam Stokes]

I don't think it's a hard rule it is just the hardware I have at the time.
I'm fixing a few things today and will test on my laptop's once I upgrade
them to xenial. I can update that section of the site once I figure out the
minimal requirements

On Sat, Apr 23, 2016, 10:31 AM Mark Baker <mark.ba...@canonical.com> wrote:

> In the "Get Started" section it states:
>
> "For localhost deployments utilizing Juju's LXD provider you will need at
> least a system with 8 CPUs and 8G RAM."
>
> Is this really 8 processors or is it cores? Even 8 cores seems excessive
> and will rule out many developer laptops.
>
>
>
> Best Regards
>
>
>
> Mark Baker
> On Sat, Apr 23, 2016 at 9:17 AM, Mark Shuttleworth <m...@ubuntu.com>
> wrote:
>
>> On 23/04/16 09:10, Adam Stokes wrote:
>>
>> Also we have conjure-up.io up and running as well.
>>
>>
>> Love it! This makes it really easy to add a deb package to Ubuntu that
>> wraps any Juju bundle.
>>
>> Mark
>>
>> --
>> Cloud mailing list
>> cl...@lists.canonical.com
>> Modify settings or unsubscribe at:
>> https://lists.canonical.com/mailman/listinfo/cloud
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 16.04 OpenStack charm release

[Adam Stokes]

Also we have conjure-up.io up and running as well.

On Sat, Apr 23, 2016, 10:09 AM Adam Stokes <adam.sto...@canonical.com>
wrote:

> We are currently working a few kinks out to have a fully turnkey solution
> for Nova LXD. The option already exist but there are a few rough spots that
> we are fixing today.
>
> On Sat, Apr 23, 2016, 10:07 AM Mark Shuttleworth <m...@ubuntu.com> wrote:
>
>>
>> Perhaps the best way to test these is with the new "conjure-up
>> openstack" tool in Xenial. It needs a bit of beta testing (it is
>> exercising Juju 2.0 beta as well as LXD 2.0 quite hard!) so please bang
>> on it and file bugs as needed.
>>
>> conjure-up is a nice thin layer on top of bundles, that basically lets
>> you make a walk-through of a bundle deployment with some wiggle-room for
>> placement and scale. If you have a bundle of a large topology, you can
>> thus conjure-up that bundle, giving your users the ability to use it on
>> LXD or on MAAS or on KVM. So in the openstack example it's a nice way to
>> spin up a micro-openstack on your laptop with LXD and KVM, or a
>> macro-openstack on MAAS, walking through each of the components in the
>> bundle one by one.
>>
>> Mark
>>
>> --
>> Cloud mailing list
>> cl...@lists.canonical.com
>> Modify settings or unsubscribe at:
>> https://lists.canonical.com/mailman/listinfo/cloud
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 16.04 OpenStack charm release

[Adam Stokes]

We are currently working a few kinks out to have a fully turnkey solution
for Nova LXD. The option already exist but there are a few rough spots that
we are fixing today.

On Sat, Apr 23, 2016, 10:07 AM Mark Shuttleworth  wrote:

>
> Perhaps the best way to test these is with the new "conjure-up
> openstack" tool in Xenial. It needs a bit of beta testing (it is
> exercising Juju 2.0 beta as well as LXD 2.0 quite hard!) so please bang
> on it and file bugs as needed.
>
> conjure-up is a nice thin layer on top of bundles, that basically lets
> you make a walk-through of a bundle deployment with some wiggle-room for
> placement and scale. If you have a bundle of a large topology, you can
> thus conjure-up that bundle, giving your users the ability to use it on
> LXD or on MAAS or on KVM. So in the openstack example it's a nice way to
> spin up a micro-openstack on your laptop with LXD and KVM, or a
> macro-openstack on MAAS, walking through each of the components in the
> bundle one by one.
>
> Mark
>
> --
> Cloud mailing list
> cl...@lists.canonical.com
> Modify settings or unsubscribe at:
> https://lists.canonical.com/mailman/listinfo/cloud
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju 2.0 beta3 push this week

[Adam Stokes]

Hi!

Could I get this bug added to the list too?

https://bugs.launchpad.net/juju-core/+bug/1554721

On Thu, Mar 17, 2016 at 2:51 PM, Rick Harding 
wrote:

>
>
> tl;dr
> Juju 2.0 beta3 will not be out this week.
>
> The team is fighting a backlog of getting work landed. Rather than get the
> partial release out this week with the handful of current features and
> adding to the backlog while getting that beta release out, the decision was
> made to focus on getting the current work that’s ready landed. This will
> help us get our features in before the freeze exception deadline of the
> 23rd.
>
> We have several new things currently in trunk (such as enhanced support
> for MAAS spaces, machine provisioning status monitoring, Juju GUI embedded
> CLI commands into Juju Core), but we have important things to get landed.
> These include:
>
> - Updating controller model to be called “admin” and a “default” initial
> working model on bootstrap that’s safely removable
> - Minimum Juju version support for charms
> - juju read-only mode
> - additional resources work with version numbers and bundles support
> - additional work in the clouds and credentials management work
> - juju add-user and juju register to sign in the new user
>
> The teams will work together and focus on landing these and we’ll get a
> beta with the full set of updates for everyone to try out next week. If you
> have any questions or concerns, please let me know.
>
> Thanks
>
> Rick
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Issue with (some) layered charms in network-restricted envs

[Adam Stokes]

Not sure if this would help, but, I recently came across this
https://github.com/pantsbuild/pex. Would something like this help for
keeping charms self contained?

On Tue, Mar 1, 2016, 4:45 PM Cory Johns  wrote:

> I'd like to raise awareness of the following issue open against
> charm-tools: https://github.com/juju/charm-tools/issues/117
>
> It affects deploying charms in network-restricted environments, depending
> on whether any of the Python libraries they depend on in their wheelhouse
> use a feature called "setup_requires."  Most don't, but some, like path.py,
> do.
>
> The issue has links with more information and a potential partial
> work-around, but it would still require some manual work by the charm
> author, so I also wanted to start a discussion about other possible
> solutions.
> --
> 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: Logging into the API on Juju 2.0

[Adam Stokes]

Went ahead and filed a bug here:
https://bugs.launchpad.net/juju-core/+bug/1551743

On Tue, Mar 1, 2016 at 8:40 AM, Rick Harding <rick.hard...@canonical.com>
wrote:

> Thank Adam. That's good feedback. With tabular output the default now we
> should be more verbose on the yaml output and display the uuids and other
> data.
>
> On Tue, Mar 1, 2016, 8:37 AM Adam Stokes <adam.sto...@canonical.com>
> wrote:
>
>> One of the problems using `juju list-controllers --format yaml` versus
>> reading the controllers.yaml file directly is the information is
>> different.  Specifically I need the UUID in order to build the URL used
>> when accessing Juju's API.
>>
>>   adam@deadpool:conjure   juju list-controllers --format yaml
>> controllers:
>>   local.conjure:
>> model: conjure
>> user: admin@local
>> server: 10.0.3.130:17070
>>   local.conjure-maas:
>> model: conjure-maas
>> user: admin@local
>> server: 172.16.0.152:17070
>> current-controller: local.conjure-maas
>>
>>
>>   adam@deadpool:conjure   cat ~/.local/share/juju/controllers.yaml
>> controllers:
>>   local.conjure:
>> servers: ['10.0.3.130:17070', '127.0.0.1:17070', '[::1]:17070',
>> '[fe80::216:3eff:fe22:c849]:17070']
>> uuid: 0551fce8-0e0d-4fbc-8d53-b67f7a7657c4
>> api-endpoints: ['10.0.3.130:17070', '127.0.0.1:17070',
>> '[::1]:17070', '[fe80::216:3eff:fe22:c849]:17070']
>> ca-cert: |
>>   -BEGIN CERTIFICATE-
>> -END CERTIFICATE-
>>   local.conjure-maas:
>> servers: ['172.16.0.152:17070']
>> uuid: ad6f65af-6b45-4293-8891-482635653807
>> api-endpoints: ['172.16.0.152:17070']
>> ca-cert: |
>>   -BEGIN CERTIFICATE-
>>
>>
>> On Mon, Feb 29, 2016 at 11:56 PM, Ian Booth <ian.bo...@canonical.com>
>> wrote:
>>
>>> No, you are right.
>>>
>>> $ juju list-controllers --format yaml
>>>
>>> is better.
>>>
>>> On 01/03/16 14:49, John Meinel wrote:
>>> > Is there a reason to tell people to look at "controllers.yaml" rather
>>> than
>>> > having the official mechanism be something like "juju list-controllers
>>> > --format=yaml" ? I'd really like to avoid tying 3rd party scripts to
>>> our
>>> > on-disk configuration. We can keep CLI compatibility, but on-disk
>>> > structures aren't something we really want to commit to forever.
>>> >
>>> > John
>>> > =:->
>>> >
>>> > On Tue, Mar 1, 2016 at 8:22 AM, Ian Booth <ian.bo...@canonical.com>
>>> wrote:
>>> >
>>> >> Just to be clear, the remote APi for listing models for a given
>>> controller
>>> >> exists. But you do need to look at controllers.yaml to see what
>>> >> controllers you
>>> >> have bootstrapped or have access to in order to make the remote list
>>> >> models api
>>> >> call.
>>> >>
>>> >> On 01/03/16 13:14, Adam Stokes wrote:
>>> >>> Got it squared away, being able to replicate `juju list-controllers`
>>> >> didn't
>>> >>> have a remote api. So I will continue to read from
>>> >>> ~/.local/share/juju/controllers.yaml. My intention was to basically
>>> see
>>> >>> what controllers were already bootstrapped and gather the models for
>>> >> those
>>> >>> controllers using the remote juju api. But that doesn't exist so I
>>> will
>>> >>> mimic what `juju list-controllers` does and read from the yaml file
>>> for
>>> >>> controllers that are local to my admin and users.
>>> >>>
>>> >>> On Mon, Feb 29, 2016 at 9:40 PM, Tim Penhey <
>>> tim.pen...@canonical.com>
>>> >>> wrote:
>>> >>>
>>> >>>> It is the controller that you have logged into for the API.
>>> >>>>
>>> >>>> What are you wanting?
>>> >>>>
>>> >>>> You need a different API connection for each controller.
>>> >>>>
>>> >>>> Tim
>>> >>>>
>>> >>>> On 01/03/16 15:05, Adam Stokes wrote:
>>> >>>>> Right, but how do you specify which controller you want to list the
>>> >>>>> models for? The only way I can see is to manuall

Re: Logging into the API on Juju 2.0

[Adam Stokes]

One of the problems using `juju list-controllers --format yaml` versus
reading the controllers.yaml file directly is the information is
different.  Specifically I need the UUID in order to build the URL used
when accessing Juju's API.

  adam@deadpool:conjure   juju list-controllers --format yaml
controllers:
  local.conjure:
model: conjure
user: admin@local
server: 10.0.3.130:17070
  local.conjure-maas:
model: conjure-maas
user: admin@local
server: 172.16.0.152:17070
current-controller: local.conjure-maas


  adam@deadpool:conjure   cat ~/.local/share/juju/controllers.yaml
controllers:
  local.conjure:
servers: ['10.0.3.130:17070', '127.0.0.1:17070', '[::1]:17070',
'[fe80::216:3eff:fe22:c849]:17070']
uuid: 0551fce8-0e0d-4fbc-8d53-b67f7a7657c4
api-endpoints: ['10.0.3.130:17070', '127.0.0.1:17070', '[::1]:17070',
'[fe80::216:3eff:fe22:c849]:17070']
ca-cert: |
  -BEGIN CERTIFICATE-
-END CERTIFICATE-
  local.conjure-maas:
servers: ['172.16.0.152:17070']
uuid: ad6f65af-6b45-4293-8891-482635653807
api-endpoints: ['172.16.0.152:17070']
ca-cert: |
  -BEGIN CERTIFICATE-


On Mon, Feb 29, 2016 at 11:56 PM, Ian Booth <ian.bo...@canonical.com> wrote:

> No, you are right.
>
> $ juju list-controllers --format yaml
>
> is better.
>
> On 01/03/16 14:49, John Meinel wrote:
> > Is there a reason to tell people to look at "controllers.yaml" rather
> than
> > having the official mechanism be something like "juju list-controllers
> > --format=yaml" ? I'd really like to avoid tying 3rd party scripts to our
> > on-disk configuration. We can keep CLI compatibility, but on-disk
> > structures aren't something we really want to commit to forever.
> >
> > John
> > =:->
> >
> > On Tue, Mar 1, 2016 at 8:22 AM, Ian Booth <ian.bo...@canonical.com>
> wrote:
> >
> >> Just to be clear, the remote APi for listing models for a given
> controller
> >> exists. But you do need to look at controllers.yaml to see what
> >> controllers you
> >> have bootstrapped or have access to in order to make the remote list
> >> models api
> >> call.
> >>
> >> On 01/03/16 13:14, Adam Stokes wrote:
> >>> Got it squared away, being able to replicate `juju list-controllers`
> >> didn't
> >>> have a remote api. So I will continue to read from
> >>> ~/.local/share/juju/controllers.yaml. My intention was to basically see
> >>> what controllers were already bootstrapped and gather the models for
> >> those
> >>> controllers using the remote juju api. But that doesn't exist so I will
> >>> mimic what `juju list-controllers` does and read from the yaml file for
> >>> controllers that are local to my admin and users.
> >>>
> >>> On Mon, Feb 29, 2016 at 9:40 PM, Tim Penhey <tim.pen...@canonical.com>
> >>> wrote:
> >>>
> >>>> It is the controller that you have logged into for the API.
> >>>>
> >>>> What are you wanting?
> >>>>
> >>>> You need a different API connection for each controller.
> >>>>
> >>>> Tim
> >>>>
> >>>> On 01/03/16 15:05, Adam Stokes wrote:
> >>>>> Right, but how do you specify which controller you want to list the
> >>>>> models for? The only way I can see is to manually `juju switch
> >>>>> ` then re-login to the API and run the AllModels method.
> Is
> >>>>> there a way (as an administrator) to specify which controller you
> want
> >>>>> to list the models for?
> >>>>>
> >>>>> On Mon, Feb 29, 2016 at 8:46 PM, Ian Booth <ian.bo...@canonical.com
> >>>>> <mailto:ian.bo...@canonical.com>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 01/03/16 11:25, Adam Stokes wrote:
> >>>>> > On Mon, Feb 29, 2016 at 7:24 PM, Tim Penhey
> >>>>> <tim.pen...@canonical.com <mailto:tim.pen...@canonical.com>>
> >>>>> > wrote:
> >>>>> >
> >>>>> >> On 01/03/16 03:48, Adam Stokes wrote:
> >>>>> >>> Is there a way to list all models for a specific controller?
> >>>>> >>
> >>>>> >> Yes.
> >>>>> >
> >>>>> >
> >>>>> > Mind pointing me to the api docs that has that capability?
> >>>>> >
> >>>>>
> >>>>>
> >>>>
> https://godoc.org/github.com/juju/juju/api/controller#Client.AllModels
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> 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: Logging into the API on Juju 2.0

[Adam Stokes]

Got it squared away, being able to replicate `juju list-controllers` didn't
have a remote api. So I will continue to read from
~/.local/share/juju/controllers.yaml. My intention was to basically see
what controllers were already bootstrapped and gather the models for those
controllers using the remote juju api. But that doesn't exist so I will
mimic what `juju list-controllers` does and read from the yaml file for
controllers that are local to my admin and users.

On Mon, Feb 29, 2016 at 9:40 PM, Tim Penhey <tim.pen...@canonical.com>
wrote:

> It is the controller that you have logged into for the API.
>
> What are you wanting?
>
> You need a different API connection for each controller.
>
> Tim
>
> On 01/03/16 15:05, Adam Stokes wrote:
> > Right, but how do you specify which controller you want to list the
> > models for? The only way I can see is to manually `juju switch
> > ` then re-login to the API and run the AllModels method. Is
> > there a way (as an administrator) to specify which controller you want
> > to list the models for?
> >
> > On Mon, Feb 29, 2016 at 8:46 PM, Ian Booth <ian.bo...@canonical.com
> > <mailto:ian.bo...@canonical.com>> wrote:
> >
> >
> >
> > On 01/03/16 11:25, Adam Stokes wrote:
> > > On Mon, Feb 29, 2016 at 7:24 PM, Tim Penhey
> >     <tim.pen...@canonical.com <mailto:tim.pen...@canonical.com>>
> > > wrote:
> > >
> > >> On 01/03/16 03:48, Adam Stokes wrote:
> > >>> Is there a way to list all models for a specific controller?
> > >>
> > >> Yes.
> > >
> > >
> > > Mind pointing me to the api docs that has that capability?
> > >
> >
> >
> https://godoc.org/github.com/juju/juju/api/controller#Client.AllModels
> >
> >
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Adam Stokes]

Right, but how do you specify which controller you want to list the models
for? The only way I can see is to manually `juju switch ` then
re-login to the API and run the AllModels method. Is there a way (as an
administrator) to specify which controller you want to list the models for?

On Mon, Feb 29, 2016 at 8:46 PM, Ian Booth <ian.bo...@canonical.com> wrote:

>
>
> On 01/03/16 11:25, Adam Stokes wrote:
> > On Mon, Feb 29, 2016 at 7:24 PM, Tim Penhey <tim.pen...@canonical.com>
> > wrote:
> >
> >> On 01/03/16 03:48, Adam Stokes wrote:
> >>> Is there a way to list all models for a specific controller?
> >>
> >> Yes.
> >
> >
> > Mind pointing me to the api docs that has that capability?
> >
>
> https://godoc.org/github.com/juju/juju/api/controller#Client.AllModels
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Adam Stokes]

On Mon, Feb 29, 2016 at 7:24 PM, Tim Penhey <tim.pen...@canonical.com>
wrote:

> On 01/03/16 03:48, Adam Stokes wrote:
> > Is there a way to list all models for a specific controller?
>
> Yes.


Mind pointing me to the api docs that has that capability?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Adam Stokes]

Is there a way to list all models for a specific controller?

https://godoc.org/github.com/juju/juju/api/controller and
https://godoc.org/github.com/juju/juju/api/modelmanager seem to do the same
thing wrt listing models. This also only does it for whatever the current
controller is set to before making the api call. I also don't see a way to
list all active controllers, is there a way to do that as well?

I also think the API is a bit confusing when it comes to distinguishing
between a Controller and its Models. There are at least 2 places in the api
that call out to listing models:

https://github.com/juju/juju/blob/master/api/controller/controller.go#L35
https://github.com/juju/juju/blob/master/api/modelmanager/modelmanager.go#L78

And there are other areas where you create a model via modelmanager but can
only gather information about a model via the client, why not just put all
model related api code under modelmanager?


On Fri, Feb 26, 2016 at 9:02 PM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> Ok perfect, i'll try these tags out with the api. Thanks again
>
> On Fri, Feb 26, 2016 at 9:01 PM, Ian Booth <ian.bo...@canonical.com>
> wrote:
>
>> The admin user tag for aws is the same as described below. The @local
>> suffix
>> pertains to the controller not the cloud - think of it as users for a
>> controller
>> you bootstrap yourself are local to that controller.
>>
>> On 27/02/16 11:29, Adam Stokes wrote:
>> > Thanks that makes sense now. I don't have aws or anything but what would
>> > the admin user tag for those clouds look like?
>> >
>> > On Fri, Feb 26, 2016 at 7:07 PM, Andrew Wilkins <
>> > andrew.wilk...@canonical.com> wrote:
>> >
>> >> On Sat, Feb 27, 2016 at 1:10 AM Adam Stokes <adam.sto...@canonical.com
>> >
>> >> wrote:
>> >>
>> >>> Also, will the API support non admin users to login and query the
>> various
>> >>> modelmanager methods they have access to? If so, will this be
>> available by
>> >>> GA release?
>> >>>
>> >>> On Fri, Feb 26, 2016 at 11:45 AM, Adam Stokes <
>> adam.sto...@canonical.com>
>> >>> wrote:
>> >>>
>> >>>> Currently, the only way to login to the Juju 2.0 api is to use the
>> Tag
>> >>>> of 'user-admin'.
>> >>>>
>> >>>
>> >> You can log in with additional users. With the CLI, you can do:
>> >>   - juju add-user bob
>> >>   - juju change-user-password bob
>> >>   - juju switch-user bob
>> >> (or you could use the "register" command to add another controller
>> entry;
>> >> you'll still end up with the "bob" user)
>> >>
>> >> However, all the files created by juju during bootstrap (accounts.yaml,
>> >>>> models.yaml, controllers.yaml) only mention the admin user as
>> 'admin@local'
>> >>>> for the controller.
>> >>>>
>> >>>
>> >> "admin" is equivalent to "admin@local"; the latter form is canonical.
>> >> What you're passing over the API is a different form altogether: it is
>> a
>> >> "tag". The tag form of a user is: user-[@domain].
>> >>
>> >> So for the "admin@local" user, the tag form is "user-admin@local". You
>> >> can also supply just "user-admin", and the "local" is implied.
>> >>
>> >> When will the API login support logging in as the admin user for the
>> >>>> specified controller?
>> >>>>
>> >>>> An example of the request being passed to the api server:
>> >>>>
>> >>>> {'Type': 'Admin',
>> >>>>  'Version': 3,
>> >>>>  'Request': 'Login',
>> >>>>  'RequestId': 1,
>> >>>>  'Params': {'auth-tag': user,
>> >>>>'credentials': password}}
>> >>>>
>> >>>> user = 'user-admin' and not 'admin@local' as seen in the yaml
>> configs.
>> >>>>
>> >>>
>> >> That should be working. Please file a bug if it's not, with steps to
>> >> reproduce.
>> >>
>> >> Cheers,
>> >> Andrew
>> >>
>> >
>> >
>> >
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Adam Stokes]

Ok perfect, i'll try these tags out with the api. Thanks again

On Fri, Feb 26, 2016 at 9:01 PM, Ian Booth <ian.bo...@canonical.com> wrote:

> The admin user tag for aws is the same as described below. The @local
> suffix
> pertains to the controller not the cloud - think of it as users for a
> controller
> you bootstrap yourself are local to that controller.
>
> On 27/02/16 11:29, Adam Stokes wrote:
> > Thanks that makes sense now. I don't have aws or anything but what would
> > the admin user tag for those clouds look like?
> >
> > On Fri, Feb 26, 2016 at 7:07 PM, Andrew Wilkins <
> > andrew.wilk...@canonical.com> wrote:
> >
> >> On Sat, Feb 27, 2016 at 1:10 AM Adam Stokes <adam.sto...@canonical.com>
> >> wrote:
> >>
> >>> Also, will the API support non admin users to login and query the
> various
> >>> modelmanager methods they have access to? If so, will this be
> available by
> >>> GA release?
> >>>
> >>> On Fri, Feb 26, 2016 at 11:45 AM, Adam Stokes <
> adam.sto...@canonical.com>
> >>> wrote:
> >>>
> >>>> Currently, the only way to login to the Juju 2.0 api is to use the Tag
> >>>> of 'user-admin'.
> >>>>
> >>>
> >> You can log in with additional users. With the CLI, you can do:
> >>   - juju add-user bob
> >>   - juju change-user-password bob
> >>   - juju switch-user bob
> >> (or you could use the "register" command to add another controller
> entry;
> >> you'll still end up with the "bob" user)
> >>
> >> However, all the files created by juju during bootstrap (accounts.yaml,
> >>>> models.yaml, controllers.yaml) only mention the admin user as
> 'admin@local'
> >>>> for the controller.
> >>>>
> >>>
> >> "admin" is equivalent to "admin@local"; the latter form is canonical.
> >> What you're passing over the API is a different form altogether: it is a
> >> "tag". The tag form of a user is: user-[@domain].
> >>
> >> So for the "admin@local" user, the tag form is "user-admin@local". You
> >> can also supply just "user-admin", and the "local" is implied.
> >>
> >> When will the API login support logging in as the admin user for the
> >>>> specified controller?
> >>>>
> >>>> An example of the request being passed to the api server:
> >>>>
> >>>> {'Type': 'Admin',
> >>>>  'Version': 3,
> >>>>  'Request': 'Login',
> >>>>  'RequestId': 1,
> >>>>  'Params': {'auth-tag': user,
> >>>>'credentials': password}}
> >>>>
> >>>> user = 'user-admin' and not 'admin@local' as seen in the yaml
> configs.
> >>>>
> >>>
> >> That should be working. Please file a bug if it's not, with steps to
> >> reproduce.
> >>
> >> Cheers,
> >> Andrew
> >>
> >
> >
> >
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Adam Stokes]

Thanks that makes sense now. I don't have aws or anything but what would
the admin user tag for those clouds look like?

On Fri, Feb 26, 2016 at 7:07 PM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Sat, Feb 27, 2016 at 1:10 AM Adam Stokes <adam.sto...@canonical.com>
> wrote:
>
>> Also, will the API support non admin users to login and query the various
>> modelmanager methods they have access to? If so, will this be available by
>> GA release?
>>
>> On Fri, Feb 26, 2016 at 11:45 AM, Adam Stokes <adam.sto...@canonical.com>
>> wrote:
>>
>>> Currently, the only way to login to the Juju 2.0 api is to use the Tag
>>> of 'user-admin'.
>>>
>>
> You can log in with additional users. With the CLI, you can do:
>   - juju add-user bob
>   - juju change-user-password bob
>   - juju switch-user bob
> (or you could use the "register" command to add another controller entry;
> you'll still end up with the "bob" user)
>
> However, all the files created by juju during bootstrap (accounts.yaml,
>>> models.yaml, controllers.yaml) only mention the admin user as 'admin@local'
>>> for the controller.
>>>
>>
> "admin" is equivalent to "admin@local"; the latter form is canonical.
> What you're passing over the API is a different form altogether: it is a
> "tag". The tag form of a user is: user-[@domain].
>
> So for the "admin@local" user, the tag form is "user-admin@local". You
> can also supply just "user-admin", and the "local" is implied.
>
> When will the API login support logging in as the admin user for the
>>> specified controller?
>>>
>>> An example of the request being passed to the api server:
>>>
>>> {'Type': 'Admin',
>>>  'Version': 3,
>>>  'Request': 'Login',
>>>  'RequestId': 1,
>>>  'Params': {'auth-tag': user,
>>>'credentials': password}}
>>>
>>> user = 'user-admin' and not 'admin@local' as seen in the yaml configs.
>>>
>>
> That should be working. Please file a bug if it's not, with steps to
> reproduce.
>
> Cheers,
> Andrew
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Adam Stokes]

Also, will the API support non admin users to login and query the various
modelmanager methods they have access to? If so, will this be available by
GA release?

On Fri, Feb 26, 2016 at 11:45 AM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> Currently, the only way to login to the Juju 2.0 api is to use the Tag of
> 'user-admin'. However, all the files created by juju during bootstrap
> (accounts.yaml, models.yaml, controllers.yaml) only mention the admin user
> as 'admin@local' for the controller.
>
> When will the API login support logging in as the admin user for the
> specified controller?
>
> An example of the request being passed to the api server:
>
> {'Type': 'Admin',
>  'Version': 3,
>  'Request': 'Login',
>  'RequestId': 1,
>  'Params': {'auth-tag': user,
>'credentials': password}}
>
> user = 'user-admin' and not 'admin@local' as seen in the yaml configs.
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Logging into the API on Juju 2.0

[Adam Stokes]

Currently, the only way to login to the Juju 2.0 api is to use the Tag of
'user-admin'. However, all the files created by juju during bootstrap
(accounts.yaml, models.yaml, controllers.yaml) only mention the admin user
as 'admin@local' for the controller.

When will the API login support logging in as the admin user for the
specified controller?

An example of the request being passed to the api server:

{'Type': 'Admin',
 'Version': 3,
 'Request': 'Login',
 'RequestId': 1,
 'Params': {'auth-tag': user,
   'credentials': password}}

user = 'user-admin' and not 'admin@local' as seen in the yaml configs.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD support (maybe)

[Adam Stokes]

When will this PR make it into the lxd-container-type feature branch so we
can start testing this?

On Thu, Feb 25, 2016 at 5:41 PM, Ian Booth  wrote:

> FWIW, go 1.6 works just fine with Juju on my system
>
> On 26/02/16 08:34, Menno Smits wrote:
> > On 26 February 2016 at 04:59, Horacio Duran  >
> > wrote:
> >
> >> be aware though, iirc that ppa replaces your go version with 1.6 (or
> used
> >> to) which can mess your env if you are using go from ubuntu.
> >>
> >
> > With a bit of apt configuration you can use the lxd stable PPA without
> > pulling in its Go 1.6 packages.
> >
> > Here's what I did:
> >
> > $ cat /etc/apt/preferences.d/lxd-stable-pin
> > Package:  *
> > Pin: release o=LP-PPA-ubuntu-lxc-lxd-stable
> > Pin-Priority: 200
> >
> > Package: lxd lxd-tools lxd-client lxcfs lxc-templates lxc cgmanager
> > libcgmanager0 libseccomp2
> > Pin: release o=LP-PPA-ubuntu-lxc-lxd-stable
> > Pin-Priority: 500
> >
> > The main problem with this approach is that you have to explicitly
> specify
> > the package names you do want to use, which will be a problem if package
> > names change or extra packages are added. Maybe someone with more apt foo
> > than me knows a better way.
> >
> > - Menno
> >
> >
> >
>
> --
> 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: Breaking news - New Juju 2.0 home^H^H^H^H data location

[Adam Stokes]

Does this mean the environments.yaml file is going away at some point?

On Mon, Feb 8, 2016 at 10:33 AM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> Does this mean the environments.yaml file is going away at some point?
>
> On Mon, Feb 8, 2016 at 2:16 AM, Ian Booth <ian.bo...@canonical.com> wrote:
>
>> As advance notice, the next alpha release of Juju 2.0 (due this week)
>> will use a
>> new default home location. Juju will now adhere to the the XDG desktop
>> standard
>> and use this directory (by default):
>>
>> ~/.local/share/juju
>>
>> to store its working files (%APPDATA%/Juju on Windows). This is partly to
>> allow
>> Juju 2.0 to be installed alongside 1.x.
>>
>> Very, very soon, the need for an environments.yaml file will be no more,
>> meaning
>> there will be no need for the user to edit any files in that directory.
>> As a
>> sneak peak of what is coming, you will be able to, out of the box:
>>
>> $ juju bootstrap mycontroller aws/us-west-2
>>
>> Note that there's no need to "$ juju init" or edit any environment.yaml
>> to use
>> the public clouds and regions supported by Juju. Adding support for new
>> regions
>> or cloud information is a simple matter of running "$juju update-clouds".
>> There's more to come, but you get the idea.
>>
>> Anyway, the point of the above is to say the location of the home/data
>> directory
>> doesn't really matter as there will be no need to poke around inside it.
>>
>> As an interim measure, if you run off master, just:
>>
>> mkdir ~/.local/share/juju
>> cp -r ~/.juju/* ~/.local/share/juju
>>
>> if you want to use existing models with the latest build from source.
>>
>>
>>
>>
>> --
>> 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: Problem deploying a bundle

[Adam Stokes]

You'll need to update your revisions in the bundle file. We ran into this
problem as well yesterday and it has to deal with charmhelpers regex when
matching package_names -> openstack_versions.

On Tue, Feb 2, 2016 at 10:10 PM, Pshem Kowalczyk  wrote:

> Hi,
>
> I've created my own openstack bundle (attached) that I use to re-deploy
> our staging environment. I've used that bundle a number of times in the
> past.
>
> I've attempted to upgrade to 16.01 charms and try the trusty-mitaka
> openstack, but ran into issues so decided to wipe out the whole environment
> and start from scratch.
>
> To my great surprise the bundle doesn't deploy any more. Multiple charms
> fail with messages like:
>
> 2016-02-03 02:49:19 ERROR juju-log FATAL ERROR: Could not determine
> OpenStack codename for version 8.0.1 (keystone)
> 2016-02-03 02:47:49 ERROR juju-log FATAL ERROR: Could not determine
> OpenStack codename for version 11.0.1 (glance)
> 016-02-03 02:48:30 ERROR juju-log FATAL ERROR: Could not determine
> OpenStack codename for version 7.0.1 (cinder)
>
> etc.
>
> Why are they failing now? And the more important question - how do I make
> it work again? Do I have to upgrade my bundle file to use the new charms?
>
> kind regards
> Pshem
>
>
> --
> 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: Apt layer released

[Adam Stokes]

Why would someone want to use this instead of what's provided in
charmhelpers?

On Thu, Jan 28, 2016 at 10:48 AM, Stuart Bishop  wrote:

> The Apt layer is more code broken out from my PostgreSQL charm work
> that will be used by future Cassandra charm work.
>
> It provides a simple, charms.reactive friendly interface for dealing
> with apt sources and deb packages. But I think its main utility is
> providing consistent configuration for those extra features required
> for real world production deploys without charmers needing to add a
> single line of code; specifying custom apt sources, package signing
> keys, package version pinning, and a list of arbitrary additional
> packages to install. It also finally documents these options,
> previously only found in the bowels of charmhelpers.core.fetch (which
> provides the underlying implementation).
>
>
>
> # Apt layer
>
> The Apt layer for Juju enables layered charms to more easily deal with
> deb packages and apt sources in a simple and efficient manner. It
> provides consistent configuration for operators, allowing them to
> easily specify custom apt sources and additional debs required for
> their particular installations.
>
> ## Configuration
>
> The charm may provide defaults for these service configuration
> (config.yaml) options, and the operator may override them as required.
>
> * `extra_packages`
>
>   A space separated list of additional deb packages to install on
>   each unit.
>
> * `package_status`
>
>   'install' or 'hold'. When set to hold, packages installed using
>   the Apt layer API will be pinned, so that they will not be
>   automatically upgraded when package updates are performed. 'hold'
>   is particularly useful for allowing a service such as Landscape
>   to automatically apply security updates to most of the system,
>   whilst holding back any potentially service affecting updates.
>
> * `install_sources`
>
>   A list of apt sources containing the packages that need to be
> installed.
>   Each source may be either a line that can be added directly to
>   sources.list(5), or in the form ppa:/ for adding
>   Personal Package Archives, or a distribution component to enable.
>   The list is a yaml list, encoded as a string. The nicest way of
>   declaring this in a yaml file looks like the following (in
> particular,
>   the | character indicates that the value is a multiline string):
>
>   ```
> install_sources: |
> - ppa:stub/cassandra
> - deb http://www.apache.org/dist/cassandra/debian 21x main
>   ```
>
> * `install_keys`
>
>   A list of GPG signing keys to accept. There needs to be one entry
>   per entry in install_sources. null may be used if no keep is
>   needed, which is the case for PPAs and for the standard Ubuntu
>   archives. Keys should be full ASCII armoured GPG public keys.
>   GPG key ids are also accepted, but in most environments this
>   mechanism is not secure. The install_keys list, like
>   install_sources, must also be a yaml formatted list encoded as
>   a string:
>
>   ```
> install_keys: |
> - null
> - |
>   -BEGIN PGP PUBLIC KEY BLOCK-
>   Version: GnuPG v1
>
>
> mQINBFQJvgUBEAC0KcYCTj0hd15p4fiXBsbob0sKgsvN5Lm7N9jzJWlGshJ0peMi
>
> kH8YhDXw5Lh+mPEHksL7t1L8CIr1a+ntns/Opt65ZPO38ENVkOqEVAn9Z5sIoZsb
>
> AUeLlJzSeRLTKhcOugK7UcsQD2FHnMBJz50bxis9X7pjmnc/tWpjAGJfaWdjDIo=
>   =yiQ4
>   -END PGP PUBLIC KEY BLOCK-
>   ```
>
> ## Usage
>
> Queue packages for installation, and have handlers waiting for
> these packages to finish being installed:
>
> ```
> from reactive import apt
>
> @hook('install')
> def install():
> apt.queue_install(['git'])
>
> @when_not('apt.installed.gnupg')
> def install_gnupg():
> apt.queue_install(['gnupg'])
>
> @when('apt.installed.git')
> @when('apt.installed.gnupg')
> def grabit():
> clone_repo()
> validate_repo()
> ```
>
> ### API
>
> Several methods are exposed in the reactive.apt Python package.
>
> * `add_source(source, key=None)`
>
>   Add an apt source.
>
>   A source may be either a line that can be added directly to
>   sources.list(5), or in the form ppa:/ for adding
>   Personal Package Archives, or a distribution component to enable.
>
>   The package signing key should be an ASCII armoured GPG key. While
>   GPG key ids are also supported, the retrieval mechanism is insecure.
>   There is no need to specify the package signing key for PPAs or for
>   the main Ubuntu archives.
>
>   It is preferable if charms do not call this directly to hard
>   coded apt sources, but instead have these sources listed
>   as defaults in the install_sources config option. This allows
>   operators to mirror your packages to internal archives and
>  

Re: Apt layer released

[Adam Stokes]

Cool thanks for the additional info, I'm going to integrate this into my
layers now

On Thu, Jan 28, 2016 at 11:46 AM, Stuart Bishop <stuart.bis...@canonical.com
> wrote:

> On 28 January 2016 at 23:01, Adam Stokes <adam.sto...@canonical.com>
> wrote:
> > Why would someone want to use this instead of what's provided in
> > charmhelpers?
>
> This wraps what is provided in charmhelpers.
>
> To use raw charmhelpers, you need to write the hooks and handlers to
> call its features at the right time and in the right order. You need
> to call fetch.configure_sources, whenever the relevant config items
> change. You need to install the list of extra packages, whenever the
> relevant config item changes. You need to repin held packages, if the
> option is set, whenever new packages are installed. To use the layer,
> you just add an entry to layers.yaml and get it all done for you, and
> it is all done consistently across all charms using the layer. You
> don't have to worry about inconsistencies between your
> reimplementation of the wheel with the next charms reimplementation of
> the wheel causing confusion to users.
>
> It also removes all the boilerplate. You don't need to include all
> that gumph in your config.yaml.
>
> It sets reactive states your handlers can wait on so you don't have to
> set reactive states your handlers can wait on.
>
> By requesting a package install and having handlers wait on the
> install to complete, you get to write highly decoupled code without
> losing efficiency. Several different handlers in different parts of
> the code base and even in different layers can all schedule the
> packages they care about to be installed, and have a single apt-get
> update run, and only if necessary.
>
> Improvements to the layer improve all charms using the layer. When
> Juju charm configuration gets richer data structures, we can write all
> the migration, compatibility and deprecation stuff once and all charms
> get it next time they are built. Fixes in the charmhelpers codebase
> can't fix its callsites or improve the documentation in your
> config.yaml.
>
> So you want to use it to save initial work and future maintenance :)
>
>
>
> --
> Stuart Bishop <stuart.bis...@canonical.com>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: additional catering towards the application developer

[Adam Stokes]

Also there seems to be a couple of bugs relevant to this discussion:

https://bugs.launchpad.net/juju-core/+bug/1445066
https://bugs.launchpad.net/juju-core/+bug/1445078

On Wed, Dec 9, 2015 at 5:09 PM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> I agree, having the ability to run actions synchronously and wait for a
> result  would be a huge step in allowing charm authors to provide actions
> that can be used during the development of your application _before_ you
> reach the stage of charming that app.
>
> Casey, made a suggestion of possibly making the actions more relevant to
> the type of task it's running (background vs run-and-wait). For example, to
> launch an action in the background you could do `juju action launch (begin,
> start)` and to run an action immediately and wait for the result would be
> `juju action do` or even drop the word `action` and have it be `juju
> launch` and `juju do`. Semantics aside though I think this would be an
> excellent addition and first step for getting application developers
> interested in bringing their application into the Juju ecosystem.
>
> On Wed, Dec 9, 2015 at 4:48 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> I've been thinking about the actions as well. 99% of the actions use-case
>> is: Run the action, wait for it to finish and show the result. Most of the
>> actions are things like 'restart', 'show-something',...
>>
>> I think waiting for the action to finish and show the result should be
>> put in as a flag, with the possibility to become default in Juju2.
>>
>> - Juju 1: Add flag --wait
>> - Juju 2: Make --wait default and add flag --no-wait
>>
>>
>> What do you guys think? Is this what you had in mind, Adam?
>>
>> 2015-12-09 18:28 GMT+01:00 Adam Stokes <adam.sto...@canonical.com>:
>>
>>> I wanted to write this to get a discussion going around how we can better
>>> support application developers. This is something I've been thinking
>>> about
>>> for awhile and was further convinced to write this email after seeing
>>> posts
>>> like:
>>> http://askubuntu.com/questions/635758/is-juju-a-suitable-tool-for-development-as-well-as-deployment
>>>
>>> The scenario:
>>>
>>> In its simplest form, I am writing a web application that needs a
>>> database. I
>>> would like to quickly startup a postgresql server and grab it's
>>> connection
>>> information.
>>>
>>> How's its done with docker:
>>> $ docker pull k0st/alpine-postgres
>>> $ docker run --name myapp -e POSTGRES_USER=user -e
>>> POSTGRES_PASSWORD=password -e POSTGRES_DB=testdb k0st/alpine-postgres
>>> $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' myapp
>>> 172.16.0.5
>>>
>>> From here you can build your connection string:
>>> postgresql://user:password@172.16.0.5:5432/testdb
>>>
>>> And now how we could possibly accomplish this with Juju today:
>>>
>>> 1. Using Juju actions:
>>>
>>> $ juju deploy postgresql
>>> $ juju action do postgresql/0 createdb username=user password=pass
>>> database=testdb
>>> Action queued with id 32432-432-432-432-432-432
>>> $ juju action fetch 32432-432-432-432-432-432
>>>
>>> .. Parse the results
>>>
>>> message: "" # No error message.
>>> results:
>>>   result-map:
>>> connection_string: postgresql://user:pass@
>>> :5432/testdb
>>> message: Hello world!
>>>   outcome: success
>>> status: completed
>>>
>>> 2. Adding support in the charm hook (config-changed)
>>>
>>> $ juju deploy postgresql
>>> $ juju set postgresql "createdb=user:pass:dbname"
>>>
>>> .. config-changed
>>>
>>> status-set "active", "db created:
>>> postgresql://user:pass@unit-public-address:5432/dbname"
>>>
>>> $ juju status postgresql
>>>
>>> Look for the status message in the output.
>>>
>>> As you can tell between docker and juju we're still looking at 3
>>> commands for
>>> just standing a database up, creating the db, and getting its connection
>>> details.
>>>
>>> It would be really nice if I could just do:
>>>
>>> $ juju deploy postgresql
>>> $ juju postgresql create-db --username=user --password=pass
>>> --database=mydb
>>>
>>> # Default to json output for our application to consume and make use of
>>> {"error": "", "result": "postgresql://user:pass@unit-public-address
>>> :5432/mydb"}
>>>
>>> Even an action would still be ok if the action would print the results
>>> to stdout
>>> $ juju action do postgresql/0 create-db username=user password=pass
>>> database=mydb
>>> {"error": "", "result": "postgresql://user:pass@unit-public-address
>>> :5432/mydb"}
>>>
>>> For me, personally, I don't want to use docker or vagrant or any other
>>> tool as
>>> I feel Juju is fully capable of catering to the application developer.
>>>
>>> Thoughts?
>>>
>>> --
>>> 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

additional catering towards the application developer

[Adam Stokes]

I wanted to write this to get a discussion going around how we can better
support application developers. This is something I've been thinking about
for awhile and was further convinced to write this email after seeing posts
like:
http://askubuntu.com/questions/635758/is-juju-a-suitable-tool-for-development-as-well-as-deployment

The scenario:

In its simplest form, I am writing a web application that needs a database.
I
would like to quickly startup a postgresql server and grab it's connection
information.

How's its done with docker:
$ docker pull k0st/alpine-postgres
$ docker run --name myapp -e POSTGRES_USER=user -e
POSTGRES_PASSWORD=password -e POSTGRES_DB=testdb k0st/alpine-postgres
$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' myapp
172.16.0.5

>From here you can build your connection string:
postgresql://user:password@172.16.0.5:5432/testdb

And now how we could possibly accomplish this with Juju today:

1. Using Juju actions:

$ juju deploy postgresql
$ juju action do postgresql/0 createdb username=user password=pass
database=testdb
Action queued with id 32432-432-432-432-432-432
$ juju action fetch 32432-432-432-432-432-432

.. Parse the results

message: "" # No error message.
results:
  result-map:
connection_string: postgresql://user:pass@
:5432/testdb
message: Hello world!
  outcome: success
status: completed

2. Adding support in the charm hook (config-changed)

$ juju deploy postgresql
$ juju set postgresql "createdb=user:pass:dbname"

.. config-changed

status-set "active", "db created: postgresql://user:pass@unit-public-address
:5432/dbname"

$ juju status postgresql

Look for the status message in the output.

As you can tell between docker and juju we're still looking at 3 commands
for
just standing a database up, creating the db, and getting its connection
details.

It would be really nice if I could just do:

$ juju deploy postgresql
$ juju postgresql create-db --username=user --password=pass --database=mydb

# Default to json output for our application to consume and make use of
{"error": "", "result": "postgresql://user:pass@unit-public-address
:5432/mydb"}

Even an action would still be ok if the action would print the results to
stdout
$ juju action do postgresql/0 create-db username=user password=pass
database=mydb
{"error": "", "result": "postgresql://user:pass@unit-public-address
:5432/mydb"}

For me, personally, I don't want to use docker or vagrant or any other tool
as
I feel Juju is fully capable of catering to the application developer.

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

Re: Charm layers and python2 dependencies

[Adam Stokes]

You can use `pip2` and it'll pull down the python 2.7 flask

On Tue, Dec 8, 2015 at 12:36 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> Since shortly, Charm build creates Python3 Charms instead of Python2. I
> have a Charm that installs a Python2 application. It requires some pip
> dependencies like Flask, which I install using
> `subprocess.check_output(['pip', 'install', ...])`.
>
> The problem now is that for some reason, this installs the Python3 version
> of Flask. Is there a way to install Python2 dependencies from a Python3
> Charm using Pip?
>
>
>
> Kind regards
> Merlijn sebrechts
>
> --
> 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: [ANN] charm-tools 1.9.3

[Adam Stokes]

What if we only needed pure python modules? It seems like the toolchain
will always be installed because of some of the dependencies of
charmhelpers? Will these additional deps become optional once charmhelpers
is refactored?




On Wed, Nov 25, 2015, 11:18 PM Marco Ceppi 
wrote:

On Wed, Nov 25, 2015 at 4:08 PM Simon Davy  wrote:

On 25 November 2015 at 16:02, Marco Ceppi  wrote:
> ## Wheel House for layer dependencies
>
> Going forward we recommend all dependencies for layers and charms be
> packaged in a wheelhouse.txt file. This perform the installation of pypi
> packages on the unit instead of first on the local machine meaning Python
> libraries that require architecture specific builds will do it on the
units
> architecture.

If I'm understanding the above correctly, this approach is a blocker for us.

We would not want to install direct from pypi on a production service

 1) pypi packages are not signed (or when they are, pip doesn't verify
the signature)
 2) pypi is an external dependency and thus unreliable (although not
as bad these days)
 3) old versions can disappear from pypi at an authors whim.
 4) installing c packages involves installing a c toolchain on your prod
machine

Additionally, our policy (Canonical's, that is), does not allow access
to the internet on production machines, for very good reasons. This is
the default policy in many (probably most) production environments.

Any layer or charm that consumes a layer that uses this new approach
for dependencies would thus be unusable to us :(

It also harms repeatability, and I would not want to use it even if
our access policy allowed access to pypi.

For python charm dependencies, we use system python packages as much
as possible, or if we need any wheels, we ship that wheel in the
charm, and pip install it directly from the there. No external
network, completely repeatable.

So, allow me to clarify. If you review the pastebin outputs from the
original announcement email, what this shift does is previously `charm
build` would create and embed installed dependencies into the charm under
lib/ much like charm-helper-sync did for instead for any arbitrary Pypi
dependency. Issues there are for PyYAML it will build a yaml.so file which
would be built based on the architecture of your machine and not the cloud.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Here's our pile of new Juju questions for the week!

[Adam Stokes]

On Mon, Nov 9, 2015 at 9:42 AM, Jorge O. Castro  wrote:

> Happy Monday folks, here's the latest questions I've screened from our
> users that could use some love. Remember, you can subscribe to a tag
> to get an automated list of curated questions by hovering over the
> "juju" tag in the UI and clicking the star!
>
> Before we begin I'd like to highlight David Bostjanic's detailed self
> documenting processes around Juju on POWER8 systems:
> http://askubuntu.com/users/451719/david-bostjancic
>
> cmars answered this, (thanks!) but if we have a milestone for this
> it'd be nice to add to his answer:
> http://askubuntu.com/questions/693689/is-there-a-juju-rest-api
>
> This one needs a good answer, sounds like he's making his own autoscaler:
>
> http://askubuntu.com/questions/693682/whats-the-best-way-to-have-a-charm-control-juju
>
> OpenStack/MAAS/Landscape questions:
>
> http://askubuntu.com/questions/688527/maas-mirrored-regions
>
> http://askubuntu.com/questions/694085/ubuntu-openstack-single-installer-on-ubuntu-15-10-wily

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

Re: Juju service commands or communitation protocol

[Adam Stokes]

On Thu, Nov 5, 2015 at 8:24 AM, Mark Shuttleworth  wrote:

> On 05/11/15 00:19, André Moreira wrote:
> > Thank you, Adam. This is exactly what I was looking for.
> > André
>
> If you end up making bindings for another language like Ruby or Node
> then we'll be glad to publicise that to the community too!
>
> Mark
>

I dare say it, how about Perl? :)) https://metacpan.org/release/Juju
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju service commands or communitation protocol

[Adam Stokes]

If you're going to use Go or creating bindings of your own the api
documentation is https://godoc.org/github.com/juju/juju/api.

On Wed, Nov 4, 2015 at 8:30 AM, André Moreira  wrote:

> Thank you, Mark, for the reply.
> Nice to know there is this library and there will be an official one!
> But, if I want to use the REST api without the python library, where can I
> find documentation for it?
> Thanks in advance,
> André
>
> 2015-11-04 6:32 GMT-02:00 Mark Shuttleworth :
>
>> On 04/11/15 09:02, Merlijn Sebrechts wrote:
>> > I'm very interested to hear more about that python library! Is this
>> > something that will be discussed at the summit?
>>
>> It could be. There have been a couple of informal variations on this
>> theme from various sources, we recently decided it was worth making an
>> official one. Someone closer to that work would be able to provide more
>> insight, including whether it will be based on one like
>> http://python-jujuclient.readthedocs.org/ or whether it's a fresh start.
>>
>> Mark
>>
>
>
>
> --
>
> Le doux charme de maint songe
> Par leur bel art inventé
> Sous les habits du mensonge
> Nous offre la vérité.
> -La Fontaine
>
> --
> 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 service commands or communitation protocol

[Adam Stokes]

You'll have to check out some of the bindings code:

http://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/view/head:/jujuclient.py

That should give you a good indication of what the juju api server
requires. For example the credentials need to be in a form of


{'Type': 'Admin',
  'Request': 'Login',
  'RequestId': 1,
  'Params': {'AuthTag': 'user-admin',
 'Password': None}}

The above library is a single file which is pretty easy to grok and has
good documentation on what the functions do.

On Wed, Nov 4, 2015 at 11:04 AM, André Moreira <andre@gmail.com> wrote:

> Hi Adam,
> What I mean is how do I construct the json requests and how should I
> expect the json response to be provided. Do you know where do I find this
> kind of documentation? I mean, is there a doc for it without needing to
> read the source code?
> André
>
> 2015-11-04 11:34 GMT-02:00 Adam Stokes <adam.sto...@canonical.com>:
>
>> If you're going to use Go or creating bindings of your own the api
>> documentation is https://godoc.org/github.com/juju/juju/api.
>>
>> On Wed, Nov 4, 2015 at 8:30 AM, André Moreira <andre@gmail.com>
>> wrote:
>>
>>> Thank you, Mark, for the reply.
>>> Nice to know there is this library and there will be an official one!
>>> But, if I want to use the REST api without the python library, where can
>>> I find documentation for it?
>>> Thanks in advance,
>>> André
>>>
>>> 2015-11-04 6:32 GMT-02:00 Mark Shuttleworth <m...@ubuntu.com>:
>>>
>>>> On 04/11/15 09:02, Merlijn Sebrechts wrote:
>>>> > I'm very interested to hear more about that python library! Is this
>>>> > something that will be discussed at the summit?
>>>>
>>>> It could be. There have been a couple of informal variations on this
>>>> theme from various sources, we recently decided it was worth making an
>>>> official one. Someone closer to that work would be able to provide more
>>>> insight, including whether it will be based on one like
>>>> http://python-jujuclient.readthedocs.org/ or whether it's a fresh
>>>> start.
>>>>
>>>> Mark
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Le doux charme de maint songe
>>> Par leur bel art inventé
>>> Sous les habits du mensonge
>>> Nous offre la vérité.
>>> -La Fontaine
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
>
> --
>
> Le doux charme de maint songe
> Par leur bel art inventé
> Sous les habits du mensonge
> Nous offre la vérité.
> -La Fontaine
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charmers: request to add node.js layer

[Adam Stokes]

Hi,

I think my layer is ready for use
https://github.com/battlemidget/juju-layer-node I realize there is pending
changes to the actual composer names, aside from that could I get a review
on this and possibly added to http://interfaces.juju.solutions?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: charmers: request to add node.js layer

[Adam Stokes]

Sounds good, I'll make a few changes to the base layer and open up a PR for
that

On Wed, Oct 21, 2015 at 12:47 PM, Benjamin Saller <
benjamin.sal...@canonical.com> wrote:

> Hi Adam,
>
> This has been pushed to the index. In the future people should be able to
> add layers themselves with a Launchpad Account. Some of the things you do
> here might be able to find a home in the basic layer (for example the pep8
> code). I'd be happy if over time this layer could be smaller, and the basic
> layer a little smarter.
>
> Glad to see you getting use out of the system.
>
> Thanks,
> Ben
>
> On Wed, Oct 21, 2015 at 8:02 AM Adam Stokes <adam.sto...@canonical.com>
> wrote:
>
>> Hi,
>>
>> I think my layer is ready for use
>> https://github.com/battlemidget/juju-layer-node I realize there is
>> pending changes to the actual composer names, aside from that could I get a
>> review on this and possibly added to http://interfaces.juju.solutions?
>> --
>> 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

nodejs reactive layer

[Adam Stokes]

I'm looking to get my nodejs layer[1] included at
http://interfaces.juju.solutions and wanted to make sure that this charm
can be properly tested. I noticed that a Makefile is generated during
`charm-compose` and was curious how I can utilize that with amulet or
whatever the preferred way to test charms is. The amulet documentation
doesn't really go into how to actually run the tests locally so I can
easily verify my charm. Is there a how-to on the preferred (blessed) way of
testing charms locally?

For the curious my charm layer simply installs Node.js based on whatever
version you set in the config (0.10, 0.12, 4.x) and will be used when
deploying whatever node app you require.

Oh one other thing, I didn't see how to pass config options in amulet's
deploy so that I can test my different default versions from the config.

1: https://github.com/battlemidget/juju-layer-node

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

Re: nodejs reactive layer

[Adam Stokes]

Additionally I was hoping I could just layer my application on top of the
nodejs layer and have my node version available to the application layer so
it would look like:

- base layer
- node layer
- application api layer

The application api layer would then have access to node/npm during charm
deployment and be able to react to node's layer state. However, in testing
this out it doesn't look like my application layer ever gets executed once
the node layer has finished.

My thinking was that in order to test multiple node versions for my
application all I would need to do is deploy the charm with the node layers
default version configuration. To give you a better idea this is my api
service layer for an application I have:

https://github.com/wffm/juju-layer-wffmapi

That layer inherits from my node layer which inherits the base layer. I was
hoping to keep each layer's responsibility to just one thing, ie node layer
only installs node.js and exposes its installed state.

On Mon, Oct 19, 2015 at 9:23 AM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> I'm looking to get my nodejs layer[1] included at
> http://interfaces.juju.solutions and wanted to make sure that this charm
> can be properly tested. I noticed that a Makefile is generated during
> `charm-compose` and was curious how I can utilize that with amulet or
> whatever the preferred way to test charms is. The amulet documentation
> doesn't really go into how to actually run the tests locally so I can
> easily verify my charm. Is there a how-to on the preferred (blessed) way of
> testing charms locally?
>
> For the curious my charm layer simply installs Node.js based on whatever
> version you set in the config (0.10, 0.12, 4.x) and will be used when
> deploying whatever node app you require.
>
> Oh one other thing, I didn't see how to pass config options in amulet's
> deploy so that I can test my different default versions from the config.
>
> 1: https://github.com/battlemidget/juju-layer-node
>
> Thanks!
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: local provider

[Adam Stokes]

This would also help emphasize our single install option for the
OpenStack installer to be meant for trying out Juju and OpenStack.

http://ubuntu-cloud-installer.readthedocs.org/en/latest/single-installer.guide.html

On Fri, Dec 12, 2014 at 11:26 AM, Nate Finch nate.fi...@canonical.com wrote:
 It seems like a lot of people get confused by Juju, because it is different
 than the tools they know. They want to deploy stuff with Juju, and so they
 get a machine from AWS/Digital Ocean/whatever, ssh into the machine, install
 juju, and run the local provider and then wonder why they can't access
 their services from outside the machine.

 I think this stems from two things - one is the people are used to
 chef/puppet/etc where you ssh into the machine and then run the install
 there (note: I know nothing about these tools, so may be mis-characterizing
 them).  Whereas with Juju, you are perfectly able to orchestrate an install
 on a remote machine in the cloud from your laptop.

 The other is the local provider.  The intent of the local provider is to
 give users a way to easily try out Juju without needing to spin up real
 machines in the cloud. It's also very useful for testing out charms during
 charm development and/or testing service deployments.  It's not very useful
 for real production environments... but yet some people still try to
 shoehorn it into that job.

 I think one easy thing we could do to better indicate the purpose of the
 local provider is to simply rename it.  If we named it the demo provider,
 it would be much more clear to users that it is not expected to be used for
 deploying a production environment. This could be as easy as aliasing
 local to demo and making the default environments.yaml print out with
 the local provider renamed to demo.  (feel free to s/demo/testing/ or any
 other not ready for production word)

 What do you think?

 -Nate

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




-- 
[ Adam Stokes ]

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

Re: I gave a quick writeup over Juju on Digital Ocean

[Adam Stokes]

There is also this:

https://bugs.launchpad.net/juju-core/+bug/1372543

On Mon, Sep 22, 2014 at 12:25 PM, Charles Butler
charles.but...@canonical.com wrote:
 Just a quick note:

 Basin has seen we were #1 and sent people over to vote, so we're now in a
 tie for the #1 spot on the DO api integration page.  If you've used Juju on
 DO, please dont hesitate to head over to their community listing and vote
 for us!

 https://www.digitalocean.com/community/projects

 On Mon, Sep 22, 2014 at 12:15 PM, Sebastian sebas5...@gmail.com wrote:

 Yeah! DO rocks, and like Nate said, can't wait for the real provider !!!

 Here's a quote about that from Kapil:

 Its possible (although unscheduled atm) a real provider could be done for
 DO when the provider object storage requirements are dropped from juju which
 is work that's scheduled.  The coreos announcement also coincided with the
 release of the new userdata facility on DO (smoser verified its basically
 ec2 compatible) which means cloud-init support. In the future version of
 this plugin i intend to use the userdata facilities as it will speed up non
 bootstrap machine allocation as at the moment each machine has to be ssh'd
 into.


  Product owner! move this history to the top of the backlog please! :)

 Cheers,
 Sebas.


 2014-09-22 12:47 GMT-03:00 Nate Finch nate.fi...@canonical.com:

 Nice!  Digital Ocean really is super fast my Discourse charm takes
 21(!) minutes to deploy on an AWS m1.small and 7 minutes on a DO 2GB
 droplet, which is 2/3rds the price of the amazon instance.

 Kapil's digital ocean plugin really makes it all (relatively) seamless,
 too.  I look forward to when we can make a real provider for Digital Ocean,
 and I can take out that relatively part :)

 On Mon, Sep 22, 2014 at 11:42 AM, Charles Butler
 charles.but...@canonical.com wrote:

 http://blog.dasroot.net/juju-digital-ocean-awesome/

 Juju on Digital Ocean, WOW! That's all I have to say. Digital Ocean is
 one of the fastest cloud hosts around with their SSD backed virtual
 machines. To top it off their billing is a no-nonsense straight forward
 model. $5/mo for their lowest end server, with 1TB of included traffic.
 That's enough to scratch just about any itch you might have with the cloud.

 Speaking of scratching itches, if you haven't checked out Juju yet, now
 you have a prime, low cost cloud provider to toe the waters. Spinning up
 droplets with Juju is very straight forward, and offers you a hands on
 approach to service orchestration thats affordable enough for a weekend
 hacker to whet their appetite. Not to mention, Juju is currently the #1
 project on their API Integration listing! http://goo.gl/m6u781

 In about 11 minutes, we will go from zero to deployed infrastructure for
 a scale-out blog (much like the one you're reading right now).


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




-- 
[ Adam Stokes ]

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

Re: I gave a quick writeup over Juju on Digital Ocean

[Adam Stokes]

Something else that would be cool is to submit your blog posts as a
tutorial on DO

On Mon, Sep 22, 2014 at 12:26 PM, Adam Stokes adam.sto...@ubuntu.com wrote:
 There is also this:

 https://bugs.launchpad.net/juju-core/+bug/1372543

 On Mon, Sep 22, 2014 at 12:25 PM, Charles Butler
 charles.but...@canonical.com wrote:
 Just a quick note:

 Basin has seen we were #1 and sent people over to vote, so we're now in a
 tie for the #1 spot on the DO api integration page.  If you've used Juju on
 DO, please dont hesitate to head over to their community listing and vote
 for us!

 https://www.digitalocean.com/community/projects

 On Mon, Sep 22, 2014 at 12:15 PM, Sebastian sebas5...@gmail.com wrote:

 Yeah! DO rocks, and like Nate said, can't wait for the real provider !!!

 Here's a quote about that from Kapil:

 Its possible (although unscheduled atm) a real provider could be done for
 DO when the provider object storage requirements are dropped from juju 
 which
 is work that's scheduled.  The coreos announcement also coincided with the
 release of the new userdata facility on DO (smoser verified its basically
 ec2 compatible) which means cloud-init support. In the future version of
 this plugin i intend to use the userdata facilities as it will speed up non
 bootstrap machine allocation as at the moment each machine has to be ssh'd
 into.


  Product owner! move this history to the top of the backlog please! :)

 Cheers,
 Sebas.


 2014-09-22 12:47 GMT-03:00 Nate Finch nate.fi...@canonical.com:

 Nice!  Digital Ocean really is super fast my Discourse charm takes
 21(!) minutes to deploy on an AWS m1.small and 7 minutes on a DO 2GB
 droplet, which is 2/3rds the price of the amazon instance.

 Kapil's digital ocean plugin really makes it all (relatively) seamless,
 too.  I look forward to when we can make a real provider for Digital Ocean,
 and I can take out that relatively part :)

 On Mon, Sep 22, 2014 at 11:42 AM, Charles Butler
 charles.but...@canonical.com wrote:

 http://blog.dasroot.net/juju-digital-ocean-awesome/

 Juju on Digital Ocean, WOW! That's all I have to say. Digital Ocean is
 one of the fastest cloud hosts around with their SSD backed virtual
 machines. To top it off their billing is a no-nonsense straight forward
 model. $5/mo for their lowest end server, with 1TB of included traffic.
 That's enough to scratch just about any itch you might have with the 
 cloud.

 Speaking of scratching itches, if you haven't checked out Juju yet, now
 you have a prime, low cost cloud provider to toe the waters. Spinning up
 droplets with Juju is very straight forward, and offers you a hands on
 approach to service orchestration thats affordable enough for a weekend
 hacker to whet their appetite. Not to mention, Juju is currently the #1
 project on their API Integration listing! http://goo.gl/m6u781

 In about 11 minutes, we will go from zero to deployed infrastructure for
 a scale-out blog (much like the one you're reading right now).


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




 --
 [ Adam Stokes ]



-- 
[ Adam Stokes ]

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

Re: juju as a web service

[Adam Stokes]

We also have a python3 version hosted at:

https://github.com/Ubuntu-Solutions-Engineering/macumba

It's what Ubuntu Openstack Installer is switching to for its internal
juju communication.

On Wed, Jul 9, 2014 at 9:28 AM, Mark Shuttleworth m...@ubuntu.com wrote:
 On 09/07/14 13:52, Andrew Wilkins wrote:
 Juju has a websocket API that you can use to perform the same operations as
 the CLI can.

 There are Go and Python client APIs. The Go one is in the core repository,
 and the Python one is here: https://launchpad.net/python-jujuclient

 Batteries included. No extra charge :)

 Mark

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



-- 
[ Adam Stokes ]

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

Re: python-django charm with subordinate app - help needed

[Adam Stokes]

I did something like this though I didnt use the python-django charm

https://github.com/battlemidget/juju-apache-gunicorn-django

You may be able to get some ideas from that

On Sun, Jun 8, 2014 at 11:32 PM, Tim Penhey tim.pen...@canonical.com wrote:
 Hi all,

 I'm looking at using the subordinate charm method for delivering the app
 payload to the python-django charm.

 From the pyton-django readme:

 When you add a relation between your charm and the python-django
 charm, you will be able to get those relation variables from the
 hook:

   settings_dir_path
   urls_dir_path
   django_admin_cmd
   install_root

 Now your charm will be informed about where it needs to add new
 settings and urls files and how to run additionnal Django commands.
 The Django charm reloads Gunicorn after the relation to catch the
 changes.

 Unfortunately the doc doesn't explain what I need to put where.

 Lets say I have my django application in revision control, but it isn't
 public (because it will be SAAS :-).  It follows pretty standard django
 format, and testing wise I just use: ./manage.py runserver

 I have a settings file, and urls, and dependencies that I use a virtual
 environment and a pip requirements.txt file for.

 I'm thinking that I should have the install and upgrade hook use pip to
 install the requirements.  It seems that the current python-django charm
 isn't yet set up to handle virtual environments, is that right?

 How then do I hook up the database for example?  I have settings in my
 current settings.py, but this will clearly be superseded by the
 relationship between python-django and postgresql.

 Are there examples I could look at for existing charms that do this type
 of thing?

 Any help greatly appreciated.

 Cheers,
 Tim



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



-- 
[ Adam Stokes ]

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

Re: juju-nat

[Adam Stokes]

lxc-use-clone was only introduced into 1.18.3 (only available through
the juju stable PPA). Could you provide an output of dpkg -l|grep
juju?

For example my output looks like the following:

┌[adam@bigboi] [/dev/pts/21] [stable]
└[~/Projects/cloud-installer-bm] cat ~/.juju/environments.yaml
default: local

environments:
  local:
type: local
container: kvm
lxc-use-clone: true
┌[adam@bigboi] [/dev/pts/21] [stable]
└[~/Projects/cloud-installer-bm] dpkg -l|grep juju
ii  juju-core
1.18.3-0ubuntu1~14.04.1~juju1   amd64Juju
is devops distilled - client
ii  juju-local
1.18.3-0ubuntu1~14.04.1~juju1   all
dependency package for the Juju local provider
ii  juju-mongodb
2.4.9-0ubuntu3  amd64
MongoDB object/document-oriented database for Juju

On Tue, Jun 3, 2014 at 1:35 PM, brian mullan bmullan.m...@gmail.com wrote:
 It is the latest 1.18.3.1



 On Tue, Jun 3, 2014 at 1:25 PM, Adam Stokes adam.sto...@ubuntu.com wrote:

 Need to make sure you're using juju 1.18.3 or higher

 On Tue, Jun 3, 2014 at 1:16 PM, brian mullan bmullan.m...@gmail.com
 wrote:
  Kapil
 
  Ubuntu 14.04 server x64 bit
 
  juju configured in local provider mode.
 
  deployed juju-gui (in container)
 
  Although I am pretty sure I had nginx setup correctly to reverse proxy
  juju-gui running in an lxc container I went ahead and created a new
  server,
  installed juju, juju-gui to try it out.
 
  Then installed  configured juju-nat
 
  Finally, running:
  $ juju nat-expose juju-gui/0
 
  I just get 3 warning messages:
 
  WARNING juju. environs.config config.go.912 unknown config.field
  lxc-use-clone
  WARNING juju. environs.config config.go.912 unknown config.field
  lxc-use-clone
  WARNING juju. environs.config config.go.912 unknown config.field
  lxc-use-clone
 
 
 
 
  --
  Juju mailing list
  Juju@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju
 



 --
 [ Adam Stokes ]





-- 
[ Adam Stokes ]

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

Filing SRU's

[Adam Stokes]

Just to get some clarification -- are we handling juju updates within
the archive through the normal SRU processes? It was mentioned that
there may be an exception for juju-core but wanted to make sure before
I go through with patching the existing package (1.18.1 at the time of
this writing).

Thanks!

-- 
[ Adam Stokes ]

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

Re: Questions about the integration of the Outscale cloud provider into juju-core

[Adam Stokes]

I'd probably start here:

http://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/provider/

This can give you an idea on how the ec2 implementation is done

On Mon, May 5, 2014 at 10:56 AM, Benoît Canet benoit.ca...@irqsave.net wrote:

 Hello,

 I am a developper planning to add the support for the Outscale cloud into
 juju-core.

 The Outscale cloud implement most of the EC2 API.

 Does the Juju maintainer have some guidance on how the support should be
 written ?

 Best regards

 Benoît Canet
 Nodalink

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



-- 
[ Adam Stokes ]

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

Re: New Juju Plugin: git-deploy

[Adam Stokes]

Im probably missing something but I dont see where juju-git-charm
actually handles the deploying? Where as Francesco's plugin interacts
directly with the api server to handle the deploying of charms.

On Tue, Apr 8, 2014 at 10:33 AM, Joshua Strobl truthfroml...@gmail.com wrote:
 You clearly didn't see the juju-git-charm, which deploys and manages charms
 through git, and it isn't limited to GitHub.

 On Apr 8, 2014 10:52 AM, Francesco Banconi
 francesco.banc...@canonical.com wrote:


 On 08 Apr 2014, at 00:35, Joshua Strobl truthfroml...@gmail.com wrote:

  I already created a plugin, not sure why it was created again. It is
  over at Juju Plugins:
 
  https://github.com/juju/plugins

 I don't see anything equivalent or similar there.

 --
 Francesco





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




-- 
[ Adam Stokes ]

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

Re: New Juju Plugin: git-deploy

[Adam Stokes]

I think it would be cool if that was utilizing the existing code by
Kapil for the api interactions:

https://launchpad.net/python-jujuclient

On Mon, Apr 7, 2014 at 12:03 PM, Jorge O. Castro jo...@ubuntu.com wrote:
 Hi everyone:

 Francesco Banconi has whipped up a new plugin:

 https://github.com/frankban/juju-git-deploy

 It's designed to deploy charms from github. Testing and feedback wanted!



 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

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



-- 
[ Adam Stokes ]

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

Re: JuJu, LXC, OpenStack charm problem w/Nova Quantum

[Adam Stokes]

I also think that nova and lxc do not mingle well either. I've
typically deployed nova in a kvm instance instead

On Sat, Mar 15, 2014 at 1:26 PM, John Meinel j...@arbash-meinel.com wrote:
 I'm pretty sure Quantum can't be deployed in LXC because it needs direct
 access to block devices. I could be wrong.

 John
 =:-

 On Mar 15, 2014 2:08 PM, brian mullan bmullan.m...@gmail.com wrote:

 I thought I'd try using some of the cool new stuff.. so with latest lxc
 1.0 JuJu  JuJu-gui installed I decided to look at JuJu Bundles.

 I set my environment to local and started the OpenStack bundle.

 Everything eventually turns green except:

 Nova-Compute
 Quantum-Gateway

 Which stay in a red state and provide a message that the charm had failed
 hooks.

 Just out of curiousity has anyone else tried to do this yet ?

 I believe the problem is related to how openstack requires addressing
 setup for nova ( probably quantum) but not sure how to troubleshoot the
 charm further myself.

 Thanks

 Brian Mullan
 Raleigh NC

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




-- 
[ Adam Stokes ]

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

Re: juju api and authenticated request

[Adam Stokes]

On Tue, Feb 11, 2014 at 3:22 PM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
 hybi-13 is the rfc version. the library jujuclient is using also has a
 python3 variant.


I guess my question is what version of the websocket spec is supported
in the juju api server? Any attempt to make a connection using a
websocket library specifically for RFC 6455 fails to make a
connection. I can see where the connection gets upgraded to a
websocket connection but juju is always returning a 403 forbidden
before I have a chance to pass in the authentication credentials.

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

Re: juju api and authenticated request

[Adam Stokes]

Also looking at the websocket code from go.net/websocket it looks like
all older versions of the protocol were dropped in Dec 2013.
Unfortunately, my go knowledge is limited and Im not sure how to tell
which version of the websocket library is being used. I see the
protocol version in the upstream code now as well:

ProtocolVersionHybi  = ProtocolVersionHybi13

Do the latest libraries like go.net/websocket get pulled in during each release?

On Thu, Feb 13, 2014 at 7:16 PM, Adam Stokes adam.sto...@ubuntu.com wrote:
 On Tue, Feb 11, 2014 at 3:22 PM, Kapil Thangavelu
 kapil.thangav...@canonical.com wrote:
 hybi-13 is the rfc version. the library jujuclient is using also has a
 python3 variant.


 I guess my question is what version of the websocket spec is supported
 in the juju api server? Any attempt to make a connection using a
 websocket library specifically for RFC 6455 fails to make a
 connection. I can see where the connection gets upgraded to a
 websocket connection but juju is always returning a 403 forbidden
 before I have a chance to pass in the authentication credentials.



-- 
[ Adam Stokes ]

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

Re: juju api and authenticated request

[Adam Stokes]

Got it working for anyone curious:

http://paste.ubuntu.com/6910254/

On Mon, Feb 10, 2014 at 1:02 PM, Adam Stokes adam.sto...@ubuntu.com wrote:
 I tried a python3 variant that uses ws4py which is RFC 6455 compliant
 and can not seem to get the login to work:

 # OUtput
 connection opened

 {'RequestId': 1, 'Response': {}}


 # Code
 #!/usr/bin/python3


 from ws4py.client.threadedclient import WebSocketClient
 from pprint import pprint
 import json

 params = {}
 params['Type'] = Admin
 params['Request'] = 'Login'
 params['RequestId'] = 1
 params['Params'] = { 'AuthTag' : 'user-admin', 'Password':
 'f0d44f279b47cc8b5f7ea291f5e3b30a'}

 class DummyClient(WebSocketClient):
 def opened(self):
 print(connection opened)
 self.send(json.dumps(params))

 def closed(self, code, reason):
 print (Closed down, code, reason)

 def received_message(self, m):
 pprint(json.loads(m.data.decode('utf-8')))
 return m

 if __name__ == '__main__':
 try:
 ws = DummyClient('wss://192.168.122.16:17070/',
 protocols=['https-only'])
 ws.connect()
 #info = {'Type': 'Client',
 #'Request': 'EnvironmentInfo'}
 #ws.send(json.dumps(info))
 except KeyboardInterrupt:
 ws.close()


 The library that Kapil uses in the jujuclient only supports hybi-13.
 So I'm curious if juju supports anything beyond that?

 --
 [ Adam Stokes ]



-- 
[ Adam Stokes ]

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