Re: Using Deb Proxy to cache Debs to minimize time starting-up machines and its installation scripts

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

Re: lost reviews

I *believe* a database dump of the reviewboard site was kept but the site was taken down as it wasn't being used. Juju QA folks may be able to shed more light. On 25 May 2017 at 01:44, roger peppe wrote: > Despite my plea (quoted below) it seems that our reviewboard

Re: Using Deb Proxy to cache Debs to minimize time starting-up machines and its installation scripts

Hi Naz, I use squid-deb-proxy to speed up deployments and it works well. If you're using the lxd provider install the proxy on the host machine so that all controllers and models benefit from the packages cached during previous deployments. Ensure that squid-deb-proxy is configured to listen on

Re: Is it possible to return management to Juju after manual provision of a machine?

Hi NAZ, Like Andrew already pointed out, you can issue `juju deploy your-charm --to 9` to run your charms. Then on the juju CLI side, use `juju debug-log` to get a running debug log. Whatever the charm error is, you should see it flashing across the screen. Also, hooks and states will be

Re: Is it possible to return management to Juju after manual provision of a machine?

Hi NAZ, Like Andrew already pointed out, you can issue `juju deploy your-char --to 9` to run your charms. Then on the juju CLI side, use `juju debug-log` to get a running debug log. Whatever the charm error is, you should see it flashing across the screen. Also, hooks and states will be run

Re: Command Completion Not working? --SOLVED

On 3 July 2017 at 19:55, N. S. wrote: > I quote what I replied to this thread the second day. > > "After the refresh of the snap, issue is solved" > ​Sorry, I didn't see this before I replied. My mail reader split the thread in two. I'm glad you got it sorted out. -

Re: Command Completion Not working? --SOLVED

Hi Menno, Thank you for your followup. This issue was solved. I am sorry, I don't recall the exact scenario. But I think it was : sudo apt install juju. Certainly, NOT a build from source. But, I remember that I removed JUJU by sudo apt remove juju and re-installed it using snap and done

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

URE > Jun 28 19:54:34 ns-HP systemd[1]: Failed to start Mount ZFS filesystems. > Jun 28 19:54:34 ns-HP systemd[1]: zfs-mount.service: Unit entered failed > state. > Jun 28 19:54:34 ns-HP systemd[1]: zfs-mount.service: Failed with result > 'exit-code'. > ns@ns-HP:/usr/src/linux-he

Re: Command Completion Not working?

HI NS, Can you tell us how you installed the Juju client? Was it via conventional Ubuntu updates (i.e. a deb package), the snap release (i.e. `snap install juju`) or did you build it yourself? Regards, Menno On 29 June 2017 at 00:38, N. S. wrote: > Hi Juju team, > > > I

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

probe zfs modprobe: FATAL: Module zfs not found in directory /lib/modules/4.8.0-040800-lowlatency root@ns-HP:~# I know this might be not directly related to JUJU, but to ubuntu kernel, but I appreciate if you could help. Thanks, BR, NS Nicholas Skaggsnicholas.skaggs at canonical.com<mail

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

nical.com<mailto:juju%40lists.ubuntu.com?Subject=Re%3A%20Running%20KVM%20in%20addition%20to%20LXC%20on%20local%20LXD%20CLOUD=%3CCAHNOz3oXQF4t2x5Rz6R5P-zfuQ651PPJSJEQRf9Er-ZW_3pE4Q%40mail.gmail.com%3E> Tue Jun 27 19:51:08 UTC 2017 If it's possible, I would simply run the hwe kernel on xenial which pro

Re: [ANN] Virtual Docs Sprint - The charms.reactive framework - on 30 June 2017

We've wrapped up our second Virtual Docs sprint, this time focusing on charms.reactive. General topics discussed: - Monitoring Ask Ubuntu, Reddit, etc., for charms.reactive-related questions. As an experiment, we've created an IFTTT applet to create new issues in Github for new questions

Re: [ANN] Virtual Docs Sprint - The charms.reactive framework - on 30 June 2017

We've wrapped up our second Virtual Docs sprint, this time focusing on charms.reactive. General topics discussed: - Monitoring Ask Ubuntu, Reddit, etc., for charms.reactive-related questions. As an experiment, we've created an IFTTT applet to create new issues in Github for new questions

Re: juju enable-ha with lxd servers

Are these 3 LXD containers on one machine, or 3 different host machines where you want to run LXD containers? At present we don't support scheduling across LXD hosts, so the easier way would probably be to treat 3 host machines as separate 'manually provisioned' machines, and then deploy to

Re: Is it possible to return management to Juju after manual provision of a machine?

On Fri, Jun 30, 2017 at 7:39 AM N. S. wrote: > Hi, > > Excuse me if this seems a strange scenario. > > My scenario is as follows: > > I have a charm that has lots of problems in its install script, needs > massive change (NOT SURE how to fix it) > > So, > > I added an empty

Re: Command Completion Not working? --SOLVED

Awesome, glad you got it worked out and things nice and up to date with 2.2 On Wed, Jun 28, 2017 at 7:30 PM N. S. wrote: > Hi, > > Sorry > False Alarm. > > There is something wrong , especially that version reads 2.0.2! > > After the refresh of the snap, issue is

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

root@ns-HP:~*# /sbin/modprobe zfs* > modprobe: FATAL: Module zfs not found in directory > /lib/modules/4.8.0-040800-lowlatency > root@ns-HP:~# > > > > I know this might be not directly related to JUJU, but to ubuntu kernel, > but I appreciate if you could help. > > &

Re: Command Completion Not working? --SOLVED

Hi, Sorry False Alarm. There is something wrong , especially that version reads 2.0.2! After the refresh of the snap, issue is solved. Thanks BR NS On Jun 28, 2017 5:38 PM, "N. S." wrote: Hi Juju team, I am upgraded my juju platform to latest release: ~$ juju

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

If it's possible, I would simply run the hwe kernel on xenial which provides 4.8+. Read more about running an updated stack here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack This would solve your specific problem without worrying about running kvm's. On Jun 24, 2017 11:14 PM, "N. S."

Re: Juju vs Openshift

Juju doesn't have to be responsible for translating the model into the underlying substrate. The Charms have always been responsible for interpreting the model. t's the Charms that figure out what it actually means to "connect Wordpress to MySQL". This has allowed Charms to become very smart,

Re: Juju vs Openshift

I think the reason it's challenging, and that you're seeing different tools for different systems, is that each time you want to model something you have to make sure you can translate the model into the underlying substrates clearly and precisely. To date, Juju hasn't expressed a model on the

Re: Juju vs Openshift

OK, but since I have been asked to help prepare a roadmap for the next 3 years for the evolution of cloud services and infrastructure for the Italian public administrations, I need to have both a clear picture of the current situation and to make an educated guess at the most promising

Re: Juju vs Openshift

I found this quick comparison between Openshift and Kubernetes: https://medium.com/levvel-consulting/the-differences-between-kubernetes-and-openshift-ae778059a90e It points out that

Re: Juju vs Openshift

Hi Giuseppe On Tue, Jun 27, 2017 at 9:32 AM Giuseppe Attardi wrote: > Some Italian public administration are considering purchasing cloud > services for Big Data analytics deployed on Openshift. > How this solution would compare with using a Kubernetes cluster deployed

Re: Juju vs Openshift

Hey Giuseppe Having worked in the data sector for a while now whilst keeping an eye on container tech, for now at least I'd keep deploying data services to baremetal for a number of reasons, docker container discovery for one. Juju hadoop on services vs hadoop on containers is a bit of a

Re: Consuming MongoDB from a Snap

Hi everybody, Thanks for highlighting this in a public thread. Before switching to snaps, please consider mongodb lifetime as snapd does not give you any strict lifetime guarantees as of now: 1. it will try to stop a service on update; 2. will send SIGTERM if that timed out; 3. if processes in

Re: Juju Digest, Vol 77, Issue 21

26 Jun 2017 12:13:10 +0300 > From: Dmitrii Shcherbakov <dmitrii.shcherba...@canonical.com> > <dmitrii.shcherba...@canonical.com> > To: Merlijn Sebrechts <merlijn.sebrec...@gmail.com> > <merlijn.sebrec...@gmail.com> > Cc: juju <juju@lists.ubuntu.com> &

Re: Juju Digest, Vol 77, Issue 21

On 26/6/2017 14:00, juju-requ...@lists.ubuntu.com wrote: Date: Mon, 26 Jun 2017 12:13:10 +0300 From: Dmitrii Shcherbakov<dmitrii.shcherba...@canonical.com> To: Merlijn Sebrechts<merlijn.sebrec...@gmail.com> Cc: juju<juju@lists.ubuntu.com> Subject: Re: Italian federated cloud

Re: Upgrading juju2

On 13/06/17 04:25, Mario Splivalo wrote: > Hi, ladies and lads! > > I am verifying the juju upgrade procedure and I ran into some > ‘misunderstandings’ which I’m hoping could be clarified out here. > > I am running juju 2.0.0 and the plan is to upgrade it to the latest 2.1 > version, which is

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

On Sat, Jun 24, 2017 at 9:14 PM N. S. wrote: > Hi, > > > I am running 10 machines on local LXD cloud, and it's fine. > > My host is Ubuntu 16.04, kernel 4.4.0-81. > > However, I have the following challenge: > One of the machines (M0) stipulates a kernel 4.7+ > > > As it's

Re: We are excited to announce the release of Juju 2.2.1!

Yes indeed. Congratulations to the whole team. Tim On 23/06/17 23:35, Ante Karamatić wrote: > Congrats! > > Excellent release and some of our high profile users are already on > 2.2.1 as of now. The fact that one can just upgrade big > environments like that, while drinking coffee, speaks

Re: We are excited to announce the release of Juju 2.2.1!

Yes indeed. Congratulations to the whole team. Tim On 23/06/17 23:35, Ante Karamatić wrote: > Congrats! > > Excellent release and some of our high profile users are already on > 2.2.1 as of now. The fact that one can just upgrade big > environments like that, while drinking coffee, speaks

Re: Consuming MongoDB from a Snap

On Fri, Jun 23, 2017 at 10:36 AM, Menno Smits wrote: > > > On 23 June 2017 at 12:09, Andrew Wilkins > wrote: > >> >>> *1. Does snapd work on all architectures that Juju supports?* >>> >>> The answer appears to be "yes with some caveats".

Re: We are excited to announce the release of Juju 2.2.1!

Congrats! Excellent release and some of our high profile users are already on 2.2.1 as of now. The fact that one can just upgrade big environments like that, while drinking coffee, speaks volumes! On Fri, Jun 23, 2017 at 7:17 AM Burton Swan wrote: > This release

Re: Consuming MongoDB from a Snap

У пет, 23. 06 2017. у 00:09 +, Andrew Wilkins пише: > > One issue would be upgrades: we would either have to continue > supporting both snaps and debs for mongodb, or we would have to > disallow upgrading from a system that doesn't support snaps. That > would OK as long as there are no

Re: Consuming MongoDB from a Snap

On 23 June 2017 at 12:25, Michael Hudson-Doyle wrote: > >>> The answer appears to be "yes with some caveats". For xenial onwards >>> there are snapd packages for all the architectures the Juju team cares >>> about. >>> >> >> Ah, I thought the question was rather

Re: Consuming MongoDB from a Snap

On 23 June 2017 at 12:09, Andrew Wilkins wrote: > >> *1. Does snapd work on all architectures that Juju supports?* >> >> The answer appears to be "yes with some caveats". For xenial onwards >> there are snapd packages for all the architectures the Juju team cares >>

Re: Consuming MongoDB from a Snap

On 23 June 2017 at 12:09, Andrew Wilkins wrote: > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits > wrote: > >> We've had some discussion this week about whether Juju could use MongoDB >> from snap instead of a deb. This would make it easier

Re: Consuming MongoDB from a Snap

On Fri, Jun 23, 2017 at 7:47 AM Menno Smits wrote: > We've had some discussion this week about whether Juju could use MongoDB > from snap instead of a deb. This would make it easier for Juju to stay up > to date with the latest MongoDB releases, avoiding the involved

Re: Network Spaces Issues with LXD on Juju 2.2

You might be hitting https://bugs.launchpad.net/juju/+bug/1698443 cheers, peter. On 22.06.17 16:15, Subhranshu Dwivedi wrote: > Hi Team, > > I am trying to install openstack using bundle.yaml, on MaaS 2,0, with > network spaces using Juju .2.2, > > Now the problem is that Lxd containers are

Re: How to pass a value from @when code to a relation?

Hi, A relation is a good way to pass data between the related charms. If you could share a toy-example of your code we might be able to offer more assistance. Thank you, Konstantinos On Wed, Jun 21, 2017 at 10:33 PM, fengxia wrote: > Hi Juju, > > I'm designing an

Re: docker -> lxdbr0

It really does ... don't know why I didn't just add the extra file. I've fixed this. Thanks! > On Jun 21, 2017, at 6:32 AM, John Meinel wrote: > > Gotcha. Though I will say that looks more like its a bogus comment about a > file that this isn't. But I see what you're

Re: docker -> lxdbr0

It really does ... don't know why I didn't just add the extra file. I've fixed this. Thanks! > On Jun 21, 2017, at 6:32 AM, John Meinel wrote: > > Gotcha. Though I will say that looks more like its a bogus comment about a > file that this isn't. But I see what you're

Re: docker -> lxdbr0

Gotcha. Though I will say that looks more like its a bogus comment about a file that this isn't. But I see what you're doing. John =:-> On Wed, Jun 21, 2017 at 5:29 PM, James Beedy wrote: > It's in the comments at the top of the gist. > > On Jun 20, 2017, at 10:31 PM,

Re: docker -> lxdbr0

Gotcha. Though I will say that looks more like its a bogus comment about a file that this isn't. But I see what you're doing. John =:-> On Wed, Jun 21, 2017 at 5:29 PM, James Beedy wrote: > It's in the comments at the top of the gist. > > On Jun 20, 2017, at 10:31 PM,

Re: docker -> lxdbr0

It's in the comments at the top of the gist. > On Jun 20, 2017, at 10:31 PM, John Meinel wrote: > > This definitely sounds interesting. > > You included the layer python code, but not the "daemon.json.j2" file. Isn't > that part of getting the networking config in

Re: docker -> lxdbr0

It's in the comments at the top of the gist. > On Jun 20, 2017, at 10:31 PM, John Meinel wrote: > > This definitely sounds interesting. > > You included the layer python code, but not the "daemon.json.j2" file. Isn't > that part of getting the networking config in

Re: is Hdp bundle still maintained/supported?

Hi Patrizio, Network resolvability of Hadoop cluster nodes is a painful requirement at times. We test to catch issues like this on clouds/containers, but it sounds like we've missed an openstack case. If you don't mind, please describe the failing environment and your /etc/hosts fix in an issue

Re: is Hdp bundle still maintained/supported?

Hi Patrizio, My recommendation is that you go to the freenode channel #juju, and then talk to Kevin (kwmonroe, also cced). He has a lot of wits on these solutions and will be able to help you, tell you where report bugs and also see if there is a potential implementation path for your issues

Re: docker -> lxdbr0

This definitely sounds interesting. You included the layer python code, but not the "daemon.json.j2" file. Isn't that part of getting the networking config in place? John =:-> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy wrote: > On integrating docker and lxd deployed

Re: New releases of Juju 2.2.0 and conjure-up 2.2.0 are here!

On Thu, Jun 15, 2017 at 1:05 AM, Burton Swan wrote: > We are excited to announce the release of Juju 2.2.0 and conjure-up 2.2.0! > This release greatly enhances memory and CPU utilisation at scale, improves > the modelling of networks, and adds support for KVM

Re: is Hdp bundle still maintained/supported?

Dear Samuel i deployed the hadoop-processing bundle successfully. I had some troubles because openstack instances didn't get the dns entry so hadoop-hdfs-namenode/datanode could not resolve their own addresses first, then the peers'. I did a fast hack just manually adding the entries in

Re: multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

Marco, i totally agree with you: i do not want to manage them manually, John's suggestion is great but it's very last chance. Regarding cross model relations i'm very interested, I can't upgrade to juju 2.2 immediately (i'm in 2.1.2 now) but as soon as possibile i'll give a try. Regarding multi

Re: multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

I'd got one step further and say cross model relations are exactly what you're looking to do. I'd avoid using manual machine additions because it's really not a first class experience. In 2.2 cross model relations have matured quite a bit, there are still some limitations, but it might be worth

Re: multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

If you have started the machine yourself, you should be able to "juju add-machine ssh:IP_ADDRESS" and then use that as a "juju deploy --to X" target. However, you will still need to tear down the machine when you're done. We don't yet support multi-provider models. Likely we won't, but we will

Re: is Hdp bundle still maintained/supported?

Hi Samuel, thank you for fast and honest reply. I will start to take a look at hadoop-processing bundle. Regards, Patrizio 2017-06-16 9:54 GMT+02:00 Samuel Cozannet : > Hi Patrizio, > > Thanks for reaching out. There is a list of more recent charms based on > Big

Re: is Hdp bundle still maintained/supported?

Hi Patrizio, Thanks for reaching out. There is a list of more recent charms based on Big Top here: https://jujucharms.com/q/bigtop?type=charm The current strategy is to focus on big top, so products from Hortonworks are no longer supported as you could notice. The team to track is here :

Re: [ANNOUNCEMENT] Virtual Juju Docs Sprint #1

Won't be able to make it, but this is a good initiative! 2017-06-16 0:17 GMT+02:00 Adam Israel : > Hi all, > > I'm announcing that we're holding our first Virtual Juju Docs Sprint > tomorrow from 18-19:00 GMT (14-15:00 EDT). This will be a bi-weekly event > where

Re: [ANNOUNCEMENT] Virtual Juju Docs Sprint #1

Won't be able to make it, but this is a good initiative! 2017-06-16 0:17 GMT+02:00 Adam Israel : > Hi all, > > I'm announcing that we're holding our first Virtual Juju Docs Sprint > tomorrow from 18-19:00 GMT (14-15:00 EDT). This will be a bi-weekly event > where

Re: Maximum AllWatcher frame size?

Wouldn't that feel like a breach of contract where the first response is supposed to get you in sync with the system? I could definitely see doing a different code path for the first response because you know there aren't any objects you have to compare against, etc. Or because you can reasonably

Re: juju deploy with a series

The patch and instructions are listed here: https://github.com/juju/juju/pull/6954 We didn't go this route. In our project, we ended up using MAAS to provision CentOS node to test charms. On 06/15/2017 10:51 PM, fengxia wrote: +1 On 06/15/2017 10:47 PM, Andrew Wilkins wrote: On Fri, Jun

Re: juju deploy with a series

+1 On 06/15/2017 10:47 PM, Andrew Wilkins wrote: On Fri, Jun 16, 2017 at 1:36 AM John Meinel > wrote: "juju show-machine 10" is likely to tell you why we are failing to provision the machine. My guess is that we acctually

Re: juju deploy with a series

There was a bug filed back in 2015: https://bugs.launchpad.net/juju/+bug/1495978 It has information on how to make a work around to run CentOS in LXD. On 06/15/2017 12:37 PM, Daniel Bidwell wrote: I am trying to deploy a charm that I am writing for both ubuntu and centos. "lxc image alias

Re: juju deploy with a series

On Fri, Jun 16, 2017 at 1:36 AM John Meinel wrote: > "juju show-machine 10" is likely to tell you why we are failing to > provision the machine. > > My guess is that we acctually need the alias to be "juju/centos7/amd64" > for Juju to recognize that it is the container

Re: juju deploy with a series

John, There are multiple issues with this since we have just gone through a similar effort: 1. LXD does not support CentOS image. 2. Default "charm build" will produce a dist that will not run on CentOS, even with "--series centos7". On 06/15/2017 01:34 PM, John Meinel wrote: "juju

Re: juju deploy with a series

"juju show-machine 10" is likely to tell you why we are failing to provision the machine. My guess is that we acctually need the alias to be "juju/centos7/amd64" for Juju to recognize that it is the container image we want to be starting. John =:-> On Thu, Jun 15, 2017 at 8:37 PM, Daniel

Re: Maximum AllWatcher frame size?

On 14 June 2017 at 17:14, Cory Johns wrote: > So, I'm not sure if this resolves the issue. The python websockets library > supports fragmented messages but I think that is separate from the maximum > message size that it's enforcing. I think that maximum is for the

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

Your best bet right now is to back up the data for the application/unit, deploy a fresh application and/or units and restore the data into the new instance. How you do this is of course dependent on the application. On 14 June 2017 at 23:38, Rick Harding wrote: > Not

Re: Maximum AllWatcher frame size?

So, I'm not sure if this resolves the issue. The python websockets library supports fragmented messages but I think that is separate from the maximum message size that it's enforcing. I think that maximum is for the final payload, which would be the entire AllWatcher JSON response. If the

Re: Maximum AllWatcher frame size?

Do we know what size the gorilla/websocket library uses for automatic chunking? On Wed, Jun 14, 2017 at 11:35 AM, John Meinel wrote: > In 2.1 we did not chunk, in 2.2 we switch to gorilla/websocket which does > support chunking into frames. I don't think we do any

Re: Maximum AllWatcher frame size?

In 2.1 we did not chunk, in 2.2 we switch to gorilla/websocket which does support chunking into frames. I don't think we do any internal "well that would be too much information so we wont send it all". John =:-> On Wed, Jun 14, 2017 at 7:11 PM, Cory Johns wrote: >

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

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

Re: killing old dead controllers

If the machines are just gone (you manually destroyed them via 'lxc stop/delete'). You can just do: juju unregister lxd-test It will remove it from the local registry without trying to tear anything down. John =:-> On Tue, Jun 13, 2017 at 8:17 AM, Daniel Bidwell wrote:

Re: killing old dead controllers

If the machines are just gone (you manually destroyed them via 'lxc stop/delete'). You can just do: juju unregister lxd-test It will remove it from the local registry without trying to tear anything down. John =:-> On Tue, Jun 13, 2017 at 8:17 AM, Daniel Bidwell wrote:

Re: Best practice in giving lxd containers routable IP addresses

Hi Daniel, When going through the network setup for lxd as outlined[0] in the "Walkthrough of network configuration" section. You can set the "Bridge interface name" to the primary interface on the host. Your lxc profile should look as follows, where "br0" is the interface name of the host. ```

Re: Juju 2.2-rc2 has been released

Yes, and this too has been corrected. You should expect releases to flow down to level of risk. So, when 2.2 releases, beta, candidate and stable will all point to the 2.2 revision (until the first beta for 2.3, and so on). channels: latest/stable:2.1.3 (1922) 24MB

Re: Juju 2.2-rc2 has been released

Nicholas, Thanks. beta is still 2.2rc1. Should it be 2.2rc2 also? Jason On Mon, Jun 12, 2017 at 11:15 AM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > Thanks for the heads-up Jason. Yes, small snafu with publishing the > builds. Edge builds are tracking develop (2.3-alpha1) and

Re: Juju 2.2-rc2 has been released

Nicholas, Thanks. beta is still 2.2rc1. Should it be 2.2rc2 also? Jason On Mon, Jun 12, 2017 at 11:15 AM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > Thanks for the heads-up Jason. Yes, small snafu with publishing the > builds. Edge builds are tracking develop (2.3-alpha1) and

Re: Juju 2.2-rc2 has been released

Thanks for the heads-up Jason. Yes, small snafu with publishing the builds. Edge builds are tracking develop (2.3-alpha1) and now are being published again. Nicholas On 06/12/2017 11:18 AM, Jason Hobbs wrote: I noticed that for the juju snap, edge and beta channels have older releases than

Re: Juju 2.2-rc2 has been released

I noticed that for the juju snap, edge and beta channels have older releases than candidate. Shouldn't they always be at least the same version as candidate, if not newer? stable:2.1.3 (1922) 24MB classic candidate: 2.2-rc2 (1929) 25MB classic beta:

Re: Juju 2.2-rc2 has been released

I noticed that for the juju snap, edge and beta channels have older releases than candidate. Shouldn't they always be at least the same version as candidate, if not newer? stable:2.1.3 (1922) 24MB classic candidate: 2.2-rc2 (1929) 25MB classic beta:

Re: Juju 2.2-rc2 has been released

Simon, That was my mistake, I forgot to click release on that. conjure-up-rc2-20170612 is now available on the candidate channel. On Fri, Jun 9, 2017 at 8:06 PM, Simon Kollberg wrote: > conjure-up still seem to be on rc1 > > % sudo snap install conjure-up

Re: Juju-dev Digest, Vol 61, Issue 10

> juju-dev-requ...@lists.ubuntu.com > > You can reach the person managing the list at > juju-dev-ow...@lists.ubuntu.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Juju-dev digest..." > > >

Re: Juju 2.2-rc2 has been released

conjure-up still seem to be on rc1 % sudo snap install conjure-up --classic --candidate conjure-up (candidate) 2.2-rc1-20170606.0106 from 'canonical' installed % juju --version 2.2-rc1-xenial-amd64 % conjure-up --version conjure-up 2.2-rc1 % sudo snap remove conjure-up conjure-up removed % sudo

Re: Juju 2.2-rc2 has been released

On Fri, Jun 9, 2017 at 12:29 PM, Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Quick instructions on how the new azure credentials flow works in Juju > 2.2-RC2: > > # install az client using a snap > $ sudo snap install azure-cli --classic --edge > I've pushed the snap to stable, so

Re: Juju 2.2-rc2 has been released

On Fri, Jun 9, 2017 at 12:29 PM, Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Quick instructions on how the new azure credentials flow works in Juju > 2.2-RC2: > > # install az client using a snap > $ sudo snap install azure-cli --classic --edge > I've pushed the snap to stable, so

Re: Juju 2.2-rc2 has been released

Quick instructions on how the new azure credentials flow works in Juju 2.2-RC2: # install az client using a snap $ sudo snap install azure-cli --classic --edge # login to azure $ az login # install latest 2.2-rc2 Juju $ sudo snap install juju --classic --candidate # verify version $ juju

Re: How to count relations?

On Thu, Jun 8, 2017 at 2:38 PM, Cory Johns wrote: > Alex, > > I should clarify, conv.scope should only be None if the class's scope is > GLOBAL. Otherwise, it should be the name of the service or unit. If the > scope is defined as SERVICE or UNIT and the conv.scope is

Re: Does relation scopes need to match?

The original intention of conversations and scopes was to simply certain interface interaction patterns where it may not be relevant or useful on your end of the relation to deal with each remote unit individually. An example might be if the remote service is expected to have a leader which

Re: Is base64 really the best way to use complex config values

On 08.06.2017 13:39, Stuart Bishop wrote: > It is only popular because people keep cargo culting it > into their charms when it is unnecessary. I always call it out in > reviews and get people to switch to unencoded text. On the topic of cargo-culting. I'm re-writing a charm right no

Re: How to count relations?

Alex, I should clarify, conv.scope should only be None if the class's scope is GLOBAL. Otherwise, it should be the name of the service or unit. If the scope is defined as SERVICE or UNIT and the conv.scope is None, it was a bug, yes (but let's work to get rid of the confusing idea of scopes and

Re: Is base64 really the best way to use complex config values

On 7 June 2017 at 23:22, Tilman Baumann wrote: > I see a lot of charms use base64 values in config parameters. Especially > when the values are stuff like custom templates. > > Is this really the way to go? It may avoid shell quoting hell for > parameters set via

Re: Is base64 really the best way to use complex config values

Hi Tilman Just wanted to lend a +1 to this. Often config values also don't clearly call out that they are needing base64 data, or do not generate an error if non-compliant base64 is encountered. It's a layer of obfuscation that doesn't really add any benefit, unless binary data needed to be

Re: Does relation scopes need to match?

Just to clarify my question. I know the official doc of these scopes, that data are broadcasted in GLOBAL and UNIT is maintained as 1-to-1. What I'd like to know is when we should use GLOBAL, and when to use UNIT? When I deploy multiple units of a charm, does it mean its end of relation must

Re: How to count relations?

On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns wrote: > Alex beat me to it, but here's a marginally more complete example: > https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b > > The key points are: > > * The interface needs to be UNIT scoped (because you

Re: How to count relations?

Cory, Alex, good pointers! I had provider set to GLOBAL and require in UNIT. Maybe that's why. Let me take a look your example and follow your instructions here to give it another try. Thank you guys! On 06/07/2017 11:44 AM, Cory Johns wrote: Alex beat me to it, but here's a marginally

Re: How to count relations?

Alex beat me to it, but here's a marginally more complete example: https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b The key points are: * The interface needs to be UNIT scoped (because you care about individual units) * The joined handler sets a state for each unit that joins *

Re: Is there a way to login to lxd containers of existing openstack?

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

Re: OS X VMS on JAAS

... > >> Which is why using something like the "lxd provider" would be a more >> natural use case, but according to James the sticking point is having to >> set up a controller in the first place. So "--to lxd:0" is easier for them >> to think about than setting up a provider and letting it

Re: OS X VMS on JAAS

... > >> Which is why using something like the "lxd provider" would be a more >> natural use case, but according to James the sticking point is having to >> set up a controller in the first place. So "--to lxd:0" is easier for them >> to think about than setting up a provider and letting it

<    3   4   5   6   7   8   9   10   11   12   >