Re: Getting started?

Hi Ramsey, If your goal is to setup a single NUC Openstack I would also suggest taking a look at our Openstack installer. It supports a single install option that utilizes a combination of LXC/KVM and will soon support the solution Mark described below with LXD on Xenial. Details can be foun

Re: @when('config.changed')

This is awesome, glad to see this wrapped in the reactive framework. Will make a lot of my layers much simpler! Marco On Wed, Feb 17, 2016 at 1:44 PM Cory Johns wrote: > Just wanted to give a heads-up about a feature that landed in the reactive > base layer yesterday. > > If a charm config opti

Re: @when('config.changed')

Cool! I'll work that into my charms tomorrow. Might as well go all out on the new stuff ;) Tom On 17 Feb 2016 18:48, "Marco Ceppi" wrote: > This is awesome, glad to see this wrapped in the reactive framework. Will > make a lot of my layers much simpler! > > Marco > > On Wed, Feb 17, 2016 at 1:44

Re: @when('config.changed')

Cory Johns: > If a charm config option has changed, the state "config.changed" will > be set for the duration of the hook. Additionally, specific states > will be set for each config option that changed; that is, if option > "foo" has changed, the state "config.changed.foo" will be set. Ah, thi

Re: @when('config.changed')

Relations are best served being managed by the interface layer. Which should consume the data and raise states as appropriate. On Wed, Feb 17, 2016 at 3:45 PM Nick Moffitt wrote: > Cory Johns: > > If a charm config option has changed, the state "config.changed" will > > be set for the duration o

Re: @when('config.changed')

That's a very good point. Marco Ceppi: > Relations are best served being managed by the interface layer. Which > should consume the data and raise states as appropriate. > > On Wed, Feb 17, 2016 at 3:45 PM Nick Moffitt > wrote: > > > Cory Johns: > > > If a charm config option has changed, the s

Re: @when('config.changed')

Great! Very usefull! Thanks, Cory! Op woensdag 17 februari 2016 heeft Cory Johns het volgende geschreven: > Just wanted to give a heads-up about a feature that landed in the reactive base layer yesterday. > If a charm config option has changed, the state "config.changed" will be set for the durat

Re: @when('config.changed')

I hate to go against the love-in here. While I desperately want a configuration changed feature for the reactive framework. I disagree with the way it was implemented. I brought up issues with this implementation in the pull request: https://github.com/juju-solutions/layer-basic/pull/36 It feels

Re: @when('config.changed')

On Wed, Feb 17, 2016 at 5:56 PM Matt Bruzek wrote: > I hate to go against the love-in here. While I desperately want a > configuration changed feature for the reactive framework. I disagree with > the way it was implemented. I brought up issues with this implementation in > the pull request: htt

Re: @when('config.changed')

On 18 February 2016 at 01:44, Cory Johns wrote: > If a charm config option has changed, the state "config.changed" will be set > for the duration of the hook. Additionally, specific states will be set for > each config option that changed; that is, if option "foo" has changed, the > state "confi

Re: @when('config.changed')

I sort of agree that it feels wrong to lump configuration change events into states. That said, adding another primitive doesn't seem like a good idea. The primitive doesn't nearly cover all cases. I think the problem with `x.changed` states is just a symptom, and we should address the root cause,

Re: @when('config.changed')

nting towards are: 1. Information that is relevant till processed. 2. Information that acts as a fact, persistent knowledge of the system. Point two is how you see states today. Point two states are only persistent facts until something changes that makes us re-evaluate them, this how ev

Re: @when('config.changed')

ormation that acts as a fact, persistent knowledge of the > system. > > Point two is how you see states today. Point two states are only > persistent facts until something changes that makes us re-evaluate them, > this how ever is also true of point 1. In the case of point 1 processe

Re: @when('config.changed')

On 19 February 2016 at 16:32, Merlijn Sebrechts wrote: > I completely agree with you on point two. The semantics I'm trying to get at > for point one are a bit different. Events are information that is relevant > for a single point in time, not until the information is processed. Events > can be

Re: @when('config.changed')

I like the idea of an @after() decorator. I've run into some cases where having @after would be a boon, such as cycling for docker extensions (setting up network, storage, et-al) that would benefit from an @after() that i can ensure will be run before/after any workloads have landed on that daemon

Re: @when('config.changed')

On Fri, Feb 19, 2016 at 6:30 PM, Charles Butler wrote: > I like the idea of an @after() decorator. > > I've run into some cases where having @after would be a boon, such as > cycling for docker extensions (setting up network, storage, et-al) that > would benefit from an @after() that i can ensure

Re: LXD Bootstrap

Sorry forgot to mention, Juju was built from trunk this morning. Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart

Re: LXD Bootstrap

I've tried rolling back on Juju but still can't find a combination, its not the end of the world, I was curious. Anyway, if I lxc exec into the machine I find SSH is down which sorta explains the connection failure: cloud init runs but then seems to get no futher https://gist.github.com/buggtb/c5

Re: LXD Bootstrap

On Jorge's advice I rolled all the way back to the juju 1.26 beta 2 tag, lxd beta 2 and xenial and still it fails with connection refused weird. On 26 Feb 2016 16:02, "Tom Barber" wrote: > I've tried rolling back on Juju but still can't find a combination, its > not the end of the world, I wa

Re: LXD Bootstrap

On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote: > Afternoon, got bored decided to try Jorge's blog post about Juju LXD and ZFS > > I'd read on a few posts about the requirement for LXD beta2 because of API > incompatibilities so I found the deb's and installed them. > > Its up and run

Re: LXD Bootstrap

No worries Serge I was just some Friday fun to get me out of the daily grind. Thanks for the update. Tom On 26 Feb 2016 8:02 pm, "Serge E. Hallyn" wrote: > On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote: > > Afternoon, got bored decided to try Jorge's blog post about Juju LXD and > Z

Re: LXD Bootstrap

Connection refused isn't the error you would be getting if it was the current incompatibilities. What you're seeing looks more like you aren't in the "LXD" group, or you didn't refresh your groups after installing LXD. (newgrp lxd) John =:-> On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber wrote:

Re: LXD Bootstrap

Thanks John That was sort of my thinking too. But it's not a groups thing that I can see. Same issue as root or as unprivileged users. bugg@tomsdevbox:~$ groups bugg lxd bugg@tomsdevbox:~$ lxd --version 2.0.0.beta2 bugg@tomsdevbox:~$ lxc --version 2.0.0.beta2 at which point the bootstrap t

Re: LXD Bootstrap

What image did you import into LXD? You should use something like: lxd-images import ubuntu trusty --alias ubuntu-trusty (substitute xenial/wily etc as relevant.) That looks like you are using an image from linuxcontainers.org which is very different from the ones built by cloud-images.ubuntu.c

Re: LXD Bootstrap

I used: lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty Which I stole from Jorge's blog. bugg@tomsdevbox:~$ lxc image list ++--++++--+--+ | ALIAS | FING

Re: LXD Bootstrap

That does seem correct. But I thought cloud-images run openssh by default. So that seems surprising. What happens if you just do "lxc create" to spawn an instance instead of using Juju? John =:-> On Sat, Feb 27, 2016 at 4:17 PM, Tom Barber wrote: > I used: > > lxd-images import ubuntu trusty

Re: LXD Bootstrap

BTW, if you are comfortable running Juju from master, there is a branch "lxd-container-type" which should support LXD 2.0.0~beta4 (I have it running here), and I'd be happy to get feedback on it. John =:-> On Sat, Feb 27, 2016 at 4:55 PM, John Meinel wrote: > That does seem correct. But I thou

Re: LXD Bootstrap

bugg@tomsdevbox:~$ lxc launch ubuntu-trusty my-test-container Creating my-test-container Starting my-test-container bugg@tomsdevbox:~$ bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bas bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bash root@my-test-container:~# ps axu |grep ssh root

Re: LXD Bootstrap

Okay checked out and tested but no dice currently: bugg@tomsdevbox:~$ juju --version 2.0-beta2-xenial-amd64 bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxc --version 2.0.0.beta4 bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxd --version 2.0.0.beta4 bugg@tomsdevbox:~/work/src/github

Re: LXD Bootstrap

The only thing I can tell you about this box that might different from the test beds you guys use was it was a dist upgrade from wily because that was the latest image the hosts had. -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku communi

Re: LXD Bootstrap

You're running on Xenial but you don't have a Xenial image listed. Maybe its launching a Trusty image for bootstrap? I thought it always tried to match the host version. I assume you did: cd $GOPATH/src/github.com/juju/juju git checkout lxd-container-type godeps -u dependencies.tsv go install ./...

Re: LXD Bootstrap

Yeah I did run the build like that, so not sure whats going on there. lxc launch still works fine. The box is empty except this hacking so I might flatten it and reinstall wily and upgrade through it again, see if a clean slate does the trick. LXD looks fine though, so I'm not sure what I'm doing

Re: LXD Bootstrap

Okay, evolution on a theme, clean install, compiled the new version and added lxd and checked my user now I get: 016-02-27 14:40:51 DEBUG juju.provider.common bootstrap.go:318 connection attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94 port 22: Connection refused 2016-02-27 14:40:52 DE

Re: LXD Bootstrap

Is 10.0.3.94 the correct IP for the LXD container? Did you let it sit a while so it had a chance to keep trying until maybe SSH came up on its own? And yet again, if you just do "lxc create" a container from exactly the same image, is SSH running on it? I'm recompiling my own work here making sure

Re: LXD Bootstrap

One thing you could try, "juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series trusty". It may be a difference based on what the target series is. John =:-> On Sat, Feb 27, 2016 at 6:50 PM, John Meinel wrote: > Is 10.0.3.94 the correct IP for the LXD container? Did you let it

Re: LXD Bootstrap

On 27 February 2016 at 14:53, John Meinel wrote: > juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series > trusty" No difference. Im on juju-dev as magicaltrout. Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku com

Re: LXD Bootstrap

Also: bugg@tomsdevbox:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu Xenial Xerus (development branch) Release: 16.04 Codename: xenial lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial juju bootstrap test-lxd lxd --debug --upload-to

Re: LXD Bootstrap

Okay so a summary from IRC investigations with Rick H. I thought yesterday on trusty manual sshd was running, i may have been wrong. Xenial image has a running sshd but I can't bootstrap it due to missing tools If anyone has a snippet for generating and using tools locally instead of from the pl

Re: LXD Bootstrap

Okay trusty images are failing for me because upstart borks and I get dumped into runlevel unknown. Serge might have an idea as he was involved in a similar bug issue a while ago on launchpad -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the

Re: LXD Bootstrap

Also, right on boot, like the moment the image spins up if I force the runlevel to 5, then the node gets bootstrapped without issue. So it is something to do with: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/924337 or similar, just with a Xenial host. -- Director Meteorite.bi -

Re: LXD Bootstrap

Okay I think I worked it out, but i dont' cause the cause in reality: in upstart mountall was failing during the boot of the containers so I did: root@tomsdevbox ~ # umount /sys/kernel/debug root@tomsdevbox ~ # mount -t debugfs none /sys/kernel/debug and suddenly trusty images started booting.

Re: LXD Bootstrap

Hi Serge I rebooted the host to see what happened and the lxc images that were running fine all now have broken SSHD. This, to make absolutely clear doesn't affect the Xenial image, just the trusty one I test with. bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2 Creating fix-server2 Start

Re: LXD Bootstrap

On Sat, Feb 27, 2016 at 11:42:51PM +, Tom Barber wrote: > Okay I think I worked it out, but i dont' cause the cause in reality: > > in upstart mountall was failing during the boot of the containers > > so I did: > > root@tomsdevbox ~ # umount /sys/kernel/debug > root@tomsdevbox ~ # mount -t

Re: LXD Bootstrap

On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote: > Hi Serge > > I rebooted the host to see what happened and the lxc images that were > running fine all now have broken SSHD. This, to make absolutely clear > doesn't affect the Xenial image, just the trusty one I test with. > > bugg@tom

Re: LXD Bootstrap

Hi Serge Fresh reboot and updated image, image boots with SSHD working fine, so whatever you did, i assume worked or is a freak occurrence. I don't have any old images kicking around and the import I copied from your email appears to have stomped on the old image. FYI bugg@tomsdevbox:~$ lxc conf

Re: LXD Bootstrap

Seemingly the image name and key are the same, LXD and Juju are the same, so you've either done something magic or I'm confused with its now seeming happiness of the kernel debug mountpoint! :) -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Sa

Re: LXD Bootstrap

On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber wrote: > Seemingly the image name and key are the same, LXD and Juju are the same, > so you've either done something magic or I'm confused with its now seeming > happiness of the kernel debug mountpoint! :) > I ran into a similar issue today. xenial ho

Re: LXD Bootstrap

Hi Casey, I haven't reproduced that here in VMs. If you can reproduce this at will (by rebooting the host) could you file a bug against the kernel (pad.lv/u/linux) ? thanks, -serge Quoting Casey Marshall (casey.marsh...@canonical.com): > On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber wrote: > >

Re: LXD Bootstrap

Its pretty weird, because a few reboots and it failed, now its magically working post reboot. Worst comes to the worst I can flatten the machine again and I'm sure it will reappear as it did the previous 2 occasions. -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)560364

Re: LXD Bootstrap

Okay we're back. Here is the /proc/mount stuff: http://paste.ubuntu.com/15260347/ http://paste.ubuntu.com/15260350/ You can see a bit of a diff after the remount, hope it helps! Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku

Re: LXD Bootstrap

On Mon, Feb 29, 2016 at 5:35 PM, Serge E. Hallyn wrote: > Hi Casey, > > I haven't reproduced that here in VMs. If you can reproduce this at will > (by > rebooting the host) could you file a bug against the kernel ( > pad.lv/u/linux) ? > Saw it again after booting up my laptop this morning, open

Re: Neo4J Charm

Hi Merlijn, that was Steven Baker The charm looks like it's in his github repo here: https://github.com/srbaker/neo4j-charm I don't know what state it's in, but I'm sure it'll be fun to try out. On Thu, Mar 3, 2016 at 9:26 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Hi all > >

Re: Reactive roadmap

ilar? We'd ideally like a stable base to build from before > committing to use a new framework, having been (re)writing/maintaining > charms for 4+ years now :) > I too would like to see and help the ecosystem mature. > 2) Layer pinning. Right now, layers are evolving fast, and the lack

Re: Reactive roadmap

On 9 March 2016 at 01:19, Simon Davy wrote: > 2) Layer pinning. Right now, layers are evolving fast, and the lack of > pinning to layer versions has caused charm builds to break from day to > day. Is this a planned feature? You can pin the layers in your build environment - they are only unpinne

Re: Reactive roadmap

... > > > 3) Downloading from the internet. This issue has been common in > > charmstore charms, and is discouraged, AIUI. But the same issue > > applies for layers, and possibly with more effect, due to a layer's > > composibility. We simply can not utilise any layer that downloads > > things f

Re: Reactive roadmap

On Mon, Mar 14, 2016 at 1:05 PM, John Meinel wrote: > ... > >> >> >> > 3) Downloading from the internet. This issue has been common in >> > charmstore charms, and is discouraged, AIUI. But the same issue >> > applies for layers, and possibly with more effect, due to a layer's >> > composibility.

Re: Reactive roadmap

On Tue, Mar 8, 2016 at 9:19 AM, Simon Davy wrote: > 1) Is there a roadmap for reactive? A target for a stable 1.0 release, > or similar? We'd ideally like a stable base to build from before > committing to use a new framework, having been (re)writing/maintaining > charms

Re: Reactive roadmap

On 14/03/16 13:55, Simon Davy wrote: > Right, downloading at build time is a different problem. The issue is > that the layer might do something on the install hook, for example, > which downloads from the internet at run time, on the units. Such > things work fine in dev or for demos, but will fai

Re: Reactive roadmap

g to use a new framework, having been (re)writing/maintaining >> charms for 4+ years now :) > > > The layered & reactive approach saw adoption more quickly than I expected, > which is both great and unfortunate for working out the kinks. That said, > the core concepts of both

Re: Reserved actions

On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins wrote: > Hi, > > There's a code review in progress (http://reviews.vapour.ws/r/4286/) that > will introduce a predefined action, "juju-run", which is part of the > replacement for the current SSH-based juju-run. > This is interesting. What's the sem

Re: Reserved actions

I believe that reserving the juju- prefix would be good. I, personally, haven't seen any charms using them. -- José Antonio Rey On Mon, Mar 28, 2016, 21:04 Marco Ceppi wrote: > On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> Hi, >> >> There's a code

Re: Reserved actions

On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi wrote: > On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> Hi, >> >> There's a code review in progress (http://reviews.vapour.ws/r/4286/) >> that will introduce a predefined action, "juju-run", which is part o

Re: Reserved actions

+1 to reserving the juju* space just as we do with relations and such. On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi > wrote: > >> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins < >> andrew.wilk...@canonical.

Re: Reserved actions

I've created this issue, and will make sure it lands in time for Xenial. https://github.com/juju/charm-tools/issues/161 On Tue, Mar 29, 2016 at 1:55 AM Rick Harding wrote: > +1 to reserving the juju* space just as we do with relations and such. > > On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins

Re: Juju Storage

On Tue, Apr 5, 2016 at 10:03 PM Bruno Ranieri wrote: > Hi, > Hi Bruno, I am working on charms for the Quobyte Storage System. These charms make > use of the Juju Storage support, > but unfortunately juju storage does not behave as expected: > > In my charms block-type storage is defined (metada

Re: Model statuses

> - would you find it helpful to have common* statuses? > - or, would you find it more helpful to have statuses unique to each entity type? I'm still very much a beginner when it comes to developing charms, but from my perspective, it would be most useful to have common statuses, so that knowledge

Re: Model statuses

The guidance is that we want it to be VERY clear to people, when someone quotes just a status, what they are talking about. There is a very different situation in progress when a unit state is being described than the state of the whole application. Imagine a telephone conversation between two str

Re: Model statuses

On Wed, Apr 13, 2016 at 8:46 AM Pete Vander Giessen wrote: > > - would you find it helpful to have common* statuses? > > - or, would you find it more helpful to have statuses unique to each > entity type? > > I'm still very much a beginner when it comes to developing charms, but > from my perspec

Re: Model statuses

On Wed, Apr 13, 2016 at 7:43 PM Mark Shuttleworth wrote: > > The guidance is that we want it to be VERY clear to people, when someone > quotes just a status, what they are talking about. There is a very > different situation in progress when a unit state is being described > than the state of the

Re: ApacheCon Photo

On Friday, May 13, 2016, Tom Barber wrote: > I have a feeling there was a photo or two taken of me working the booth on > Tuesday or whenever it was. If anyone has one and fancies sending it my > way, I'd like to include it in a blog post if its remotely acceptable. > Sent over the ones I had.

Re: Drill performance

Thanks Tom! We'll contact them. Kind regards Merlijn Sebrechts 2016-05-17 11:44 GMT+02:00 Tom Barber : > Hey Merlijn > > I've not scaled up to 200GB but we did do a 20-30GB HDFS test with > adequate performance and load being spread over drill bits. I guys on the > drill mailing list are prett

Re: Drill performance

Hi Merlijn, Knowing that you are into data streaming with storm, have you looked at Druid (http://druid.io/druid.html)? It might be a good fit for your use cases. Cheers, Konstantinos On Tue, May 17, 2016 at 2:45 PM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Thanks Tom! We'll co

Re: Drill performance

Yeah Druid is on my todo as well. Samuel intoduced me to his druid contact about charming it up and then he went quiet. Would be good to get into the platform so Saiku can leverage it. -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku commu

Re: Drill performance

Sorry Merlijn! Forgot about the CTAS to parquet bit :) At least you guys got an almost instant response from those who know. On 17 May 2016 14:13, "Tom Barber" wrote: > Yeah Druid is on my todo as well. Samuel intoduced me to his druid contact > about charming it up and then he went quiet. Would

Re: Subordinate charms

Try the normal charm remove command: *juju remove-service * Regards 2016-05-27 2:24 GMT+05:00 André Moreira : > How can I remove a subordinate charm without removing the principal? > > -- > > Le doux charme de maint songe > Par leur bel art inventé > Sous les habits du mensonge > Nous offre la

Re: Subordinate charms

Using this, it also removes the unit of the charm it is subordinated to. 2016-05-26 18:34 GMT-03:00 Bilal Baqar : > Try the normal charm remove command: > *juju remove-service * > > Regards > > 2016-05-27 2:24 GMT+05:00 André Moreira : > >> How can I remove a subordinate charm without removing t

Re: Subordinate charms

Hi Andre Can you give us a clue what you are installing/uninstalling because I believe Bilal is correct, I've not see it wipe out the parent charms either. Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kic

Re: Subordinate charms

Hi Tom, I found this: The current model of subordinates doesn't include support for removing subordinate units from their principal service apart from removing the principal service itself. This limitation stems from the current policy around service shutdown and the invocation of stop hooks. htt

Re: Subordinate charms

Try removing the relation between the two. The unit of the subordinate charm will be removed from that node. Regards On Fri, May 27, 2016 at 2:38 AM, Tom Barber wrote: > Hi Andre > > Can you give us a clue what you are installing/uninstalling because I > believe Bilal is correct, I've not see i

Re: Subordinate charms

Hi Bilal, I think that is not possible. When I try, I receive this: "You may not remove a subordinate relation." André 2016-05-26 18:41 GMT-03:00 Bilal Baqar : > Try removing the relation between the two. The unit of the subordinate > charm will be removed from that node. > > Regards > > On Fri

Re: Subordinate charms

André, What are you installing and trying to remove? I will do some quick testing around, and would like to reproduce the same scenario that you have. On 05/26/2016 04:43 PM, André Moreira wrote: Hi Bilal, I think that is not possible. When I try, I receive this: "You may not remove a subord

Re: Subordinate charms

José, They are charms I created to deploy some services that I have. I have a "principal" charm with something like this (I had to change the actual names): metadata.yaml: name: charm-principal summary: maintainer: OMMITED description: | tags: - misc subordinate: false provides: principal

Re: Subordinate charms

Yes, this is the way that subordinates work. They can often do very intrusive things. Imagine a django subordinate that installs and sets up a plugin into the django application it's deployed to. We don't currently support the removal of them. They kind of become one with the principle application.

Re: Subordinate charms

Hello, What is then the recommendation for monitoring / logging / (...) agents that run independently on the units and are loosely connected to the local charms, but potentially still need to know about the apps running? Wouldn´t colocation make them cumbersome? Still encoded as subordinate charm

Re: Bash completion

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:

Re: Bash completion

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 shou

Re: Model config

Hello all, I am testing/validating with apt-mirror atm. Doing so my expectation would be to set this at the controller level and have the capacity to override per model (or user). Why ? response staging. People taking the burden of managing mirrors do so to control their environment. Which means

Re: Model config

juju set-model-defaults juju set-model-config juju set-controller-config Have we a strong preference for get/set names, or could we just use "model-config" and "model-defaults" as read/write commands? Mark On 08/06/16 18:41, Andrew Wilkins wrote: > Hi folks, > > We're in the midst of making

Re: Model config

The danger I think we've tried to avoid with the get/set is that if you have just model-config you can accidentally mutate the state by messing up your arguments you pass in via scripts/etc. It also keeps it consistent across the read/write across the many things that can change now, applications,

Re: Model config

On 08/06/16 22:05, Rick Harding wrote: > The danger I think we've tried to avoid with the get/set is that if > you have just model-config you can accidentally mutate the state by > messing up your arguments you pass in via scripts/etc. It also keeps > it consistent across the read/write across the

Re: Model config

On 8 June 2016 at 10:41, Andrew Wilkins wrote: > Hi folks, > > We're in the midst of making some changes to model configuration in Juju > 2.0, separating out things that are not model specific from those that are. > For many things this is very clear-cut, and for other things not so much. > > For

Re: Model config

On 08/06/16 23:59, roger peppe wrote: > On 8 June 2016 at 10:41, Andrew Wilkins wrote: >> Hi folks, >> >> We're in the midst of making some changes to model configuration in Juju >> 2.0, separating out things that are not model specific from those that are. >> For many things this is very clear-

Re: Model config

On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth wrote: > > juju set-model-defaults > I was mostly wondering whether we should have model defaults, or things that that we'd set at a common level *without* the ability to set on a per-model basis to keep things compartmentalised. Once cloud/regio

Re: Model config

On 09/06/16 11:35, Andrew Wilkins wrote: > On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth > wrote: > > > juju set-model-defaults > > > I was mostly wondering whether we should have model defaults, or > things that that we'd set at a common level *without* the ability

Re: "juju attach"

We can change a CLI until RC, and its good for us to debate them. Here are the guiding principles. * shorter is better, much much better * we strongly prefer one word to always mean the same thing * we strongly prefer a unique verb to a common-verb-plus-noun For the latter reason I prefer no

Re: "juju attach"

mount ? On 18 June 2016 at 09:23, Mark Shuttleworth wrote: > > We can change a CLI until RC, and its good for us to debate them. > > Here are the guiding principles. > > * shorter is better, much much better > * we strongly prefer one word to always mean the same thing > * we strongly prefer a

Re: "juju attach"

Why not just "add" which is already pretty well used. Throughout the Juju CLI. Marco On Sat, Jun 18, 2016, 5:52 AM roger peppe wrote: > mount ? > > On 18 June 2016 at 09:23, Mark Shuttleworth wrote: > > > > We can change a CLI until RC, and its good for us to debate them. > > > > Here are the

Re: "juju attach"

On 18/06/16 16:45, Marco Ceppi wrote: > > Why not just "add" which is already pretty well used. Throughout the > Juju CLI. > Well, I think the context here is more attach-a-disk. I really like Roger's suggestion of 'mount', it immediately brings all the right elements into focus, and it's only one

Re: "juju attach"

really like > Roger's suggestion of 'mount', it immediately brings all the right > elements into focus, and it's only one syllable. > I concur that add is not really appropriate here, and that mount makes a lot of sense for storage (thanks for the suggestion, Roger).

Re: Layer-Supervisor

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 con

<    1   2   3   4   5   6   7   8   9   10   >