| babbageclunk | wallyworld, axw: review please? https://github.com/juju/juju/pull/7010 | 00:13 |
|---|---|---|
| wallyworld | ok | 00:14 |
| babbageclunk | wallyworld: thanks - ended up being a bit stupid | 00:16 |
| wallyworld | a one liner | 00:16 |
| wallyworld | babbageclunk: lgtm | 00:17 |
| babbageclunk | wallyworld: yup - the better fix is lots of lines across 3 packages | 00:17 |
| babbageclunk | wallyworld: thanks | 00:18 |
| wallyworld | for 2.1 this is fine IMO | 00:18 |
| axw | babbageclunk: is that change safe for concurrent AddCharmWithAuthorization calls? will two calls to repo.Get end up getting the same bundle, and one will remove it from underneath the other? | 00:30 |
| menn0 | wallyworld, axw: during cloud-init, the proxy settings are only used to write out to ~ubuntu/.juju-proxy | 01:19 |
| wallyworld | menn0: yeah, that's what i feared | 01:19 |
| menn0 | wallyworld, axw: which is dumb anyway | 01:19 |
| axw | menn0: no, we do also set them for the cloud-init scripts | 01:19 |
| menn0 | wallyworld, axw: the proxy settings aren't used in any other way | 01:19 |
| axw | menn0: see `exportedProxyEnv := w.icfg.ProxySettings.AsScriptEnvironment()` | 01:19 |
| axw | menn0: in cloudconfig/userdata_unix.go | 01:20 |
| axw | err, userdatacfg_unix.go | 01:20 |
| menn0 | axw: you're right. I missed that the proxy settings were executed | 01:20 |
| menn0 | axw, wallyworld: so the one thing we should fix is that the proxy settings should probably be written out to the global profile (which affects all users) instead of just the ubuntu user | 01:22 |
| menn0 | axw, wallyworld: do you agree? | 01:22 |
| axw | menn0: seems reasonable | 01:22 |
| wallyworld | i think so | 01:22 |
| wallyworld | i wonder why we restricted to ~ubuntu in the first place | 01:22 |
| menn0 | axw, wallyworld: which is fine except maybe for the manual provider | 01:22 |
| babbageclunk | axw: ugh, you're right. Ok, I'll have to go for the more invasive way. | 01:23 |
| babbageclunk | axw: thanks though! Luckily the merge failed. | 01:23 |
| axw | menn0: if you manually provision, you're handing over the reins. I think it's fine to do that. ideally we would be able to undo on agent uninstall tho | 01:24 |
| axw | babbageclunk: nps | 01:24 |
| menn0 | axw: yep... which should be doable | 01:24 |
| menn0 | wallyworld, axw: it looks like we don't bother with the proxy settings on windows | 01:24 |
| * menn0 files some bugs | 01:25 | |
| axw | wallyworld babbageclunk: I'm going to be out both standups tomorrow and thursday (dentist, then school assembly) | 02:22 |
| wallyworld | no worries | 02:22 |
| axw | wallyworld: seems you were right, LXD talks to the source directly | 02:30 |
| wallyworld | axw: it was a guess rather than being right :-) | 02:30 |
| axw | wallyworld: but the client does need to connect to the source and the LXD as well | 02:30 |
| axw | wallyworld: so I think it's that initial bit where it's trying to get the info that's going to be the problem | 02:31 |
| wallyworld | right, and that's something we can fix at our end | 02:31 |
| wallyworld | albeit a bit hackish perhaps | 02:31 |
| thumper | well... bollocks, and more bollocks | 02:40 |
| thumper | somehow in my massive pile of changes, I seem to have broken some of the macaroon stuff | 02:41 |
| thumper | seems that what used to end up having a successful post to /auth/discharge, now gets: | 02:41 |
| thumper | cannot get discharge from \"https://localhost:35994/auth\": cannot acquire discharge: cannot http POST to \"https://localhost:35994/auth/discharge\": Post https://localhost:35994/auth/discharge: x509: certificate signed by unknown authority | 02:41 |
| thumper | since this is a test... the tlsConfig should be set to use the CA cert... I think | 02:42 |
| thumper | but this is in the http bakery code... | 02:42 |
| thumper | so NIF | 02:42 |
| thumper | NFI | 02:42 |
| * thumper diggs through the code changes to see if I have inadvertantly deleted something important | 02:42 | |
| thumper | hmm... | 02:44 |
| * thumper thinks some... | 02:44 | |
| thumper | hmm.... I have a cunning plan | 02:45 |
| thumper | hopefully not too cunning... | 02:45 |
| thumper | gah... | 02:46 |
| thumper | I think this is another "localhost" != "127.0.0.1" issue with the bakery apiHost | 02:47 |
| * thumper stretches his brain | 02:53 | |
| thumper | this may or may not work... | 03:22 |
| thumper | I'm hoping it will | 03:22 |
| thumper | it'll save a lot of pain | 03:22 |
| thumper | yay, that fixed the macaroon issue | 03:24 |
| thumper | phew | 03:24 |
| thumper | now for the others... | 03:24 |
| thumper | I may be able to revert some of these other shitty changes I have done | 03:24 |
| thumper | reduce the diff size | 03:24 |
| thumper | hazaah | 03:24 |
| * thumper afk for a bit -- kid pickup | 03:38 | |
| === thumper is now known as thumper-afk | ||
| * thumper-afk headdesks | 04:22 | |
| thumper-afk | oh | 04:22 |
| === thumper-afk is now known as thumper | ||
| thumper | FFS | 04:22 |
| * thumper takes a deep breath | 04:22 | |
| thumper | was trying to work out why the mutex values I added weren' | 04:23 |
| thumper | weren't stopping concurrent writes | 04:23 |
| thumper | then I noticed the reciever wasn't a pointer | 04:23 |
| thumper | so every method call got its own mutex | 04:23 |
| thumper | awesome | 04:23 |
| anastasiamac | nice :( what area r u in? | 04:25 |
| thumper | rpc/jsoncodec | 04:28 |
| thumper | it was my doing though, adding the mutex | 04:28 |
| thumper | because gorilla/websocket has checks for concurrent writes / reads | 04:28 |
| blahdeblah | thumper: still around? | 04:53 |
| thumper | kinda | 04:54 |
| thumper | whazzup | 04:54 |
| thumper | ? | 04:54 |
| blahdeblah | remember the "mad-hack" you guided me through when we had missing txn-revnos? | 04:54 |
| thumper | ah... yeah | 04:54 |
| blahdeblah | It's just happened to me for the 3rd time in a different environment, with the same charm. | 04:55 |
| blahdeblah | Wondering if it's worth logging a bug | 04:55 |
| blahdeblah | (given that it's 1.25.x) | 04:55 |
| thumper | really? that is kinda batshit crazy | 04:56 |
| blahdeblah | IKR! | 04:56 |
| thumper | have you been doing any juju upgrades? | 04:57 |
| blahdeblah | this is 1.25.6 and has been for quite a while | 04:57 |
| thumper | hmm... | 04:57 |
| thumper | is it an environment that is resistent to upgrading? | 04:58 |
| blahdeblah | Well, between 1.25.7 and 1.25.9, we were quite resistent to upgrading... ;-) | 04:58 |
| blahdeblah | I don't have a problem with upgrading to 1.25.10, but is that going to fix anything? | 04:59 |
| thumper | not sure... | 05:00 |
| thumper | I'd have to go look at the 1.25.6 codebase | 05:00 |
| thumper | blahdeblah: file a bug with as much info as you have, and I'll take a look to diagnose tomorrow | 05:01 |
| thumper | it is possible that 1.25.10 will fix, but it probably makes sense to look | 05:01 |
| thumper | if I can't find a good answer, at least we can write that on the bug | 05:01 |
| blahdeblah | thumper: I kept detailed notes about what we did and last time just stepped through and fixed it | 05:01 |
| thumper | assign to me too | 05:01 |
| blahdeblah | So I'm happy to go through again and do the same; or would you prefer I left it until we can dive in further? | 05:02 |
| thumper | blahdeblah: no, don't wait to fix | 05:10 |
| thumper | I'll just be reading code | 05:10 |
| * thumper thrashes his computer some more with a full test run | 05:11 | |
| thumper | babbageclunk, menn0: I found a way around the whole "localhost" != "127.0.0.1" issue | 05:11 |
| thumper | much cleaner | 05:11 |
| thumper | thank god | 05:11 |
| blahdeblah | thumper: OK - thanks | 05:15 |
| wallyworld | jam: if you get a chance, i'd appreciate a look at the IngressNetworksForRelation() API implementation in https://github.com/juju/juju/pull/7012. For now I just get state.AllIPAddresses() and filter multicast and loopback. I also filter out IPv6 and AWS didn't like it when updating the security groups | 05:33 |
| jam | wallyworld: looking | 05:38 |
| wallyworld | thanks | 05:38 |
| thumper | hey y'all, got a groovey review: https://github.com/juju/juju/pull/7013 | 05:40 |
| thumper | although babbageclunk did say he'd take it | 05:40 |
| thumper | given that it is huge | 05:41 |
| wallyworld | not thaaaaaat big | 05:41 |
| * thumper is done | 05:42 | |
| thumper | laters folks | 05:43 |
| mup | Bug #1666396 opened: Missing txn-revnos in mongodb leads to missing status updates <canonical-is> <juju-core:New for thumper> <https://launchpad.net/bugs/1666396> | 05:54 |
| axw | anastasiamac: would you please review https://github.com/juju/juju/pull/7014? | 06:53 |
| anastasiamac | axw: in a sec but will :D | 06:53 |
| jam | axw: "the proxy should reject attempts to connect to its own lxdbr0 address" | 07:01 |
| jam | axw: I'm not sure that should be "the proxy should" | 07:01 |
| axw | jam: it should :) what isn't clear? | 07:02 |
| axw | jam: the idea is to show that no_proxy is working | 07:02 |
| jam | axw: so you said the host's IP address on lxdbr0 is 10.250.243.1, and then you set the proxy as 10.250.243.1 if the proxy is rejecting attempts to connect to that address | 07:02 |
| axw | jam: I did also test without no_proxy to show that it *does* fail | 07:03 |
| jam | then nothing can talk to the proxy | 07:03 |
| axw | jam: specifically, it should reject attempts to connect to 10.250.243.1 *through* the proxy | 07:03 |
| axw | I'll reword | 07:03 |
| jam | axw: k, that could be spelled a bit clearer | 07:03 |
| jam | cause I'm pretty sure you're connecting *to* the proxy via that IP :) | 07:04 |
| jam | axw: ugh, just spent 10 minutes searching for the right version, cause we have "github.com/juju/juju/utils/proxy" *and* "github.cqm/juju/utils/proxy" | 07:16 |
| axw | jam: heh yeah :/ | 07:16 |
| jam | axw: we should probably update that code to support CIDR notation | 07:17 |
| jam | I see a fair bit of stuff that plays games with the strings instead of using net.SplitHostPort, etc. | 07:18 |
| jam | axw: hasPort() => strings.LastIndex(':') > strings.LastIndex(']') | 07:19 |
| axw | jam: would be nice, but I don't think $no_proxy supports CIDR normally? | 07:19 |
| jam | seems ... fishy | 07:19 |
| axw | jam: it does a bit. I think it was lifted from net/http | 07:20 |
| jam | axw: yeah, looking at docs it seems it is intended to support domain suffixes instead of IP prefxies | 07:20 |
| jam | prefixes | 07:20 |
| wallyworld | axw: your PR relies on having env vars for proxies to use in the CLI command. and uses model config for the agent related stuff. IIANM. Is that an issue that these 2 sources could be out of sync? | 07:38 |
| menn0 | axw, jam: the fishy string monkeying in the net/http proxy handling code has been fixed in recent versions of the Go stdlib | 07:57 |
| jam | menn0: sounds like we should update our fork | 07:58 |
| jam | wallyworld: I'm somewhat ok with that. "What are the PROXY settings *of my laptop* is not the same as what are the PROXY settings for my cloud" | 07:59 |
| menn0 | jam: our fork in gh/juju/juju/utils/proxy does the right thing I believe | 07:59 |
| jam | menn0: hasPort still does strings.Find | 07:59 |
| jam | sorry strings.LastIndex | 07:59 |
| menn0 | jam: ok right. well in Go 1.6 it's much worse :) | 08:00 |
| wallyworld | jam: yeah, that does make sense, but it can lead to confusion for local lxd cloud where everything runs on same host | 08:00 |
| menn0 | jam: the code looks like current master | 08:00 |
| menn0 | (Go master) | 08:00 |
| menn0 | I believe | 08:00 |
| jam | menn0: net.http.ResetCachedEnvironment() | 08:01 |
| jam | seems to be a thing | 08:01 |
| menn0 | jam: only in an export_test.go | 08:02 |
| jam | yeah | 08:02 |
| jam | I just tracked that down | 08:02 |
| jam | blah | 08:02 |
| menn0 | hence all the trickery | 08:02 |
| jam | menn0: one of those "if its useful in tests, it would *probably* be useful in production for other people" | 08:02 |
| menn0 | jam: indeed :) | 08:03 |
| jam | nobody would ever change proxy settings on the fly, right? | 08:03 |
| axw | wallyworld: that's existing behaviour, didn't want to muck with it right now | 08:10 |
| wallyworld | no worries, it does make sense that that's what it needs to be | 08:10 |
| axw | wallyworld: i.e. we previously would have honoured $http_proxy in the client, but not used http-proxy from --config in the client | 08:10 |
| wallyworld | we should make sure doc is clear | 08:11 |
| wallyworld | and maybe print a message if there are differences when using local provider or something? maybe that's overkill | 08:11 |
| axw | jam: thanks for the review | 08:20 |
| axw | wallyworld: we could print out what proxy settings are detected, might be useful. but not in this PR | 08:21 |
| === jamespag` is now known as jamespage | ||
| perrito666 | does anyone know if tim replicated https://bugs.launchpad.net/juju/+bug/1634178 ? | 11:51 |
| mup | Bug #1634178: login doesn't prompt password <ci> <intermittent-failure> <jujuqa> <login> <juju:In Progress by thumper> <juju 2.0:Won't Fix> <juju 2.1:Triaged> <https://launchpad.net/bugs/1634178> | 11:51 |
| wallyworld | jam: thanks for review, i've replied to comments etc. i'll take another look, but I could not see subnets being populated from the provider at all - the provider (the aws one I looked at) seemed to populate only the ipadresses collection | 11:57 |
| jam | wallyworld: the provider isn't populating subnets, that's the discussion I had with you | 11:58 |
| jam | wallyworld: the ipaddresses is only being populated in 2.1 by the JUju machiner watching the local ip devices | 11:58 |
| wallyworld | jam: oh, i thought we said maas and aws did (via their NetworkInterface implementation | 11:58 |
| jam | wallyworld: but you're missing a bunch of the information, like all the subnets that will be used in the next add-unit | 11:58 |
| jam | wallyworld: they aren't? | 11:59 |
| jam | aws and MAAS should be | 11:59 |
| wallyworld | not that i saw - i traced the code and it all seemed to point to ipaddresses being poulated | 11:59 |
| wallyworld | i'll need to look again | 11:59 |
| wallyworld | i started using AllSubnets() and it never seemed to get populatred | 11:59 |
| jam | wallyworld: all of the "juju deploy --bind space" stuff requires subnets to have values | 11:59 |
| wallyworld | hence i looked at the code and saw ipaddresses | 11:59 |
| wallyworld | ok, i'll take another look | 12:00 |
| wallyworld | i may have misread something | 12:00 |
| wallyworld | jam: i'm looking at the discover spaces worker. that seems to want to update the subnets collection, right? | 12:09 |
| jam | wallyworld: yeah | 12:10 |
| wallyworld | jam: but aws provider does not support spaces discovery | 12:10 |
| wallyworld | so maybe it's only maas that will have subnets collection populated | 12:10 |
| jam | wallyworld: so for AWS, you do manual "juju add-space" and "juju add-subnet" if you want to use "juju deploy --bind", because we don't know what subnet is in what space if you don't tell us. | 12:11 |
| wallyworld | jam: right, so that screws up the firewaller and cmr | 12:11 |
| wallyworld | we want cmr to work without adding spaces | 12:11 |
| wallyworld | without requiring spaces | 12:11 |
| jam | wallyworld: so update the discovery mechanic to record subnets without requiring spaces | 12:12 |
| jam | wallyworld: its still *far* better | 12:12 |
| jam | else you run into "what machines have I actually deployed so far" | 12:12 |
| jam | instead of "what subnets could be in use as soon as I add-unit" | 12:12 |
| wallyworld | right, i didn't didn;t think i needed to do that as i thought aws provider populated its stuff | 12:12 |
| wallyworld | i'm just seeing a lot of this code for the first time | 12:12 |
| wallyworld | not sure what's there already | 12:12 |
| jam | wallyworld: to be fair, *it should have* | 12:12 |
| jam | wallyworld: (I only saw concrete code a few months ago as well) | 12:13 |
| wallyworld | and i'm getting my head across the model etc | 12:13 |
| jam | wallyworld: well, I'm pretty solid on how things "should" be, and loosely aware of how things *are*. :) | 12:13 |
| wallyworld | ok, so i'll rework the PR to use subnets; the fallabck to 0.0.0.0/0 will work, and then i'll need to add stuff to the providers | 12:13 |
| wallyworld | everything is awesome | 12:14 |
| wallyworld | "how things are" is interesting, a fair bit to do still | 12:14 |
| wallyworld | it seems | 12:14 |
| jam | indeed | 12:17 |
| wallyworld | jam: so would it be reasonable to modify the discover spaces worker to say that is the provder doesn't support spaces discovery, just ask it for all subnets (if it supports that which i think aws does) and whack those in the subnets collection? my fear is that subnets appear to have a space name attribute and that if we record subnets with a blank space name, things will screw up later | 12:17 |
| jam | wallyworld: we're currently treating "" as the "unknown" space elsewher, I think its fine | 12:21 |
| wallyworld | jam: ok, i'll see how it goes. i'll look to land this PR after changing t subnets; do a followup which adds the subnet listener to the worker so that as subnets are added async the ingress rules are updated; start fixing the proivders starting with aws to populate subnets info. i wasn't budgeting to that that last bit, nor updating the other providers; hopefully it won't all blow out too much | 12:24 |
| rogpeppe1 | does anyone have strong feelings about removing colors from vanilla loggo and putting them into a separate package under utils? | 13:40 |
| rogpeppe1 | we've had problems with all our services producing unparsable logs because of the default behaviour | 13:41 |
| === rogpeppe1 is now known as rogpeppe | ||
| rogpeppe | and i don't think it's right that a low level logging package should be pulling a bunch of special dependencies for that purpose | 13:41 |
| perrito666 | as long as you dont break juju default behavior | 13:43 |
| rogpeppe | without colors, loggo has no external dependencies. with them, it depends on 6 large external repositories | 13:43 |
| rogpeppe | perrito666: we'll change juju to use the colour writer | 13:43 |
| rogpeppe | perrito666: its behaviour won't change until the loggo dep is updated in juju | 13:44 |
| perrito666 | rogpeppe: wel without colors I would not use juju logger :p so they make sense to me | 13:44 |
| perrito666 | rogpeppe: I dont have objections then | 13:44 |
| rogpeppe | jam, wallyworld: ^ ? | 13:44 |
| perrito666 | rogpeppe: I would feel better if you enlisted the opinion of thumper since he implemented the colour fancines | 13:45 |
| * perrito666 wrote color in brit english just for rogpeppe | 13:45 | |
| rogpeppe | perrito666: ok, i'll post a mail to the list | 13:46 |
| wallyworld | rogpeppe: yeah, best tto ask thumper; i do see you have a point though | 13:46 |
| rogpeppe | perrito666: i never see thumper in my time zone | 13:46 |
| perrito666 | rogpeppe: yes, he seems to be in the exact oposite, would you like for me to ping him so he answers your mail promptly? | 13:47 |
| rogpeppe | perrito666: please | 13:47 |
| perrito666 | rogpeppe: noted | 13:47 |
| rogpeppe | perrito666: ta | 13:47 |
| rogpeppe | perrito666: i'm sure he'll see my mail to the list anyway | 13:47 |
| perrito666 | rogpeppe: certainly just making sure he answers asap | 13:47 |
| rogpeppe | perrito666: i've sent a message to the list | 14:02 |
| perrito666 | rogpeppe: tx, I added an item to my todo to talk to thumper as soon as he says good mornig | 14:02 |
| rogpeppe | perrito666: thanks! | 14:03 |
| perrito666 | jam: ping me if you are back around | 15:16 |
| === mup_ is now known as mup | ||
| cmars | all right, i forget, if i'm going to propose a PR into juju, what should I clone off of / propose merging with? master? develop? staging? whaaa? | 18:55 |
| perrito666 | cmars: hard question | 18:55 |
| cmars | lol | 18:55 |
| perrito666 | I believe it would be safe to branch staging and propose into develop | 18:56 |
| cmars | perrito666, ok, thanks! | 18:56 |
| perrito666 | cmars: although you might want to ask someone else too, I can never recall if staging is up to date with 2.1 | 18:57 |
| perrito666 | sinzui: ? | 18:57 |
| sinzui | perrito666: cmars, for the last 10 days, staging and master have been getting develops blesses. staging is testing the bless develop got a few hours ago. | 18:58 |
| sinzui | perrito666: cmars staging/master is NEVER a stable branch. 2.1 and 2.0 are their own histories... | 18:59 |
| sinzui | which makes you wonder about the intent to always release off og master | 18:59 |
| cmars | hmm | 19:01 |
| cmars | i'll start with staging and cherrypick it wherever it needs to go | 19:01 |
| === frankban is now known as frankban|afk | ||
| babbageclunk | morning! | 19:57 |
| perrito666 | babbageclunk: morning | 19:58 |
| babbageclunk | perrito666: feel like a fairly easy review? https://github.com/juju/charmrepo/pull/110 | 20:10 |
| thumper | well.... shit | 20:13 |
| perrito666 | thumper: ah, one of those mornings | 20:17 |
| perrito666 | thumper: btw, there is a rogpeppe mail that is pretty much just for you | 20:17 |
| perrito666 | babbageclunk: if you can hold until I return from the supermarket ill gladly review that | 20:17 |
| perrito666 | also if any of you is very familiar with how juju handled tools in 1.25 there is someone needing help in the private channel :) | 20:19 |
| babbageclunk | perrito666: dude, if you don't want to just say so. ;) | 20:19 |
| babbageclunk | thumper: feel like a fairly easy review? https://github.com/juju/charmrepo/pull/110 | 20:19 |
| thumper | perrito666: saw it | 20:20 |
| thumper | babbageclunk: how about a call, you can explain you change, and I need a teddy bear | 20:20 |
| babbageclunk | ok | 20:26 |
| babbageclunk | thumper: ^ | 20:26 |
| thumper | babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/lol-wat | 20:26 |
| perrito666 | back | 20:43 |
| === jog_ is now known as jog | ||
| wallyworld | menn0: re bug 1666660 - normally we remove the primary document (the model) before any satellite documents. I assume that will be the focus of your fix? | 21:53 |
| mup | Bug #1666660: list-models sometimes errors after a migration (before model has been removed) <ci> <model-migration> <juju:New for menno.smits> <https://launchpad.net/bugs/1666660> | 21:53 |
| === frankban|afk is now known as frankban | ||
| menn0 | wallyworld: I'm not working on that at the moment and haven't got a specific solution in mind | 22:06 |
| wallyworld | menn0: no worries, was just curious based on the description | 22:07 |
| menn0 | wallyworld: looking at removeAllModelDocs, it removes the model doc last | 22:07 |
| menn0 | wallyworld: which will be the problem | 22:07 |
| wallyworld | yep | 22:07 |
| menn0 | wallyworld: at the point it's called the model is marked Dead | 22:07 |
| menn0 | wallyworld: I suspect that model listing and lookup should avoid Dead models | 22:08 |
| wallyworld | we've had similar issues in the past with other entity->subordinate object relationships | 22:08 |
| wallyworld | yay mgo txns and not being atomic | 22:08 |
| wallyworld | "txns" | 22:09 |
| menn0 | wallyworld: understood | 22:09 |
| menn0 | wallyworld: in this case I think it makes sense for removeAllModelDocs to remove the model last | 22:09 |
| menn0 | wallyworld: in case it fails, leaving the model doc behind makes it possible to retry | 22:10 |
| menn0 | wallyworld: I think GetModel should ignore Dead models | 22:10 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === frankban is now known as frankban|afk | ||
| === thumper is now known as thumper-dogwalk | ||
| blahdeblah | thumper-dogwalk: Did https://bugs.launchpad.net/juju-core/+bug/1666396 make sense? Please let me know if you need any further information. | 23:13 |
| mup | Bug #1666396: Missing txn-revnos in mongodb leads to missing status updates <canonical-is> <juju-core:New for thumper> <https://launchpad.net/bugs/1666396> | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!