| axw | mgz: are you about? CI won't merge my critical fix, looks like because we have turned on Windows unit test gating but still have a bunch of failing Windows unit tests ... | 00:21 |
|---|---|---|
| axw | wallyworld: ^^ I'd rather not spend all my time fixing Windows unit tests right at this point in time | 00:22 |
| wallyworld | axw: agreed, i'm not sure why gating was turned on before tests passed | 00:23 |
| wallyworld | we may have to skip them depending on how many there are | 00:24 |
| wallyworld | axw: did i recall perhaps incorrectly that bug 1598049 had been sorted out in some form? | 02:18 |
| === mup_ is now known as mup | ||
| axw | wallyworld: I *think* that's sorted out by perrito666's patch, which I merged into my branch and landed | 02:20 |
| axw | but I don't have windows handy to verify | 02:20 |
| wallyworld | axw: yeah, that rings a bell, that's what i thought had happened | 02:20 |
| wallyworld | i might mark as fix committed | 02:20 |
| wallyworld | axw: this updates the juju/rfc repo with the changes to remove the custom tls package https://github.com/juju/rfc/pull/1 | 02:35 |
| axw | wallyworld: you just did a straight copy of changes from juju/juju/standards right? | 02:37 |
| axw | apart from txt file of course | 02:37 |
| wallyworld | axw: yep, and i could only see that one change | 02:37 |
| wallyworld | client.go plus deletes | 02:37 |
| axw | wallyworld: cool. LGTM, thanks | 02:37 |
| wallyworld | ta | 02:38 |
| axw | wallyworld: I'd like to move that rfc5424 package to live under juju/syslog at some point | 02:38 |
| axw | lumping all standards together is a bit odd, since there's many standards for wildly different things | 02:38 |
| wallyworld | yeah, could do. although i thik the intent was to gather all rfc things there | 02:39 |
| axw | wallyworld: I know that was the intent, it just seems very strange to me. maybe just me... | 02:39 |
| wallyworld | can easily be done, let's discuss with tech board or whatever | 02:40 |
| axw | sure, no rush anyway | 02:40 |
| wallyworld | axw: and here's the juju/juju change http://reviews.vapour.ws/r/5218/ (not that it can land, sigh) | 02:55 |
| axw | wallyworld: LGTM | 02:57 |
| wallyworld | ta | 02:57 |
| veebers | Hi axw, you have a moment to help me out. I'm attempting to generate some certs that I can use with the log forwarding feature and a rsyslog sink (this is for testing the feature) | 04:03 |
| veebers | axw I can't seem to generate a cert that juju is happy with, it complains about there not being any IP SANs, I'm sure I'm generating the certs correctly | 04:04 |
| axw | veebers: what are you using for "syslog-host" config? | 04:06 |
| veebers | axw syslog-host: 10.194.140.165:10514 | 04:07 |
| veebers | axw I'm using certtool to gen the certs (creating a ca cert and some client/server certs too) | 04:07 |
| axw | veebers: try using the hostname that you used when generating the cert | 04:08 |
| axw | rather than IP | 04:08 |
| veebers | axw: I don't have any dns setup for this as I've just bootstrapped and deployed rsyslog, added certs and config then exposed it for the rsyslog sink. Are you suggesting that I need dns settings for that machine for this to work? | 04:15 |
| axw | veebers: either you need DNS, or when you generate the cert you need to include an IP SAN | 04:16 |
| veebers | axw: the IP SAN is that for both the ca cert and the client/server cert or just one of them? I'm pretty sure I'm setting that for the ca cert | 04:17 |
| axw | veebers: for the server cert at least, not sure how client cert verification works | 04:18 |
| veebers | axw: hmm so what I'm doing at the moment is creating a ca cert, then I'm creating a cert that I sign with the ca cert and using that on the rsyslog server as well as the juju config. For the server should I create a cert and use that + ca cert and then a different cert for the client? | 04:20 |
| axw | veebers: for a more realistic setup, yes. I'd stick with the one cert to start with until you get that working, and expand, though. | 04:24 |
| veebers | Probably worth mentioning; the certs that I'm generating work fine when using just rsyslog (i.e. 2 machines one sending to the other) | 04:24 |
| axw | veebers: interesting. that would seem to imply they're not doing strict host verification | 04:25 |
| veebers | axw: ok, right now I'll try adding the ip address to the client cert (as opposed to the ca cert) too and see if I get any joy | 04:25 |
| veebers | axw: that thought did cross my mind, could be the way I have it configured | 04:26 |
| veebers | i.e. Using the config from the top answer here: http://serverfault.com/questions/666827/using-rsyslog-with-tls-without-generating-a-self-signed-cert | 04:26 |
| veebers | axw: huh, I think that's working now. Is there an action I can do that would create a log that would be forwarded? | 04:43 |
| axw | veebers: anything and everything that goes over the API | 04:44 |
| axw | veebers: you shouldn't need to do anything really, logs just happen | 04:45 |
| veebers | axw: I'm wanting something reproduce-able so I can check that it works now as well as incorporate it into the ci test :-) | 04:46 |
| veebers | I saw a large influx of messages just at the end of the bootstrap but nothing since, want to force some message so I can confirm all is wired up correctly | 04:47 |
| axw | veebers: fair enough. umm. I'm not sure what's a good candidate for a useful log message. you can just do "juju status", and you should expect to see an apiserver log message | 04:47 |
| axw | that should have the word "FullStatus" in it | 04:47 |
| veebers | axw: Hmm, 'juju status' doesn't change anything in either the rsyslog sync or the logs in /var/log/juju/machine-0.log (on the newly bootstrapped machine) although there seems to be an error in the last log: http://pastebin.ubuntu.com/19050127/ | 04:50 |
| axw | veebers: dunno what that's about. I think you won't get the log message unless you're at DEBUG level. I'll see if there are anyt interesting INFO messages | 04:51 |
| axw | although, I think we default to WARNING? | 04:52 |
| veebers | I'm not sure about the default logging level, I don't mind changing it for now or during the test assuming that's valid test cover | 04:54 |
| axw | veebers: I think it's going to be necessary, at least until we change the default to INFO (which I think there was agreement upon in London) | 04:57 |
| axw | veebers: if you're at INFO level, you should see "API connection from <IP>" whenever a client connects | 04:57 |
| axw | veebers: so you could just run "juju status" and look for that | 04:58 |
| veebers | axw: sweet, so changing log level is as easy as: juju set-model-config logging-config="<root>=INFO" -m controller ? | 04:58 |
| axw | veebers: yup | 04:58 |
| veebers | sweet cheers | 04:58 |
| veebers | axw: wow ok, so doing that and then a status floods the log with: http://pastebin.ubuntu.com/19050776/ | 04:59 |
| veebers | over and over again | 04:59 |
| veebers | I just killed the controller as it was pegging my system (jujud) | 05:00 |
| axw | veebers: huh :/ | 05:03 |
| axw | wallyworld: ^^ there's probably a log forwarding loop | 05:03 |
| wallyworld | awesome | 05:04 |
| wallyworld | hmmm, i think i saw a bug last week with that outout | 05:05 |
| wallyworld | veebers: axw: this seems to be the same thing https://bugs.launchpad.net/juju-core/+bug/1599779 | 05:09 |
| mup | Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage' emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779> | 05:09 |
| wallyworld | not sure that it's log forward related | 05:09 |
| axw | ah yes, I think this is the same issue that jam mentioned to me during the sprint - because of how we're using "ForModel" internally in state | 05:10 |
| veebers | wallyworld: that looks like what I saw, but seems it was more than once a second. /var/log/syslog on the controller was flooded | 05:11 |
| wallyworld | hmmm, maybe the log forward worker is not marking logs as sent, so it just keeps sending the same thing, not sure | 05:12 |
| veebers | axw, thanks for you help. At any rate I was able to get something working. I'll look at using dns in the certs and how we might do that under a test environment | 05:13 |
| axw | veebers: no worries | 05:13 |
| mup | Bug #1600722 opened: MachineSuite.TestHostedModelWorkers is unreliable <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1600722> | 08:56 |
| voidspace | frobware: babbageclunk: be at standup in 5 minutes or so | 09:02 |
| frobware | dooferlad: standup today? | 09:09 |
| axw | wallyworld: first of many: http://reviews.vapour.ws/r/5219/ | 09:12 |
| wallyworld | ok | 09:12 |
| wallyworld | axw: fyi i've removed the controller model check - just get the controller uuid directly now, still getting tests to pass in my branch | 09:15 |
| axw | wallyworld: great, thanks | 09:15 |
| wallyworld | axw: lgtm, hopefully we can land stuff soon | 09:23 |
| axw | wallyworld: ta. I've got another one coming with changes how we pass timeouts to MAAS and the bootstrap-state jujud code | 09:24 |
| wallyworld | ok, may be afk for a fried time | 09:24 |
| wallyworld | brief | 09:24 |
| wallyworld | lol | 09:24 |
| urulama | axw, wallyworld: is this a fix for access key issue? | 09:24 |
| axw | urulama: authorized-keys issue? | 09:25 |
| urulama | axw, wallyworld: and good evening :) | 09:25 |
| urulama | axw: yes, sorry | 09:25 |
| wallyworld | urulama: yeah | 09:25 |
| wallyworld | but the landing bot is preventing landings as it wants all windows tests to pass | 09:25 |
| urulama | geat :-/ | 09:27 |
| frobware | voidspace: want to do 1:1? | 09:36 |
| urulama | mgz: you around? can you revert the changes for windows tests so that beta12 actually becomes useful (like be able to deploy an application) | 09:38 |
| urulama | wallyworld, axw: do you know what the status of this one is? https://bugs.launchpad.net/juju-core/+bug/1593828 | 09:41 |
| mup | Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1593828> | 09:41 |
| axw | urulama: no clue, sorry | 09:43 |
| voidspace | frobware: sorry, my wife got back from dropping off her dad at the airport and I went to talk to her | 09:44 |
| voidspace | frobware: sure, can do 1:1 | 09:44 |
| frobware | voidspace: in the ho | 09:46 |
| babbageclunk | urulama: I'm working on it - it's a bug in mgo. There's a PR to fix it, I've had it reviewed and am waiting to get it merged. | 09:51 |
| babbageclunk | urulama: once it's merged into the v2 branch I can start updating the mgo version in the various dependencies.tsv files. | 09:52 |
| urulama | babbageclunk: thanks ... any estimation when it might land? it's annoyingly consistent when trying to stress test the controller how many machines and units it can handle :) | 09:53 |
| urulama | (annoyingly consistent at failing that is) | 09:53 |
| babbageclunk | urulama: Hopefully merged into mgo today (depending on reviewer time) - then there are 11 packages to get updated, so that might not get into juju/juju (at the end of the dependency chain) until tomorrow sometime. | 09:57 |
| babbageclunk | urulama: Are you using beta packages or source? It should be in the beta getting cut this week. | 09:58 |
| urulama | babbageclunk: cool, thanks. also, it looks like tests are failing, which might be an issue to land it as well :) https://github.com/go-mgo/mgo/pull/291 | 09:58 |
| babbageclunk | urulama: Yeah - that's an occasional failure in the mgo test suite. :( | 09:59 |
| urulama | babbageclunk: using source, will have an eye on when this lands | 10:00 |
| babbageclunk | urulama: not anything to do with my change but I'm going to try to sort it out, it's bitten me twice now. | 10:00 |
| babbageclunk | urulama: ok - I'll put an update on the bug now and keep you updated when there's movement | 10:01 |
| jamespage | frobware, one for your list - https://bugs.launchpad.net/juju-core/+bug/1600546 | 10:08 |
| mup | Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic <sts> <juju-core:New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546> | 10:09 |
| frobware | jamespage: ack & thanks | 10:11 |
| jamespage | well lathiat can take the credit for finding that one :-) | 10:12 |
| babbageclunk | Ugh, I just realised I'll need to do a topological sort of the transitive closure of packages that depend on mgo. | 10:17 |
| urulama | babbageclunk: thanks (and auch, on the last one) | 10:37 |
| babbageclunk | urulama: :) | 10:37 |
| mgz | urulama: sorry, which tests? | 11:21 |
| mgz | oh, it's the whole do we want gating or not thing | 11:21 |
| urulama | yes | 11:21 |
| mgz | well, there's a reason I pushed back on adding gating here, but... we *were* asked to | 11:21 |
| urulama | ok | 11:21 |
| mgz | urulama: there's actually a fun bug that circumvents the gate | 11:22 |
| urulama | lol | 11:22 |
| mgz | urulama: but I will disable the windows part if we have general agreement | 11:22 |
| urulama | i mean, critical bug fixes can't land | 11:23 |
| urulama | we can wait for Torsten to be up in 2h ... | 11:23 |
| mgz | urulama: more a question for cherylj/alexisb | 11:23 |
| mgz | but you+ian will do | 11:23 |
| mgz | test regressions generally are critical bugs | 11:23 |
| urulama | agree | 11:24 |
| mgz | urulama: anyway, I'll fix the bug in the script and remove windows from the list of jobs for now | 11:24 |
| urulama | mgz: ok, thanks | 11:25 |
| mgz | urulama: done | 11:26 |
| urulama | ty ... now i hope Andrew's branches land soon :) | 11:26 |
| mgz | you can retrigger if it's approved | 11:26 |
| mgz | I doubt he'd mind | 11:27 |
| urulama | mgz: done, let's see if tests pass now :) | 11:29 |
| babbageclunk | jam: gah, so there are a couple of cycles in the dependencies: juju-romulus and charmstore-charmrepo. How do you think I should handle those? | 11:31 |
| dooferlad | macgreagoir: standup? | 11:32 |
| urulama | rogpeppe, ashipika: ^ see comment from babbageclunk | 11:32 |
| mgz | babbageclunk: kill romulus | 11:32 |
| urulama | LOL | 11:32 |
| babbageclunk | mgz: very classical | 11:33 |
| ashipika | mgz: et tu? | 11:34 |
| ashipika | urulama, mgz, babbageclunk: the proposed solution was to integrate romulus into juju core.. which is on our todo list.. | 11:34 |
| mgz | kill, integrate, much the same | 11:35 |
| ashipika | mgz: there's a certain Julius C. that would disagree :D | 11:35 |
| ashipika | we're one sprint in Rome short of a Remus.. then we'd have a classical duel on our hands :) | 11:36 |
| urulama | mgz: thanks, https://github.com/juju/juju/pull/5772 landed | 11:43 |
| mgz | urulama: ace | 11:44 |
| babbageclunk | ashipika: Ok, that's the long-term solution, but how should I update mgo in the meantime? (Trying to think it through but it's making my head hurt.) | 11:44 |
| ashipika | babbageclunk: update the juju-core dependency first, merge, update the romulus dependency second (it depends on the core), merge.. i guess | 11:45 |
| babbageclunk | ashipika: And it doesn't matter that the dependencies will conflict? | 11:46 |
| babbageclunk | ashipika: does godeps handle that already? | 11:47 |
| ashipika | babbageclunk: hmmm.. i think it should all work out.. i hope.. | 11:47 |
| babbageclunk | ashipika: I guess I can just try it! Thx | 11:47 |
| ashipika | babbageclunk: good luck.. ping me if it doesn't work | 11:48 |
| babbageclunk | ashipika: It should be ok, since the bugfix doesn't change any interfaces. | 11:49 |
| babbageclunk | ashipika: thanks, will do! | 11:49 |
| urulama | mgz: hm, so how come that branch from Andrew got merged, but then CI stated it's bad (at juju.fail) and then if you try it, it works? (/me just tries to understand what failed and why :D) | 11:52 |
| mgz | urulama: hm, I guess I screwed something up | 11:54 |
| mgz | oh, there's a trailing backslash all the way over there >_< | 11:55 |
| urulama | babbageclunk: does this mean that you already have your fix landed in mgo? | 11:56 |
| mgz | welp. fixed, good thing the branch had in fact already passed. | 11:59 |
| rogpeppe | babbageclunk: what specific problem are you having? | 12:05 |
| babbageclunk | urulama: No, just getting ready for the next bit. | 12:08 |
| babbageclunk | rogpeppe: nothing yet - just trying to decide what order to update the dependencies when it's time to. | 12:09 |
| rogpeppe | babbageclunk: note that the cyclic dependencies from charmstore<->charmrepo are only because charmrepo uses charmstore for its tests | 12:09 |
| babbageclunk | rogpeppe: ah, ok - that is a lot less worrying. | 12:10 |
| rogpeppe | babbageclunk: FWIW i think it's a mistake that it should do so and i think i've worked out what the right answer is, but it'll be a while before we get around to fixing that | 12:10 |
| babbageclunk | rogpeppe: but if the tests pass then it should be ok, anyway. | 12:11 |
| rogpeppe | babbageclunk: yup | 12:11 |
| babbageclunk | rogpeppe: Thinking it through a bit more I was worrying too much - it's not like there'll be two versions of the code in memory, it just determines which version godeps checks out. Right? | 12:13 |
| rogpeppe | babbageclunk: right | 12:13 |
| rogpeppe | babbageclunk: you'll need to choose one version for all deps | 12:14 |
| rogpeppe | babbageclunk: i usually use the newest version of all deps if in doubt | 12:14 |
| babbageclunk | rogpeppe: yeah, that makes sense | 12:14 |
| rogpeppe | babbageclunk: the -N flag to godeps can be useful too | 12:14 |
| rogpeppe | babbageclunk: for coming up with a coherent "latest tested" set of deps from several projects' dependencies.tsv files | 12:15 |
| babbageclunk | rogpeppe: ok, will use that. Thanks! | 12:15 |
| jam | babbageclunk: I would think that neither romulus or charmrepo expose mgo as part of their interface. | 13:27 |
| jam | as long as they aren't returning an mgo.Doc or something like that, we should be ok | 13:27 |
| jam | (mgo.D/B) | 13:27 |
| jam | babbageclunk: I'm in favor of updating deps, I'd just mention that if we aren't on the latest *today*, there there is probably a reason, and I don't want to dump all of that on you. | 13:28 |
| jam | babbageclunk: they need your mgo fix more than they need newest of all other deps | 13:28 |
| junaidali | Hi everyone, what is the equivalent command for $ juju set-constraints tags=controller in Juju2.0 | 13:42 |
| frobware | junaidali: set-model-constraints (http://pastebin.ubuntu.com/19079305/) | 13:53 |
| junaidali | thanks frobware | 14:09 |
| babbageclunk | jam: good point, I'll make sure that I'm only updating deps (other than mgo) when they're on the latest. | 14:11 |
| mup | Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600> | 16:09 |
| voidspace | babbageclunk: frobware: dooferlad: firefox crash! omw | 16:12 |
| mup | Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600> | 16:24 |
| voidspace | frobware: are you going to mid-cycle? | 16:26 |
| frobware | voidspace: nope | 16:26 |
| mup | Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600> | 16:27 |
| voidspace | frobware: do you know anyone from the UK who is? | 16:27 |
| frobware | voidspace: and from juju core? | 16:27 |
| voidspace | frobware: I left my boots behind in the US - so if I can get them shipped to someone in the US going to the mid-cycle and get someone from the UK to bring them back | 16:28 |
| voidspace | frobware: then it will be cheaper than getting them shipped to the UK | 16:28 |
| voidspace | frobware: anyone from the UK willing to do me a favour... :-) | 16:28 |
| voidspace | frobware: but I have no idea who's going | 16:28 |
| mup | Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600> | 17:09 |
| mup | Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600> | 17:12 |
| mup | Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600> | 17:30 |
| mgz | anyone got something they want to land and doesn't mind being a guinea pig? | 17:32 |
| voidspace | dooferlad: ping | 17:37 |
| mbruzek | mgz: or balloons: did you come up with another solution for the bash completion problem? | 18:56 |
| mbruzek | mgz: or balloons: I had the wrong target on Friday, it is cleaned up to this: https://bugs.launchpad.net/juju-core/+bug/1600257 but balloons mentioned there might be a "better" way to solve that problem. | 18:57 |
| mup | Bug #1600257: The tab completion on juju yields KeyError: 'services' <bash-completion> <packaging> <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1600257> | 18:57 |
| mgz | mbruzek: I do wonder if we want a wrapper script like juju-version rather than a symlink, I'm not sure how nicely the bash completion mechanism plays with that | 19:01 |
| mgz | does it avoid registering completions twice if the same script is executed twice under different names? | 19:01 |
| mbruzek | mgz: OK but I believe the issue was how to not collide with juju1 bash completion | 19:01 |
| mgz | is there a better way of auto-loading for aliases? | 19:01 |
| mgz | mbruzek: that is an issue, but we also need to update the juju 1.25 packaging, and own both parts | 19:02 |
| mbruzek | mgz in my testing the symbolic link worked and I was not getting double completions, but I will admit my testing was incomplete | 19:02 |
| mgz | mbruzek: so, that's the jist of my code review questions | 19:03 |
| mbruzek | mgz: OK I will read up on bash completion aliases and see what I can find. If you or balloons have a different solution please let me know to stand down | 19:04 |
| alexisb | do we have anyone still online on the networking side | 21:10 |
| alexisb | frobware, voidspace possible?? | 21:10 |
| frobware | alexisb: if we're quick... | 21:11 |
| alexisb | frobware, was just recreating this bug: https://bugs.launchpad.net/juju-core/+bug/1516150 | 21:12 |
| mup | Bug #1516150: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-reboot> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1516150> | 21:12 |
| alexisb | and when looking at the code paths for filtering ip address I found this fucntion: | 21:12 |
| alexisb | filterLXCAddresses | 21:12 |
| alexisb | in : juju/juju/network/network.go | 21:12 |
| alexisb | which seems rather useless given /etc/default/lxc-net doesnt exits anymore, right?? | 21:13 |
| alexisb | frobware, this is not urgent I am just curious | 21:13 |
| alexisb | if I should open a bug | 21:13 |
| frobware | alexisb: jam recently landed a change for filtering lxd bridge addresses | 21:14 |
| alexisb | ah, ok I iwll look at those | 21:14 |
| alexisb | thanks | 21:14 |
| frobware | alexisb: http://reviews.vapour.ws/r/4478/ | 21:15 |
| frobware | alexisb: if there's nothing else then it's EOD for me. I only popped in to turn off some of my machines... | 21:16 |
| alexisb | frobware, nope, I will catch you tomorrow, thanks! | 21:16 |
| alexisb | sorry for the intrusion | 21:16 |
| frobware | np | 21:16 |
| mup | Bug #1602010 opened: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010> | 21:24 |
| jcastro | does anyone know how I can set this? https://github.com/juju/juju/search?utf8=%E2%9C%93&q=test-mode%3A+true | 21:46 |
| jcastro | I need to be able to set that variable in 2.x | 21:47 |
| jcastro | but since I don't have an environments.yaml to put it in ... | 21:47 |
| jcastro | test-mode:true is what I am trying to set | 21:47 |
| === urulama is now known as urulama|__ | ||
| === alexisb is now known as alexisb-afk | ||
| mup | Bug #1602032 opened: Add machine and core count to 'models' output <juju-core:New> <https://launchpad.net/bugs/1602032> | 23:22 |
| mgz | wallyworld: can you explain your change for bug 1599905 to me? | 23:45 |
| mup | Bug #1599905: rfc5424 standard has a non-free license <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1599905> | 23:45 |
| axw | wallyworld: http://reviews.vapour.ws/r/5221/ | 23:49 |
| mup | Bug #1602034 opened: 'ERROR connecting with bootstrap config' for status on destroyed model <juju-core:New> <https://launchpad.net/bugs/1602034> | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!