[00:03] perrito666: which bug? [00:23] axw: go a minute? [00:24] got even ^ [00:46] Bug #1611159 opened: model not successfully destroyed, and error on "juju list-models"

[00:49] redir: did you want to catch up? [00:49] or you all good? [00:49] wallyworld: sure, gimme 1 minute [00:51] k [00:51] standup? [00:51] wallyworld: ^ [00:51] ok [01:11] redir: sorry, was afk [01:29] np just off HO with wallyworld, going EoD but will prolly hit you up tomorrow. [01:33] * redir goes EoD === natefinch-afk is now known as natefinch [02:05] axw: let me know when/if you'd like to spend a little time discussing the jsonschema stuff... otherwise, Í'll get to writing that proposal for it that I was supposed to do earlier. [02:07] natefinch: happy to chat whenever, I think having a proposal first would be best though - something concrete we can discuss and mould [02:08] axw: cool, will whip something up. [02:28] weird, somehow chrome is linking zoom size to domain... if I have two different chrome windows open - if they're the same domain, they both increase or decrease in size. If they're different urls they change independently. [02:29] which is super annoying when I want to have godoc open on two different monitors with vastly different pixel densities [02:31] * natefinch switches one window to gowalker.org ... oh the indignity [02:56] anastasiamac: I have added this change to the PR, as it was failing with mongo 2.4: https://github.com/juju/juju/pull/5877/commits/ac97bffd0261f06df93255bed0a48ce35d1a5eb1 [02:56] anastasiamac: tested with mongo 2.4 and 2.6 (2.6 works with and without the change) [02:56] 2.4 works only with the change [02:57] axw: 2.4 does like "or" :( ..?.. [02:58] anastasiamac: not really sure what it doesn't like, seemed kosher to me [02:58] anastasiamac: but they're bot happy with $ne even if hte field doesn't exist [02:59] excellent \o/ lgtm [03:33] menn0: one thing that i miss when using juju from a snap is tab completion :-) [03:33] wallyworld: yeah true. I guess there might be some kind of workaround where juju completion workers for *.juju too but that's a bit hacky [03:34] s/workers/works/ [03:34] i'm sure we can fix it somehow [03:56] Bug #1580391 changed: juju/errors tests do not pass with go 1.6

[03:59] anastasiamac: PTAL at http://reviews.vapour.ws/r/5392/ when you have a moment [03:59] anastasiamac: i.e. please see my replies [03:59] * axw goes for lunch [04:08] wallyworld: could u do a quick ho in a-team call? [04:08] ok, give me a minute [04:09] wallyworld: k. ping u r available [04:12] when* [04:13] my proposal for conversion to jsonschema for anyone interested: https://docs.google.com/document/d/137ejUl8qRAU98F4eg9jfO9L90fkkvRZ5aGINmaxKlM0/edit# [04:14] anastasiamac: there now === tasdomas` is now known as tasdomas [04:53] axw: I'm a little stuck on the actual implementation of getting the non-jsonschema values into useful places in our code... without terrible hacks. Any ideas you have there are welcome. I'm going to go to bed.. will check my email overnight, so when william gets up, you guys figure out a time to talk, and I'll get up and talk. [04:53] axw: unless you think it would be useful to talk now for a bit, without william [04:54] natefinch: I need to think about it some more first I think [04:54] ... think think [04:54] axw: no problem. I've gone around and around on it. I welcome more brains being applied to the problem. [06:52] axw, menn0, jam: shall we talk schemas? [06:52] fwereade: happy to, but shouldn't we wait for natefinch? [06:54] axw, perhaps, but I'm not sure when he'll arrive; and several of us look likely to be here; and I got the impression that you were pretty happy with the proposal in the doc [06:56] fwereade: okey dokey, I can chat with natefinch about it tomorrow if need be [07:01] axw, so, well, *I'm* happy with the proposal in general, and have no attachment to juju/gojsonschema if a different library gives us something we need [07:01] fwereade: agreed, as long as we end up with one or the other [07:01] (and not both) [07:02] axw, right, yes, we should replace the action bits if we switch [07:03] fwereade: do you have an opinion on whether we should retain the EnvVar bits? [07:03] or Group? [07:03] I'm *fairly* sure Group is redundant now [07:04] anything that's "juju defined" shouldn't really be in the model config anyway [07:05] * axw just waits for doc comments to roll in [07:05] axw, I'm very happy to drop group [07:05] axw, and I am a bit snooty about the env var bits [07:06] axw, do you think we can cast them as interactive-only? in which add-credential is considered interactive? [07:06] fwereade: that's all they would be used for [07:06] axw, it's the "magically grab them from the env" stuff that I always hated [07:06] fwereade: autoload-credentials and add-credential [07:07] axw, yeah [07:07] fwereade: yeah, that should definitely not happen post-add [07:08] fwereade: I guess I can live with it. but it feels kinda awkward that there will be some credential detection methods that just won't work, like looking for files [07:08] axw, (if I were to shoot for the moon I'd prefer a schema that didn't allow defaults, tbh, it's just another way to handwave the difference between ingestion and validation) [07:08] axw, well, we *could* define file paths as well... [07:09] axw, not that I really want to [07:10] axw, but the *important* thing in my mind is not to have the *validation* bits go charging off through the env, filesystem, network, whatever, just to find some value to wedge in and make things look right [07:10] * axw nods [07:11] fwereade: these defaults should only apply when creating. providers can/should take care of adding defaults as necessary on upgrade [07:12] axw, yeah, which is why I'd like to keep default-insertion out of validation too, if we can [07:12] axw, I just don't see a path that doesn't involve us writing our own schema thing [07:14] fwereade: I mentioned this in London: https://github.com/juju/juju/blob/master/environs/interface.go#L121 [07:14] axw, we could just tell people not to specify json-schema defaults (ha), but if people *did* eschew them then it is just the same need as the env/file cases: if not specified, get a value [07:14] fwereade: isn't it enough to just implement that in each provider, and stop modifying config in ValidateConfig? [07:14] fwereade: ah I see what you mean, JSON-Schema validation will insert the defaults? [07:14] axw, yeah [07:16] axw, (regardless, I'm +1 on breaking up the ValidateConfig god-methods any way we can) [07:16] fwereade: I would think we would just ignore the defaults post-creation [07:16] same for env vars [07:17] axw, yeah -- that's easy if we can clearly separate them -- but I don't see how we can avoid default-insertion basically every time we validate a config [07:27] axw: wallyworld: menn0: any suggestions? or workaround for this? https://bugs.launchpad.net/juju-core/+bug/1611159 [07:27] Bug #1611159: model not successfully destroyed, and error on "juju list-models"

[07:30] anastasiamac: nope, sorry [07:32] axw: tyvm! [07:35] Bug #1449044 changed: juju add-unit resets AWS security groups

[07:35] Bug #1548564 changed: restart failed upgrade

=== jamespag` is now known as jamespage [08:08] Bug #1517499 changed: i/o timeout on bundle deployment [08:28] axw: hiya [08:28] rogpeppe: hey [08:28] axw: i just ran across mongotest.DialTimeout... [08:28] axw: it was causing a test to take 5 minutes [08:29] axw: is 5 minutes really necessary as the dial timeout? [08:29] axw: it seems like quite a long time... [08:30] rogpeppe: per the comment, I think so. mostly for the unit test merge jobs, because the machines thrash quite a bit after starting up [08:30] rogpeppe: why is the test taking 5 minutes? sounds like an error in the test? [08:30] axw: well, arguably it's a problem with state.State.Close [08:31] axw: or with the whole strategy used to manage mgo.Sessions in juju [08:31] axw: it's an interesting thing though [08:31] axw: the test that takes 5 minutes is apiserver.serverSuite.TestNewServerDoesNotAccessState [08:32] axw: well... 7/10 times it takes 0.08 seconds; the other times it takes 5 minutes [08:33] axw: it depends how far the state workers get before the state is shut down [08:33] axw: the problem is that the session is copied (with Session.Copy) whenever a mongo operation is performed [08:34] axw: and if the mongo is unavailable (as it is in this test - deliberately), the mongo operation will block until a connection can be made (or it times out) [08:35] axw: and while worker is trying to perform the operation, it cannot be stopped [08:35] axw: and the State cannot be closed until all the workers have been stopped [08:36] Bug # opened: 1611267, 1611269, 1611271, 1611273, 1611275 [08:36] rogpeppe: hrm :( I don't suppose we can tell when the workers are idle? [08:37] axw: how would that help? [08:37] rogpeppe: don't close the proxy until nothing should be accessing it [08:37] rogpeppe: which is... never? the transaction watcher will always be active won't it [08:40] axw: one mo, in a call [08:43] fwereade: so I was bugging dimitern about api stuff yesterday evening, but it got late. [08:47] fwereade: (ping) [08:56] mgz: ping? would now be a good time for me to run some tests against finfolk? [08:59] scratch that, will be back later [09:01] babbageclunk, hey, sorry [09:02] babbageclunk, I did do a little review this am, not sure if that's relevant? [09:02] fwereade: no worries - just noticed the review, going through it now. [09:03] fwereade: I'm not sure what you mean by "wrap the txn-building in a func that guarantees a sensible error" [09:03] fwereade: You mean something other than onAbort? [09:03] babbageclunk, ah sorry [09:04] babbageclunk, there's run, which takes a `func(attempt int) error` [09:04] (I mean, I understand the problem with letting ErrAborted get out, I'll fix that, just wondering if there's a deeper fix than chucking an onAbort around it.) [09:04] babbageclunk, which will get called again if the txn is aborted [09:05] babbageclunk, and if you structure the buildTxn func nicely, you have OAOO place where you check state, and can construct the associated assert at the same time [09:05] axw: yes, the transaction watcher (and the pinger) will always be active [09:06] babbageclunk, so when it fails it just gets called again and you never have to worry about, e.g., having two places to complain about non-dead machines that produce slightly different error messages [09:06] fwereade: Ah, so run can recheck the preconditions each time to work out which one failed and abort with a nicer error? [09:06] babbageclunk, exactly [09:07] babbageclunk, https://github.com/juju/juju/wiki/mgo-txn-example [09:08] fwereade: Right, so if I change Remove, MarkForRemoval and CompleteMachineRemovals to use those then places that add preconditions get a chance to return the right kind of error at the same time as they add the assertion. [09:08] babbageclunk, yes please :) [09:09] fwereade: Ok, thanks, I'll do that. [09:09] babbageclunk, incidentally, if run failed enough you'll get ErrExcessiveContention out, which hsa text something "state changing too fast, try again soon" [09:10] babbageclunk, but what it almost invariably *actually* means is "some developer messed up the correspondence between state checks and txn asserts" [09:10] fwereade: Ah, right. [09:11] babbageclunk, but that's generally easier to understand and fix than when an onAbort triggers in response to ops defined somewhere else, because that means you often just get the *wrong* error message [09:12] fwereade: ok [09:12] babbageclunk, (because someone changed the ops and the client is still assuming there's only one way for the ops to trigger abort) [09:22] axw: i think the real solution is not to Copy the session on every database operation [09:23] axw: but that's a significant change === mwhudson_ is now known as mwhudson [11:03] a small juju-core code cleanup: https://github.com/juju/juju/pull/5954 [11:04] reviews appreciated. fwereade, you'll appreciate this change [11:16] rogpeppe, very nice, LGTM with a trivial [11:16] fwereade: tvm [11:32] fwereade: that trivial is not *quite* so trivial. AFAICS there is no need for that remoteError value at all. it couldn't work even if the call did return an error. and i don't see why that code is invoking FacadeCall directly rather than using an api package. [11:32] fwereade: ha, that *is* the api package :) [11:38] fwereade: Can you take a look at http://reviews.vapour.ws/r/5365/diff/# again? Everything's using buildTxn/run now, but I'm worried I might be doing too much in completeMachineRemovalsOps. [11:46] axw, fwereade: morning... anything you need to talk about? [11:53] * babbageclunk goes for a run. [11:57] looking for a review of a small CLI change for stakeholders to go into beta15 http://reviews.vapour.ws/r/5399/ [11:59] natefinch: I think you're good to get deeper into it - not sure that there's anything to discuss. there's a few comments on the doc. I'm here for a bit but will be disappearing soon - will be more free to chat tomorrow if you're uncertain about anything [12:01] mgz sinzui balloons: any of you about? [12:03] axw: no problem. The comments seems clear, and I think we'll be good to go with it. [12:04] natefinch: did you look at replacing gojsonschema with the other one already? [12:04] for actions === ivyyy_ is now known as ivyyy [12:04] I suspect it'd be trivial, I don't think we do anything particularly complicated there [12:39] babbageclunk, I think that's all fine [12:40] babbageclunk, completeMachineRemovalsOps is quite big but it doesn't seriously upset me [13:06] fwereade: great! Thanks. [13:06] axw: I am now about [13:23] fwereade: babbageclunk What is the sig we send to jujud to stop and uninistall? [13:26] sinzui: I think it's a file that gets left in a directory somewhere, but I haven't found the bit of code yet. [13:28] babbageclunk: touch uninstall-agent, then SIGABRT? [13:31] Bug #1506225 changed: Failed bootstrap does not clean up failed environment w/o --force and error message is unhelpful

[13:31] Bug #1611379 opened: api/backups: restore code needs improvement [13:31] sinzui: not sure about the signal, but that sounds plausible [13:33] babbageclunk: I am reading notes I left to myself more than a year ago. Plenty of time for juju to change [13:35] sinzui: True that. I'm just trying it out. [13:58] natefinch: I think you're ocr? can i get a small review for a stakeholder request http://reviews.vapour.ws/r/5399/ [14:00] wallyworld: will do [14:00] ta [14:03] fwereade: standup ping [14:10] Bug #1516150 changed: LXC containers getting HA VIP addresses after reboot

[14:12] Hi everyone...in juju1 I could upload a local charm to the apiserver, then immediately deploy it via the Deploy api using the 'local:...' url returned by the upload. That doesn't work with juju2 - I get a 'charm not found' error from the api when I Deploy, and the Charms.List api doesn't show my charm. What am I missing? [14:14] mgz, sinzui: for https://bugs.launchpad.net/bugs/1604474, can you leave up a windows VM that CI tried to deploy to? I wasted a lot of time trying to get azure to start a windows machine yesterday [14:14] Bug #1604474: Juju 2.0-beta12 userdata execution fails on Windows

[14:15] natefinch: sure, we just add --keep-env to the job, or just run the test locally with the same flag [14:16] Hi tvansteenburgh - you can deploy a local charm just by specifying the charm directory in juju 2. Or do you want to upload it specifically? [14:16] there's then a slight wiggle making sure you get the env details to actually inspect that machine [14:17] but it's doable [14:17] babbageclunk: yeah but only via the cli right? i'm using the api [14:18] tvansteenburgh: oh, I see. Sorry, not sure. [14:26] tvansteenburgh: Reading the code it sounds like what you're describing should still work. Posting to the /charms endpoint gives you a url back? [14:26] babbageclunk: yeah, a local: url [14:26] but then when i try to deploy using that url, i get charm not fourd [14:26] found [14:27] and if i call the Charms.List api, my charm isn't in the list [14:27] axw: you're not actually around are you? [14:30] natefinch: I run the test scripts locally all the time. I think this will run the windows charms in azure and keep the env about after your send a control-c https://pastebin.canonical.com/162690/ [14:30] tvansteenburgh: Sorry, I'm not familiar with that part of the code at all. [14:30] tvansteenburgh: katco and wallyworld were just talking about some work needed around that code [14:31] tvansteenburgh: I defer to katco on the exact work required/possible bug there but funny that you bring it up right as they're investigating that area of things [14:31] Bug #1516150 opened: LXC containers getting HA VIP addresses after reboot

[14:31] Bug #1611391 opened: model migration fails while removing from original controller

[14:32] sinzui: thanks for the detailed example [14:33] fwereade: around? [14:33] tvansteenburgh: i'll ping you when i open that bug. from my discussions with wallyworld though, i would think that what you're doing should work (i.e. deploying from the api). there is likely something wrong with how we're caching charm archives [14:33] babbageclunk, heyhey [14:34] fwereade: migrations! [14:34] fwereade: I think I should migrate machineRemovals records? [14:35] babbageclunk, I think you should add a note saying they're not migrated because we won't migrate when we're in an unstable state [14:35] fwereade: I *could* treat them like cleanups, but then migration would be blocked by the provider? [14:36] babbageclunk, and double-check with menn0 that "any entity in any state other than alive" == unstable (from migrations perspective) [14:36] fwereade: Ok, so I should treat them like cleanups then - don't let migration happen while there are machineRemovals. [14:36] fwereade: ok [14:36] babbageclunk, yeah -- and just sync up with menn0, I am pretty certain he's about to start on that side of it [14:36] katco: thanks! really eager to get past this - trying to help a customer who is stuck here [14:37] tvansteenburgh: ack. other than asap, what kind of timeframe would be ideal for you? [14:37] fwereade: ok cool [14:38] katco: yesterday? :) [14:38] katco: i know you guys are swamped, whatever you can do [14:38] tvansteenburgh: not a problem. in this timeline you'll have to wait 40y or so while i invent time travel, but the alternate-you will have it yesterday :) [14:39] haha! [14:39] dimitern, re: 1610037, I just uploaded the cloud init logs for both container/host. [14:39] jam, thanks for opening the conversation again about sharing configs for snappy [14:54] katco: ship it with one minor question [14:54] natefinch: tal, ty [14:55] natefinch: ah, yeah the reason i do that is so that the formatting is completely left to the errors package. basically for consistency [14:56] natefinch: e.g. if the errors package ever changes its string formatting (or we use different errors), this would still format correctly in the log [15:01] Bug #1611404 opened: failed migration leaves model unkillable

[15:01] katco: It was a little confusing to me. My first thought was that you were accidentally not saving the annotated error to a local variable.... took me a second to realize you were probably doing it on purpose to let it do the formatting for you. [15:17] I believe my PR's are still invisible, so does someone mind having a look at https://github.com/juju/juju/pull/5956 today? It's upstreaming the snapcraft.yaml file [15:29] niedbalski: thanks, I'll have a look [15:32] niedbalski: /var/log/cloud-init.log from the container is not very useful I'm afraid - I'd like to see /var/log/cloud-init-output.log from the container please, and thanks for adding the machine's /v/l/c-i-o.log [15:34] dimitern, ok. cloud-init and cloud-init-output http://pastebin.ubuntu.com/22811404/ [15:36] niedbalski: is there nothing else in the container's /var/log/cloud-init-output.log? That's very strange.. [15:40] * rick_h_ grabs lunchables [15:41] dimitern, yep, it seems not complete. btw; http://pastebin.ubuntu.com/22811951/ this is the hypervisor. [15:50] natefinch: hey you're OCR, can i get a quick ship it? +8L: http://reviews.vapour.ws/r/5401/ [16:01] Bug #1611427 opened: Code which performs retries should consolidate on github.com/juju/retry

[16:07] katco: I'd feel free to self-review that one and just run with it [16:07] rick_h_: k [16:07] rick_h_: wondering... in the time it took you to type that message, could you have clicked "Ship It!" ;) [16:08] katco: I'm happy to stamp a comment-only change :) [16:08] katco: yes, but then I'd not have said that in the future you should be able to self-review trivial such as that [16:08] katco: so figured I'd type that vs both :) [16:08] hehe [16:08] mgz: ta [16:08] fwereade: still around? [16:24] babbageclunk, heyhey [16:24] fwereade: hey, so now I'm trying to understand auth in the API. [16:26] babbageclunk, basically, your facade is passed a facade.Authorizer that tells you who made the (already-authenticated) connection to your facade [16:27] babbageclunk, often you can just return common.ErrPerm from the facade ctor when you know that the caller isn't allowed -- e.g. a user connecting to a facade intended for a worker [16:27] fwereade: Ok, so there's the AuthModelManager() method, that is only true for something that's running on the controller? I'm using that in the ctor. [16:28] fwereade: You mentioned in the review that AllMachineRemovals should take entities and check that it's the model tag. [16:29] babbageclunk, ah yes [16:29] babbageclunk, right, the AuthModelManager is the right one for the ctor [16:29] Do I do that just by checking that the type of the tag is model, and then calling authorizer.AuthOwner(modelTag)? [16:30] babbageclunk, and... it is sort of ludicrous that the Authorizer *doesn't* have a ModelUUID representing when model it's connected to, but you*can* get that out of state [16:30] babbageclunk, AuthOwner isn't quite right [16:30] fwereade: Maybe HasPermission? [16:30] // AuthOwner returns true if tag == .GetAuthTag(). Doesn't need [16:30] // to be on this interface, should be a utility fun if anything. [16:31] GetAuthTag will be the machine that connected [16:31] babbageclunk, I would (1) reject non-model-tags, and (2) reject model tags that don't match the state's modeluuid [16:32] babbageclunk, for bonus points, a ConnectedModel or something on Authorizer would be much nicer than having to ask state [16:32] fwereade: Ah, right - not really looking at auth at all. [16:32] babbageclunk, yeah, but I think conceptually that info *should* be coming from the authorizer [16:32] fwereade: yeah, that does sound nicer. [16:32] babbageclunk, it's just that it hasn't really evolved much at all over the years [16:32] Ok, I'll try to thread that through. [16:33] babbageclunk, <3 [16:34] And should it accept multiple models? Presumably that would always be denied - the agent's connected to one model specifically, right? [16:34] babbageclunk, connections to a controller muddy the waters a little bit [16:35] babbageclunk, I would probably go no further than reporting *what* model the connection is for, and leave the interpretation of that in the facade, at least to begin with [16:36] fwereade: Right, sorry. I meant that check in AllMachineRemovals facade method. [16:37] babbageclunk, ah, got you, yeah -- the connection is specifically for just one model [16:37] babbageclunk, so constructing a canAccess AuthFunc and passing that on to the rest of your logic is probably ideal [16:37] fwereade: Cool. I'll do the same check on WatchMachineRemovals. [16:38] babbageclunk, that's a `func(names.Tag) bool` iirc [16:38] babbageclunk, perfect [16:38] fwereade: And then the CompleteMachineRemovals and GetNetworkConfig ones already get lists of machines - so I do the checks against them? [16:39] babbageclunk, I think they're implicitly authorized by the AuthModelManager -- whereas if it were just some machine agent, we'd want to restrict info about any *other* machines [16:40] babbageclunk, but this is very much situational IYSWIM [16:40] babbageclunk, deciding what gets access to what is pretty much the facade's primary job [16:40] babbageclunk, we should generally be expecting to write the logic in terms of an AuthFunc chosen by the facade, or something very similar [16:41] fwereade: Yeah, I think I see that. [16:41] babbageclunk, so that when we end up wanting to do the same stuff elsewhere, it's easy to pull that logic into a common/whatever type and parameterise it with an AuthFunc on facade construction [16:42] babbageclunk, e.g. apiserver/lifeflag, where I was very happy to just grab a couple of existing common services and specialise them [16:42] fwereade: Oh, right - I see some things like that in the machiner. [16:43] fwereade: Actually, something related that I was going to ask you about this morning but then got distracted by your review... [16:43] babbageclunk, yeah -- it's not all super-elegant but at least it separates the responsibilities, or lets us chalk out a path towards doing so [16:43] babbageclunk, oh yes? [16:44] fwereade: ProvisionerAPI.GetContainerInterfaceInfo is very close to what I want for getting the network config for machines. [16:44] babbageclunk, then that's a great candidate for just that sort of extraction :) [16:45] fwereade: Right, that was what I was thinking/wondering. It's slightly different because it only uses the first address on the device though. [16:46] babbageclunk, hmm... I'm not sure I have the context for a firm judgment there [16:46] babbageclunk, if there's no drawback to sending extra info to the one that doesn't need all of it, might still be sensible [16:47] fwereade: ok, I'll think about that. [16:47] babbageclunk, there might be something genuinely in common, but there might not ;) [16:47] (not always easy to tell) [16:48] fwereade: might be better to just do my one and then see what's common, rather than the other way around. [16:48] babbageclunk, ack [16:48] fwereade: ok, great - thanks! Sorry to bug you late! [16:48] babbageclunk, http://thecodelesscode.com/case/233 [16:48] babbageclunk, no worries! [16:50] fwereade: cute [16:51] babbageclunk, I like that site a lot, there's some good stuff there [16:51] babbageclunk, occasionally self-contradictory in the very best possible way [16:52] Bug #1611453 opened: manual-provider: systemd services left behind

[16:56] katco: sorry, was out. Looks like you got it though. [16:59] perrito666: got a sec? [16:59] rick_h_: certainly [17:00] perrito666: so pulled that pr down and built a juju with it and verified my local show.go has your patch in it [17:00] perrito666: but it's not working for me when I run $ djuju show-model controller [17:00] perrito666: I get the output for model "default" [17:01] rick_h_: mm, something might have changed since I PRd that, tx for the test, ill re-review it and fix it and re-propose it [17:01] perrito666: rgr ok ty [17:01] perrito666: and let me know if I'm doing something wrong, only built things a couple of times so problem coould be on my end without a doubt [17:02] rick_h_: well the way you describe it, the issue is most likely on my end :) [17:02] perrito666: k, let me know if I can be of any service === frankban is now known as frankban|afk === ivyyy is now known as ivyyyy-brb [17:58] Bug #1611463 opened: GUI: test_upgrade_gui failed KeyError: 'bootstrap-config'

[19:03] sinzui: is there any easy way to check if lp:1596462 is fixed in master? [19:09] katco: Lets be optimistc and close it. http://reports.vapour.ws/releases/issue/5770f063749a56783c8c36fc shows we saw it once a week, but we haven't seen it in 4 weeks [19:09] sinzui: well, i just landed something today that (in theory) should fix it [19:09] sinzui: (last comment in the bug) [19:10] rogpeppe, so I started making the changes to migrate everything from launchpad.net/gnuflag to github.com/juju/gnuflag. I fixed everything in juju/juju, but I see there's imports in several other repos. What's the best way to coordinate this change? [19:11] katco: I suspect this bug was caused by an overloaded server. We restructured tests to avoid cpu starvation [19:11] sinzui: ah. well in any case, even under load the bug should be fixed [19:11] why was it only seen on Fridays? [19:15] sinzui: not sure if that was a question for me. i don't know. weekend test run? [19:17] katco: jsut a public musing. CI doesn't schedule extra work on late Thursday early Friday. The pattern is odd [19:17] Bug #1609494 changed: grant-revoke: reenabled users missing from list-users