[00:23] anyone used the debug-hooks lately? I can't get it to run config-changed on setting a value. It runs on install/boot of the initial service. http://paste.ubuntu.com/6823548/ [00:26] trying to debug if I ru the hook manually I get config-get: command not found and if I try to run config-get I get a error: JUJU_CONTEXT_ID not set === Guest57266 is now known as med_ === med_ is now known as medberry === medberry is now known as med_ === freeflying is now known as freeflying_away [00:50] rick_h_: hey, around? [00:50] thumper: howdy [00:51] rick_h_: are you playing with trunk? [00:51] or 1.16.5 [00:51] thumper: env is torn down, was trying to charm up my own app but having too much fun :/ [00:51] thumper: latest stable /me goes to check [00:51] thumper: 1.17 trusty [00:51] .0 [00:51] rick_h_: there is a new command [00:51] juju run [00:51] which will execute arbitrary code in a hook context [00:51] ok, yea I noticed that was the only command I could complete with juju- [00:51] so you can manually run commands [00:51] juju-run $hook ? [00:51] from the client like this [00:52] juju run unit/3 hooks/foo [00:52] ah, gotcha [00:52] if you ssh to the machine [00:52] you can get the same by going "juju-run unit/3 hooks/foo" [00:52] any idea on why the config hook would fail to run. I've got a couple of logs in the process of that hook and all I'd get are the two lines in the pastebin [00:52] it does run on initial deploy and worked perfectly [00:53] * thumper scrolls up [00:53] I got all happy until I tried to change the value via juju set [00:53] thumper: http://paste.ubuntu.com/6823548/ is all I got on the unit side after doing a set [00:53] which is what led me to debug-hooks trying to figure out why it wasn't doing anything [00:53] when it calls the hook you should notice in the logs [00:53] it'll say "calling hook foo" [00:53] right, that's all that shows in the log [00:54] noting else, at least not in the unit-.log [00:54] nothing* [00:54] how were you changing the value? [00:54] i've not looked into that code before [00:54] juju set bookie port=6548 [00:54] nor the filter bit [00:54] picking a diff port each time I tried to trigger the hook [00:54] * thumper goes to look at the source [00:55] and I take that there is a config value for bookie and port? [00:55] well, for port in the bookie service [00:55] * thumper goes to read the filter code [00:56] thumper: right, bookie is the service, port is the config [00:56] * rick_h_ goes to look that he didn't do something REALLY stupid [00:56] https://github.com/bookieio/bookie-charm/blob/get-config-working/config.yaml [00:59] wow this code is confusing [01:01] heh, /me has special breaking powers to make something simple (config change) confusing. [01:06] holy crap I can't penetrate the obfuscation of this code [01:07] thumper: ok, don't worry about it for now. I've got to afk in a few min and I'll poke at it some more and see if I can debug with the juju-run hint [01:07] maybe I do have something wrong and need to stab it more [01:08] rick_h_: grab dimitern when you are around in the morning [01:08] rick_h_: I think he has a good understanding of this [01:08] thumper: rgr, thanks for the help [01:08] * rick_h_ will move bmark.us to juju at some point darn it :) === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === mwhudson is now known as zz_mwhudson === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [05:58] where in juju's sources can I find the list of supported/known series? I would like to add support for other machine distros [06:01] also I haven't grokked yet what the difference of ubuntu server and ubuntu cloud image is. maybe cloud-init is related which is used as a form of system provisioning? [06:44] meebey: hey there [06:44] meebey: much of the juju internals currently expect an ubuntu image [06:44] meebey: we plan to support other distros/OSes this year [06:44] but work has not yet started on that [06:45] * thumper has EODed [06:45] thumper: noticed that already in various places in the code. I dont expect just work, I am interested in developing the support [06:45] but perhaps poke fwereade, he should be online soon [06:46] meebey: what is your target distro? [06:46] debian wheezy [06:46] * meebey is a DD btw [06:46] ah, at least debian based :-) [06:46] bootstrap does not need wheezy support for my use-case but machines would do [06:47] * thumper nods [06:47] definitely poke fwereade :) [06:47] * thumper heading off now [06:47] ok, thanks [06:47] .oO( he needs a smuxi-server charm, I should probably write one ) [08:32] meebey, hi [10:06] fwereade: do you have hints for me where in the source to look at when I want to add machine support for debian? [10:25] meebey, heyhey [10:25] meebey, sorry delay, I've been having fun times with an electrician [10:25] meebey, so, to get stuff running on other OSs [10:26] meebey, cloudinit and upstart are the two things that immediately stick out -- cloudinit to set up the machines, upstart to keep the agents running [10:27] meebey, those are the source-specific bits [10:28] fwereade: cloudinit is performend inside on the created machine image / VM? [10:29] meebey, yeah, it's basically the first thing that runs, it usually comes from the cloud's metadata service [10:31] meebey, (offhand I'm not sure *exactly* how it gets there on MAAS) [10:31] meebey, the maybe more interesting side is actually starting up an instance with an appropriate image [10:31] fwereade: does it need to download that from somewhere or is it provided from the juju core instance? [10:31] the cloudinit part [10:32] meebey, the images we start already have cloudinit ready to run -- I'm afraid I've never checked exactly what mechanism triggers it [10:32] so far I have made a ubuntu server install with juju-core and juju-local, to see how things work [10:33] fwereade: ah ic, where does that image come form then, is it the ubuntu cloud image? [10:33] meebey, yeah, exactly [10:33] alright, this clears some missing bits I had [10:33] meebey, the mechanism by which we choose an image is very relevant to you too [10:34] meebey, there's an image-metadata-url config setting [10:35] meebey, which needs to point at a simplestreams datasource describing what you've got available [10:36] meebey, the environs/simplestreams package is where you need to look for that [10:36] meebey, and I can't promise that there haven't been some ubuntuisms slipping in there, but the data format is explicitly not platform-specific [10:38] meebey, finally you need your charms to know about the "series" you're using, and have those match what you have in simplestreams [10:38] ok, thanks for the info, this will get me going [10:38] meebey, cool [10:38] yeah that is what exploded first in my face, the unknown series :) [10:38] meebey, come talk to us any time, we're keen to help [10:39] will do, thanks [10:40] meebey, fwiw #juju-dev is maybe an even better place to ask about these details [10:40] didnt know that one exists, I will join [10:40] meebey, it's sparsely populated at weekends but there's usually at least one core dev in there any time of day during the week [11:31] Hey there, I'm unable to bootstrap or destroy local environment on subsequent runs of juju after initially not entering sudo password: http://paste.ubuntu.com/6825699/ [11:31] If there's an easy workaround, pls let me know. Also if I should file that as a bug... === gary_poster|away is now known as gary_poster === CyberJacob is now known as CyberJacob|Away [14:25] dimitern_: ping, got a sec to help me debug something with a failing config set? thumper thought you might know the code/be able to help a bit more than he could. [14:27] noodles775, which version of juju are you running? [14:28] And I'm aware of this issue, I ran into it last week. I can help clean that up [14:29] lazyPower: trunk, the rev is at the bottom of the paste. [14:29] Thanks :) [14:30] Ah, i missed that [14:30] ok typically what I had to do was nuke my local provider and recreate it. A few questions: Are you using encrypted HOME? [14:31] Yep, I am. I thougth destroy-environment --force would nuke the local provider? [14:32] Ah - or manually nuke any lxc's? Let me do that. [14:33] its supposed to, i'm not sure what causes the mis-match - I havn't found the underlying problem yet. But when i removed $JUJU_PATH/environments/local.jenv, $JUJU_PATH/local [14:33] plus the supporting stuff like files in /etc/lxc/auto [14:33] one sec i have a script for this, but its kind of scary. Full of sudo rm -rf's [14:33] https://gist.github.com/chuckbutler/8483204 [14:34] OK, I'll try that, thanks! Do you have a bug for it? It'd be great to document everything you know. [14:34] be careful with it - reference the file paths and do some investigation [14:48] I am also having problems with juju and local this morning. [14:48] mbruzek, whats the error with local? [14:49] agent-state-info: '(error: symlink /var/lib/lxc/mbruzek-local-machine-1/config [14:49] /etc/lxc/auto/mbruzek-local-machine-1.conf: no such file or directory)' [14:49] Do you think removing my local.jenv file is advised in this case? [14:49] In this case, i'm not positive that nuking it is correct, but probably what I would do in the situation. [14:51] mbruzek: let me know if you find a fix for that. I've been hitting it as well in trusty and I thuoght it was related to lxc/trusty/etc [14:51] I have a cleanup script similar to lazyPower's and it removes the local.jenv vile [14:51] rm: cannot remove ‘/home/mbruzek/.juju/environments/local.jenv’: No such file or directory [14:51] rick_h_, I am also running lxc and trusty [14:52] mbruzek, nuke .juju/local [14:52] With the latest updates [14:52] mbruzek: I saw lxc updates come down the pipe this morning and been meaning to give it another go [14:52] lazyPower, I don't have a .juju/local directory [14:53] oh i see that its a leftover in /var/lib/lxc my mistake [14:54] let me compare our cleanup scripts [14:54] you posted a link back a few lines right? [14:54] Yeah, it should be the same as yours with a disclaimer at the top that its scary [14:55] i've been meaning to rewrite it in python with some environment checking, and re-prompting with what its going to do [14:55] so its not so abrupt in nuking every LXC container, and config [14:56] I see... [14:57] I had thumper take a look at it, and he gave me some extension pointers. If you're interested I'll add you to my trello board and we can pair on it when we're not slammed with tests [14:57] Yes my script does the same kinds of things [14:57] It removes local directory and local.jenv [14:57] THat doesnt work for users with an encrypted $HOME btw - theirs is put in /var/tmp/juju [14:58] Interesting, but my home is not encrypted. [14:58] That was an FYI :) [15:00] rick_h_, I have done all the clean up that I know of for local and I still get the error on symlink. [15:01] mbruzek: :( [15:01] mbruzek: yea, just duped here. I'm looking to see if there's a bug to track then [15:01] There was a post on the mailing list this morning about lxc being a blocker on the 17.1 release [15:01] not sure if its related [15:01] lazyPower: linky? might be [15:02] * mbruzek wonders if he could fix the symlink problem manually [15:02] https://lists.ubuntu.com/archives/juju-dev/2014-January/002042.html [15:02] mbruzek: well I think it has to do with perms of the lxc vs the charm deploy command being non-sudo [15:02] yeah, i was skimming [15:02] doesn't seem to be related :( Sorry [15:03] lazyPower: yea that's the same [15:03] lazyPower: that's the error in the bug we're getting [15:03] ah bueno [15:03] * rick_h_ follows bug [15:04] * mbruzek is tracking the bug too [15:09] rick_h_, I have created the /etc/lxc/auto directory and seem to be getting further. This problem rings a bell with something I have seen previously. Is it possible the directory is not getting created by the package ? [15:09] Obviously I did not delete this directory so I am wondering how I could have got this error before === freeflying is now known as freeflying_away [15:11] mbruzek: not sure, can see if sinzui got any info on the bug after he posted it and knows anything more? [15:11] Yeah I will talk with sinzui [15:12] mbruzek, I am testing a fix for your issue now. I hope it will be the very version I release as 1.17.1 in a few hours [15:12] OK my local provider is making it much further now [15:12] jamespage, i m having some problem with the ceph-osd charm https://pastebin.canonical.com/103619/ i do not find where is the call to "sgdisk .... --change-name" implemented. [15:13] mbruzek: are you using trusty? [15:13] avoine, yes I am [15:13] melmoth, oh - that's somewhere in the upstream code under ceph-disk-prepare [15:14] yeah in new version of lxc containers use configuration option for the autostart instead of symlinks [15:14] in fact it use both [15:14] mbruzek: but I think there is a bug in lxc that prevents us from starting machine at all [15:15] * rick_h_ and mbruzek breaking things early and often :) [15:15] ooh, that doesn't sound helpful [15:15] After adding that "auto" directory I am seeing my charms deploy on local [15:16] also the old symlinks not being clean up bug is fix in last version of golxc: https://bugs.launchpad.net/golxc/+bug/1238541 [15:16] <_mup_> Bug #1238541: Local provider isn't usable after an old environment has been destroyed

[15:16] avoine: yea, that was better this morning [15:16] mbruzek: so it work? [15:17] it looks like it, let me run a test [15:17] I have: lxc-start: failed to create cgroups for ... [15:17] when I try to start the container created by juju manually [15:18] avoine, I have a script that cleans up my local/lxc environment possibly working around that bug [15:21] I can interact with the memcahced charm normally. [15:21] I think this is working for me. [15:24] Thats awesome man [15:24] mbruzek +1 [15:27] it must be something with my installation then [15:28] * rick_h_ can test it out [15:28] Are you still having a problem? I can share my cleanup script if you want [15:28] mbruzek: what auto directory did you have to create? [15:28] mbruzek: and did you sudo bootstrap or non-sudo bootstrap? [15:28] /etc/lxc/auto [15:28] I did sudo bootstrap [15:29] mbruzek: so that's a root dir or a user dir? [15:29] /etc/lxc/auto [15:29] I saw the notes that we may not have to but I did not know if I had the right code to try it without sudo [15:29] root [15:32] mbruzek: cool, my charm I was working on this weekend is running the install hook so looking good so far [15:32] avoine: ^ [15:32] rick_h_, that is great [15:33] so sounds like that directory is the bugfix that should be in sinzui's stuff he's testing so hopefully we'll be good to go when 17.1 [15:35] hmm, and my config change fails there as well. [15:36] mbruzek: do you still have your env up? Can you try to juju set something and watch the log and see if it runs/works through the config-changed hook? === arosales_ is now known as arosales [16:01] rick_h_, sorry, i'm here now [16:07] mbruzek, lazyPower: fwiw, I created a separate bug 1273295 for the issue i was seeing - thanks for the work-around. [16:07] <_mup_> Bug #1273295: Cannot bootstrap or destroy local env after cancelling bootstrap [16:07] Happy to help [16:13] dimitern_: on a call but I'm having an issue where I don't get my config-changed hook to run when I juju set xxx, I only get http://paste.ubuntu.com/6826409/ but the config-changed hook is run after install so the hook is good at least once [16:17] rick_h_, juju set or relation-set inside a hook? [16:18] dimitern_: just ran juju set from cli to test out changing the value after it's brought up [16:21] rick_h_, so, you're saying config-changed fired once after install, but not when calling juju set [16:22] rick_h_, have you tried debug-hooks to intercept any hook (and possibly run relation-set foo=bar) ? [16:24] dimitern_: yes, the debug-hooks didn't catch anything [16:25] rick_h_, is the unit in error state? is the service alive or dying? [16:25] dimitern_: alive and running [16:27] rick_h_, can you paste the whole uniter log? [16:27] uniter log = machine log? or unit log? or different log? [16:27] unit log [16:27] dimitern_: k, after call will do [16:27] rick_h_, cheers [16:30] marcoceppi, http://paste.ubuntu.com/6827018/ [16:30] Opening a bug, but curious if you had an immediate response to the behavior [16:31] lazyPower: that could be very very bad [16:32] marcoceppi, just had a thought, i'm renaming my deployed services and this could be related. deploy('mongos', charm='mongodb') [16:33] lazyPower: interesting, I think I know the issue [16:34] raise a bug, no time to look today [16:34] got it [16:35] dimitern_: http://uploads.mitechie.com/lp/unit-bookie-0.log is the file. It's got a background thing spewing log stuff. I did a fresh juju set and pasted the command and some white space at the end of the log [16:35] dimitern_: if you go to the start of the file and seach down can see the config-changed hook running and output logging info during install [16:37] rick_h_, looking [16:38] I think something is wrong with the stream server: https://streams.canonical.com/juju/tools/streams/v1/index.json [16:39] marcoceppi, https://bugs.launchpad.net/amulet/+bug/1273312 [16:39] <_mup_> Bug #1273312: CharmStore.py failure on checking available relations [16:41] rick_h_, is this the complete log? [16:41] dimitern_: yea, scp of the unit log from the machine and uploaded to you [16:42] rick_h_, judging by the log the config-changed hook never completed and was not committed [16:46] dimitern_: never completed during the install process? [16:46] so it doesn't re-run on juju set? [16:46] rick_h_, no, the install hook ran and finished, then it was committed to the local uniter state which tracks which hooks it has to run next [16:47] rick_h_, but the config-changed hook seems to keep running and never returning anything, hence the uniter is still thinking the hooks has not completed [16:47] dimitern_: ah, gotcha [16:47] ok, I'll go look at my hook more. That gives me a hint as to how to debug [16:47] rick_h_, can I take a look at the charm source? [16:48] https://github.com/bookieio/bookie-charm/blob/get-config-working/hooks/config-changed [16:48] dimitern_: ^ [16:48] rick_h_, ta [16:50] rick_h_, that make stop and make run at the end look like it's blocking on doing something [16:51] dimitern_: yep that's probably it [16:51] I'll have to look into how it works [16:51] rick_h_, ok, glad i could help :) [17:39] Question about implementation of an amulet test, is it considered sliming the test if i use pymongo to validate a connection or should i run a mongoc shell via a sentry? [17:54] lazyPower, sliming? [17:55] when you slime, you're fudging a test case to get it to pass to test something, whether its related or not. [18:06] is there a way when deugging a dev environment, to inspect the relation data for a relation? [18:06] other than inspecting logs [18:07] like querying mongo or some such [18:07] unless there's a simple way that I've somehow missed [18:11] bloodearnest, debug-hooks is great for this, you can use relation-get to fetch the key/val you're looking for. [18:13] lazyPower: yeah, I'd like to do it after-the-fact if poss [18:14] debug-hooks is good, but has a set up cost (not just command, you need charms in correct state to perform the hook) [18:14] I'm not aware of any method to retrieve the relationship data after you've exited the hook-scope. [18:14] what I do in that scenario is i cache it in the $CHARM_DIR/.relationship_name [18:14] so i can reference it in subsequent hook runs outside of that scope, and maintain idempotency [18:16] bloodearnest, https://github.com/chuckbutler/errbit-charm-chef/blob/master/hooks/cookbooks/errbit/recipes/errbit-relation-changed.rb#L7 === CyberJacob|Away is now known as CyberJacob [19:12] lazyPower: yeah, I've thought of doing similar === zz_mwhudson is now known as mwhudson [19:28] can I have a 2nd juju local server or is that limited to a single system/box? [19:29] I could make another juju install, but then I can't make relations between them [19:48] meebey, you can have multiple environments on the same box [19:48] the bummer is we can't do cross-environment relations yet [19:48] so if you don't need things to talk to each other you can do multiple local providers [19:48] ic [19:51] so openstack is the only private cloud option then, right? [19:51] or just raw MAAS [19:52] but you probably want this [19:52] https://juju.ubuntu.com/docs/config-manual.html [19:52] that will let you deploy to any server with ssh [19:52] however, there be dragons with manual provisioning, it's not ready yet last I checked [19:53] hehe [19:53] I'll check on manual progress when thumper comes online in a few hours [19:54] we need to send a status report on that feature to the list anyway [19:54] * thumper looks at jcastro [19:54] speak of the devil! [19:54] jcastro: I told axw to look at it to confirm validitiy [19:54] as he is the source of all that [19:54] please chase with him [20:03] thumper, ack [20:45] arosales, another thing I noticed during reviews [20:45] is our description on metadata.yaml's tend to be long, with like bullet points and paragraphs [20:45] I am cutting those down since the README has all the bling, the description doesn't need to be so epic [20:47] jcastro, agreed that it should give enough an overview of what the service is and what the charm does though [20:47] yeah, most of them read like the author just copied and pasted the first 3 paragraphs from wikipedia [20:47] heh [20:47] jcastro, the "summary" page doesn't have the readme there, and is the first thing a user sees when the click on a charm [20:48] jcastro, agreed it needs to be more charm specific and an quick idea of what the service does [20:48] just incase the charm upstream is new [20:49] or folks haven't heard of the project, but agreed it shouldn't only be a copy of the wikipedia artical but summarizing the wikipedia article and providing and charm overview would be a plus. [20:53] http://imgur.com/hjFSTnu [20:53] The user won't even _see_ that page. :) [20:53] jcastro, which page? [20:54] the charm store page [20:54] ah [20:54] well [20:54] man, I think our search results are getting worse [20:54] if they are discovering via google [20:54] but if they are clicking via juju.u.c [20:54] they will see it [20:55] in any case we should very much consider how the metatdata and readme look in jujucharms.com [20:55] jcastro, the issue if it not having the correct seo juice is whole other issue :-) [20:55] yeah [20:55] I am just saying, I went to go prove you wrong [20:56] but then I ended up on that page [20:56] and started crying [20:58] jcastro, well I suggest we make the policy and readme more specific as to what we are looking for [20:59] jcastro, policy currently just states, "Must include a full description of what the software does in the metadata." [20:59] and best practice just states, "Provide an overview of the service in the README and metadata." [20:59] if I were a new user I would like for that part to be opinionated [21:00] specifically the policy should state the description should give an overview to what the deployed service is and the highlight of the charm [21:00] I was thinking just applying common sense [21:00] suggest adding to policy the charm should follow the charm tools proof template [21:01] well common sense to use may not be to some rookie like me :-) [21:01] then it ends up looking like this otherwise: http://www.debian.org/doc/debian-policy/ch-controlfields.html [21:01] not that there's anything wrong with that. :) === nate_finch is now known as natefinch [21:02] jcastro, I don't think we'll go that far, but one could arge debian has had some success so it may be not that bad of an idea to take pointers from [21:04] jcastro, also did you get any other feedback on the bundle policy from the list? [21:04] jamespage, are there any usecases where one might use the "ceph" charm without -osd and -radosgw? [21:04] * arosales should probably propose to the list the above suggested changes [21:05] jcastro, sure - just a small three node cluster would just use ceph [21:05] jamespage, ack [21:05] arosales, no feedback on the policy [21:05] I think we can safely go for "must include official charms to be an official bundle" without too much trouble [21:06] jcastro, ok do you want to make a card for starting to document the charm store bundle policy? [21:07] jcastro, only feedback I had was the bundle should endevour to be production grade [21:07] I could but I am still having a hard time understanding when bundles are supposed to land/work [21:07] and we did add bundles to policy already [21:07] we just didn't get any feedback on it [21:08] jcastro, sorry did I miss that in the docs? [21:08] juju.u.c/docs [21:09] ah I see the reference now in https://juju.ubuntu.com/docs/authors-charm-policy.html for bundles [21:09] yeah remember we made one policy page for both instead of 2 [21:09] makes sense [21:09] jcastro, do we just need to figure out how to promulgate them [21:09] the one gotcha is we still need to make `bundle add readme` and a template [21:10] we don't have a template for bundle readmes yet [21:10] arosales, they show up in the GUI and everything [21:10] you just have to manually make them and edit the file and so on [21:10] jcastro, were you looking for that to be in charm-tools [21:11] yeah [21:11] it's on marco's todo, I filed a bug, etc. [21:11] jcastro, ok, and then once that is made probably need to add a bundle specific section on https://juju.ubuntu.com/docs/authors-charm-store.html#submitting [21:12] jcastro, thanks could you make sure that bug has a card tied to it, and a card for updating https://juju.ubuntu.com/docs/authors-charm-store.html#submitting [21:12] https://juju.ubuntu.com/docs/charms-bundles.html [21:12] For submitting that had to be a seperate page [21:12] there's a link in the 4th bullet from the page you just linked [21:13] jcastro, agreed but technically they are not part of the recommended charms [21:13] ie not owned by charmers [21:13] so really not getting a chance to be reviewed against the policy [21:13] right [21:13] because we haven't really "promulgated" any bundles [21:14] :-) [21:14] ie. we're making them, but not putting them in the store [21:14] jcastro, understood and today I don't find any docs on how to get a bundle promulgated [21:14] right, we haven't done that yet [21:15] agreed, thus the ask for cards :-) [21:15] I am confused [21:16] jcastro, sorry, let me try to clearify [21:16] 1. we have bundles in our charm store policy [21:16] 2. we have how to make bundle (in a personal name space) [21:18] if we would like to have bundles "recommended" and reviewed the by the ~charmers team then we need to have the bug referenced resolved along with having how to submit a bundle for review documented [21:18] ok [21:18] I get that [21:19] I am just confused on the timeline [21:19] Were we trying to get bundles out of namespaces and officially in the store? [21:20] I mean, I can barely get any of them deploying right now [21:20] I think that is really determined by when we can resolve the bug you referenced (btw what is the bug #) and when we have a good process on submitting for review and housing bundles (ie are they owned by charmes too) [21:21] rick_h_, hey what was that bug where if one of the instances doesn't come up deployer just stops and doesn't do relations, etc [21:21] and perhaps why we need a central place to track bugs [21:55] meebey, manual provisioning will be in 1.18 [21:56] so hopefully that'll work out for you [22:25] jcastro: looking [22:26] jcastro: https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1252301 kinda but really I'm not sure it's a bug but working as intended [22:26] <_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails