[00:01] thumper: here's the logsender worker (not wired up) http://reviews.vapour.ws/r/1244/ [00:27] Bug #1434680 changed: Certificate generated by certupdater worker cannot be used by MongoDB

[00:28] menn0: ack [00:33] thumper: i'm currently pushing branches and writing you a long email [00:33] * thumper nods [00:33] sounds good [00:43] wallyworld: sorry I didn't make the standup, I didn't get much sleep and wasn't feeling well [00:44] axw_: np at all, hope you're ok, take plenty of time to fell well again today if you need to [00:44] wallyworld: last night I got the EBS provider working; it informs the provisioner that it needs a volume before it can proceed to CreateVolumes, and it sets DeleteOnTermination for the attachment if non-persistent [00:44] wallyworld: just need to write lots of tests now [00:45] yay, awesome [00:45] that will involve the new method in goamz too [00:45] ok === kadams54 is now known as kadams54-away [01:00] ocr ptal : forward port of previously reviewed changes into master: http://reviews.vapour.ws/r/1243/ [01:06] wallyworld: is trunk still blocked? [01:06] axw_: no, i unblocked just before [01:06] sweet, thanks [01:06] join the queue [01:07] wallyworld: if you have time, http://reviews.vapour.ws/r/1227/ needs reviewing [01:07] axw_: sure, just need to do a 1.22.1 fix, review is next on my todol list [01:07] nps, thanks [01:11] anastasiamac: do you still want me to review your branch? I see wallyworld has +1d === axw_ is now known as axw [01:12] axw_: sure :D was trying to land but had a failure... if u could review, would be gr8 :D [01:12] anastasiamac: don't wait for me, I'll just have a look and if there's anything just do it in a followup [01:13] axw: sounds gr8! thnx :D [01:17] anastasiamac: your latest changes look fine, thanks [01:18] axw: tyvm :D have fix for failed tests :)) will try to land again! [01:47] axw: a small one https://github.com/juju/juju/pull/1922 [01:53] wallyworld: looking [01:54] ty [01:56] wallyworld: done [01:57] ty [01:57] axw: i've also added a quick drive by fix of an intermittent failure i introduced last night fixing the bug blocking trunk [01:58] ok, looking [01:59] wallyworld: why does that change make a difference? [01:59] axw: because it slightly delays the "now" time from which the expiry is calulated [02:00] to better reflect what is done when generating the cert [02:00] there's 2 expity times - one for ca cert, one for server cert [02:01] wallyworld: and the cert time needs to be before "now" ? [02:01] the expiry tine needs to be before now+10 [02:01] and if now is slightly earlier, the expiry time is slightly after now+10 [02:02] ie don't determine"now" and then do stuff and then generate the cert [02:02] as the doing stuff delay is enough to cause the test to sometimes fail [02:02] ok [02:02] wallyworld: shipit [02:02] ta [02:03] this was a refactored test [02:03] the original used the same expiry time for ca cert and server cert [02:28] thumper: FYI, I believe I have that RB webhook unicode bug fixed [02:33] ericsnow: \o/ [02:38] ericsnow: cool [02:53] wallyworld_, thumper, anyone else: I need to change the "stateaddress" value in the machine's agent.conf (since I'm upgrading it to a state server, it needs to change to localhost). However, I can't see any code that can actually serialize a value out to that. [02:55] natefinch: hey, there's formatter.go files somewhere [02:56] let me have a look [02:58] wallyworld_: I see it - juju/agent/format-1.18.go [02:58] natefinch: there's a format-1.18.go plus, if you have already loaded the config, you can use a ChangeConfig() callback to update [02:59] you don't then need to serialise the whole lot [02:59] wallyworld_: ok, yeah, I did that, must have done something wrong, though. But it's good to know how the magic was happening. [03:00] natefinch: you need to use an AGentConfigWriter to invoke the Change callback [03:00] if you use an AgentConfig, it won't work [03:00] menn0: CI failure due to your upgrade fix? http://data.vapour.ws/juju-ci/products/version-2473/run-unit-tests-utopic-amd64/build-1747/consoleText [03:01] natefinch: i found that out the hard way last night doing a patch to unblock trunk [03:01] natefinch: if you look at the commit, you'll see how i did it [03:01] https://github.com/juju/juju/commit/97028ee0bc998026f0e1ef758ef6afadb1734ac4 [03:01] ericsnow: that's actually wallyworld_'s [03:01] yep [03:01] menn0: ah [03:02] there's a fix proposed [03:02] intermittent [03:02] wallyworld_: cool :) [03:02] landing in 1.22, then 123, then master [03:02] sigh [03:02] * ericsnow hopes we can preempt another blocker bug in the morning :) [03:03] oh yes, i will ensure it [03:03] wallyworld_: :) [03:04] wallyworld_: awesome, thanks [03:04] natefinch: sure, let me know if you get stuck etc [03:04] thumper: about restore->recover... [03:05] thumper: "restore" gives the wrong idea about what it is for [03:05] thumper: "recover" seems to describe it really well though [03:05] I disagree [03:05] thumper: go on [03:05] rebuild? [03:05] backup / restore seems more natural [03:06] are you concerned that you don't restore an environment [03:06] but you recreate one? [03:06] thumper: restore is only meant to me used in the case that your environment blows up and you no longer have a state server [03:06] thumper: the way it is now at least [03:07] wallyworld_: yeah, I was just using agent.ChangeCOnfig, not agent.AgentConfigWriter.ChangeConfig [03:07] thumper: so it covers only one part of what the name "restore" seems to promise [03:07] ericsnow: however, recover doesn't work either [03:07] thumper: PTAL http://reviews.vapour.ws/r/1244/ [03:07] natefinch: that will work, but i think it uses a go routine or something to do it async [03:07] natefinch: not the right thing to use if you just want it done ad hoc on startup or something [03:07] thumper: sure, I'm not married to "recover" as the new name [03:08] in which case, I think we need some more bikeshedding :-) [03:08] thumper: no worries [03:08] wallyworld_: actually, heh, I hadn't actually saved the changes in my buffer yet. That would probably help :0 [03:08] thumper: I opened the bug and the pull request at the very least to get things rolling [03:09] well... some take the pull request to be a slightly more agressive stance on the idea [03:09] thumper: wasn't planning on landing anything until there was more feedback [03:09] normally a PR is "this is they way I think it should be" [03:09] ericsnow: part of the problem is that people take things differently than they way you intend [03:10] it isn't obvious that it is a discussion point [03:10] it is a "here's the fix" [03:10] thumper: ah, makes sense [03:11] thumper: I'll discard the PR for now then [03:11] ok [03:11] cheers [03:16] Bug #1435644 was opened: private cloud:( environment is openstack )index file has no data for cloud [03:16] anastasiamac: thanks for those reviews [03:17] ericsnow: the least i could after u did an amazing review for me :D [03:18] anastasiamac: ha, thanks :) [03:22] ericsnow: done :D but of course my shipit is not loaded with much power :D [03:22] wallyworld_: FYI, I think we're going to be okay leaving things alone in the simplestreams code: https://github.com/Altoros/juju-vmware/blob/master/provider/vmware/image_metadata.go [03:23] anastasiamac: thanks [03:25] ericsnow: looks reasonable - those are the standard extension points [03:25] axw: finally reviewed, sorry about delay [03:25] wallyworld_: yeah, that's what I came to realize [03:30] wallyworld_: nps, thanks [03:36] thumper: finally got a nice big round tuit so I've set up the webhook on each of the repos that RB knows about (except for docs) [03:36] ericsnow: jorge's --journal backport to 1.22 also needs to get into 1.23 [03:36] thumper: I'll keep an eye on those to make sure they're working [03:37] wallyworld_: I thought he landed the original patch before the 1.23 branch was made [03:37] * ericsnow checks [03:37] ericsnow: i could be wrong, but it only seemed to land 5 days ago and when i compared master to 1.23 branch it was missing [03:37] happy to be wrong though [03:39] wallyworld_: no, you're right, it isn't there [03:39] just need to cherrypick the commit [03:39] wallyworld_: I'll make sure that gets in [03:39] ty [03:40] i added the bug to the series and milestone [03:42] wallyworld_: thanks [04:01] wallyworld: FYI, that 1.23 backport patch is now waiting its turn (https://github.com/juju/juju/pull/1925) [04:01] \o/ ty [04:02] wallyworld: wish they were all that easy :) === kadams54 is now known as kadams54-away [04:02] indeed [04:24] jam: ping [04:25] jam: we need to chat about some spec topics [04:25] jam: I'm half preparing dinner, so I'll check back in shortly === thumper is now known as thumper-dinner [04:25] thumper-dinner: k [04:26] jam: ah... you are there [04:26] jam: when is good? [04:26] thumper-dinner: I'm around, so whenever is good for you [04:26] now? [04:26] jam: https://plus.google.com/hangouts/_/canonical.com/spec-chat [04:49] axw: have you ever had a git stash become corrupt? mine just did and I had to try and piece together commits from git fsck --unreachable, and even them i lost a bunch of work :-( [04:50] wallyworld: nope, sorry :( [04:50] wallyworld: that's why I don't ues stash so much... I create branches and push WIP to GH when it gets big enough for me to worry about loss of work [04:51] yeah, i'll have to consider that [04:52] i still have one more big branch to sort out, sigh [06:43] dimitern: I'm adding ModifyInstanceAttribute, but having trouble writing a test as it involves a VPC knowledge that I don't have and don't really have time to learn right now. Would you prefer that I leave out support for SourceDestCheck, or that I put it in without a test for that attribute? [06:44] axw, so what's the problem - it's just a flag set on a ec2test instance [06:45] dimitern: just to check, request-address is part of the phase 1 networking stuff, right? [06:45] dimitern: you can't set it on non-VPC instances. instances in the test double seem to be getting a VPC by default [06:45] axw, yes, that's true - it wasn't even available pre-vpc api IIRC [06:45] jam, yes, it is [06:46] k, it came up as some other stuff [06:46] is request-iface ? [06:46] dimitern: so I can test the error path on my account, but I suspect the test will fail if there's a default VPC in the region [06:46] (thinking about kvm containers, they could create their own iface if they had an IP to assign it, right? [06:46] ) [06:46] axw, how about a simple test like this: set sourcedestcheck, followed by Instances() checking the flag is set on the instance? [06:47] dimitern: that's what I was trying to do, and got errors about not being able to create VPC or subnet or something in AZs [06:47] jam, request-iface is on the roadmap as well (but lower in priority than the rest I guess) [06:47] dimitern: sure, just checking if we actually need it for charms [06:47] do they *need* juju to provide it, or could they do it with their own work after requesting ip [06:47] jam, for *certain* very specific charms [06:48] axw, are you using the shared aws account? this is a live test I guess [06:48] dimitern: my own [06:48] yes, live [06:48] axw, well, if you don't mind adding the test and sending me a link, I can pull you branch and make sure the test pass, how about this? [06:49] dimitern: sounds good, thanks [06:49] jam, for charms that need a dedicated interface, e.g. like in the kvm appliance case, having native support in juju will definitely help [06:50] axw: i haven't looked really hard (not much work on storage today sadly), but kat has added some more to the goose cinder branch, hopefully can be landed when she comes on tomorrow https://github.com/go-goose/goose/pull/3 [06:50] wallyworld: cool, will take a look [06:50] ta, have to head to soccer for a bit [06:51] wallyworld: btw, should be able to deploy with tmpfs and rootfs on master now [06:51] sure, ttyl [08:20] morning o/ [08:21] TheMue, hey, welcome back! [08:21] TheMue, how was CeBIT? [08:22] dimitern: a bit lame, the booth has been more like a recreation area, so we got only few audience [08:22] dimitern: but used the time to visit other cloud providers and to tell them about the benefits of juju [08:22] TheMue, ah :) [08:22] dimitern: e.g. a guy of amazon ;) [08:22] TheMue, nice! did you get to play with some power machines? [08:24] dimitern: sadly not, those few which are installed by IBM are directly used for individual software products [08:24] dimitern: those have been the types of booths we should have [08:24] TheMue, yeah, I see [08:25] dimitern: and also there has been a larger open-source area with many smaller booths [08:25] dimitern: here we would have matched too [08:25] dimitern: will this morning write the report for John, together with some photos of the IBM OpenPOWER area [08:25] TheMue, so how many people where visiting appox ? [08:26] TheMue, ah, nice! I'd appreciate if you share this with us as well :) [08:26] dimitern: actively? one! for the rest I had to catch the people. the guy of redislabls had the same problem [08:26] dimitern: yes, will sent you and Alexis a copy [08:27] TheMue, ok :) [08:27] dimitern: at least we've got a partner here in Germany, selling Ubuntu and OpenStack services. he's interested in doing more with Juju [08:29] * TheMue also the next days has to create a new slide deck for his Juju/Go talk. thankfully already have a lot of material. [08:30] dimitern: seen many usual reviewing and mergin mails during these days. anything else important happened? [08:31] TheMue, great! [08:32] TheMue, well, we had 2 releases :) [08:32] 1.22.0 and 1.23-beta1 [08:32] dimitern: hehe, yes, I've seen. fantastic! [08:52] dimitern: I figured out why my test wasn't working; my AZs are different, so I had to (temporarily) change the default AZ in ec2t_test.go [08:53] axw, hmm - ok, just beware this might lead to some failures [08:53] dimitern: it's the same with the existing tests [08:54] axw, e.g. t1.micro not being available in some AZs, but used in a few live tests [08:54] dimitern: there's a flawed assumption in the live tests. AZs are account-specific [08:55] axw, huh? [08:55] axw, you mean there might be less in some accounts [08:55] dimitern: yes, and they might be different [08:56] dimitern: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#using-regions-availability-zones-describe [08:56] search for "might be different" [08:56] err sorry [08:56] "might not be the same" [08:58] dimitern: I'd appreciate a review of https://github.com/go-amz/amz/pull/44 when you have a moment [08:59] axw, well, I learned something today :) [08:59] axw, sure, will have a look in a bit [09:11] fwereade: no idea how busy you are, i have a status-get PR that needs reviewing. as soon as this lands, I have a status-set one ready to propose. if you have time, awesome, if not fine too. both status-get and status-set tested live with a custom charm. http://reviews.vapour.ws/r/1252/ [09:13] wallyworld, awesome, I will take a look in a mo; in the meantime, I am a little bit baffled by cmd/jujud/unit.go:152 which was apparently yours (a long time ago...) in commit ead4f3ee [09:13] let me look [09:13] wallyworld, is the unit agent starting a container provisioner? if so, why? if not, why are we doing that there? [09:14] fwereade: just got called for dinner, i'll get back to you [09:14] wallyworld, np [09:15] dimitern: Morning o/ [09:16] dooferlad, morning o/ [09:16] dimitern: Just proposed that names change: http://reviews.vapour.ws/r/1253/ [09:18] dooferlad, cheers, will have a look in a bit [09:51] dooferlad: what is a "space"? [09:51] axw: spaces are a juju specific networking term [09:51] axw: A space is a security subdivision of a network. [09:51] axw: it means a named group of subnets [09:51] ok [09:52] axw: so you can have a space that spans several availability zones (for example) [09:55] space seems like a terrible name [09:56] if it means a group, why not call it a group? [09:56] natefinch: I believe Mark picked it [09:57] axw, I'll pull your branch and test it locally before sending the review [09:57] voidspace: :/ [09:57] natefinch: conceptually it forms a single network space though, not a "group of subnets" [09:57] dimitern: cheers [09:57] natefinch: the point is to not [have to] think of it as a group [09:57] gotta go out, will check back later [09:58] but a group is what it is... [09:59] just a bike shed, but something with "network" in the name would be more helpful. netspace perhaps. but sounds like it's already decided [10:04] fwereade: that diff shows the machine and unit agents informing the upgrader what tools version they are running. not sure what you mean about starting a container provisioner. the container provisioner is in worker/provisioner and is run by the machine agent [10:04] dooferlad, standup? [10:08] wallyworld, oh, I see, you took it out of upgrader but didn't move the api method, I didn't look at the diff properly and thought you just hacked an extra call in [10:09] wallyworld, why does container initialisation depend on what tools the agent has reported to the state server though># [10:09] it doesn't does it? i'd have to look at the code again [10:10] fwereade: the container init stuff in the diff is just a drive by logging change it seems [10:10] from trace -> info [10:10] wallyworld, the commit claims it's fixing a bug in which container initialisation fails because the toools haven't been set [10:11] wallyworld, damn sorry bbs [10:11] sure [10:14] fwereade: so, container_initialisation.go, that has NewContainerSetupHandler(), this does indeed create a Broker to start containers, it needs tools to do that (of the right version). all this is set up in the machine agent, not the unit agent [10:14] machine agent has ths code handler := provisioner.NewContainerSetupHandler(params) [10:15] so if tools haven't been set, then when machine agent starts the container handler, the handler can't work properly [10:25] wallyworld, I don't see why a provisioner ever needs to ask the api server for its own tools though [10:25] wallyworld, it *knows* its tools [10:26] wallyworld, the only tools it's guaranteed to be capable of using to provision another machine are the ones it's running already [10:26] wallyworld, independent of what it might have told anyone else [10:27] fwereade: to start a container, it needs the tools tarball [10:28] wallyworld, right, but all it needs to know is the version it's running -- not the version a separate worker told some other dude it was running [10:29] wallyworld, it can ask the apiserver for the tools tarball corresponding to version.Current.Number for the target arch [10:29] wallyworld, in fact it *must*, lest bugs like that one [10:30] fwereade:looking at the code now, the container initialiser gets a ToolsFInder interface which does what you say above i think [10:32] the ToolsFinder method is on provisioner.State [10:32] i think but am not sure that version.Current is passed in, nd a tools list is returned [10:33] wallyworld, yeah, I'm trying to follow those same threads :) [10:34] wallyworld, so then I *think* we should be ok to revert the agent changes and put the SetTools back in Upgrader? [10:34] fwereade: i have no idea, i haven't enough context [10:35] wallyworld, fair enough :) [10:35] the change in that commit is from a while ago isn't it [10:37] fwereade: is this for a particular new bug? [10:49] wallyworld, this is just because I'm trying to do something saner with the unit agent and I noticed that call (which I expected to be in Upgrader) squatting in the middle of APIWorkers() [10:50] fwereade: ah i see, it was maybe expedient at the time, i honestly can't recall. sorry :-( [10:50] wallyworld, no worries at all, I see it was a copy from a release branch ;) [10:52] voidspace, hey, iirc you were involved with the proxy-settings weirdness [10:52] fwereade: right [10:53] fwereade: for my sins, which are many... [10:53] dooferlad: want to be a guinea pig? [10:53] I'm going to gate the juju/names package in a sec [10:53] voidspace, so, AIUI, we encounter problems if proxy settings get set too late [10:53] fwereade: correct [10:54] fwereade: anything that needs network access shouldn't run until after the proxy settings are made [10:54] voidspace, (1) why exactly is that and (2) does that mean we restart the whole agent when we get new proxy settings? [10:54] voidspace, (and if not why not) [10:54] fwereade: so it was contacting the charm store specifically that failed [10:54] fwereade: so the charmrevisionworker was one thing that had problems [10:55] fwereade: I didn't look at what happens when proxy settings change so I can't answer 2 [10:55] voidspace, ok, I am slightly worried that all we've done is mask the problem then [10:55] fwereade: deploying charms failing was the specific bug that caused me to look at the problem [10:56] fwereade: we don't block on waiting for the proxy settings to be set [10:56] fwereade: so we knew we had only made a partial fix, and there's a bug for *that* [10:56] voidspace, and that's specifically in the unit agent trying to download them then? [10:56] fwereade: I believe so [10:57] voidspace, I feel like that ought to be a self-healing problem [10:57] fwereade: the *only* fix I made was to move starting the proxyupdater to be one of the first workers started [10:57] voidspace, uniter tries to download a charm, fails out, gets restarted in 3s, by which time the proxysettingsupdater has run [10:57] so definitely a band-aid rather than a fix [10:57] fwereade: it was failing hard [10:57] mgz: sounds good [10:57] voidspace, *unless* the proxysettingsupdater doesn't actually work [10:58] fwereade: moving it solved *that* problem [10:59] it's possible there's a bug around charm download retrying (worker doesn't die properly - or more likely reports a failed deploy causing the deploy to be cancelled and not retried?) [11:00] voidspace, ok, I think I'll just try to preserve your approach and comment it [11:00] cool [11:04] voidspace, (and, hmm, I don't *think* that'd happen -- now or before -- I'm pretty sure the only special error is ErrConflict, and that only happens well after the charm is downloaded and verified) [11:06] voidspace, (while I remain deeply suspicious about what *actually* happens to the http module when the magic env vars are changed from some random goroutine...) [11:14] voidspace, hey [11:14] voidspace, just about finishing the review on the addresser [11:15] voidspace, considering you're already using interfaces for both the state and environ methods you need, why not just mock those in the test? [11:16] dimitern: I did initially, but it's lot more work than just using the dummy provider [11:16] dimitern: for no particular gain [11:16] voidspace, really? [11:16] voidspace, how so? [11:17] dimitern: well I had an implementation of a mockReleaser and types for storing the calls [11:17] dimitern: and then you call NewWorkerWithReleaser [11:17] dimitern: instead of just breaking the environ method and listening on a channel to get the call [11:18] voidspace, yeah [11:18] dimitern: so I deleted my mockReleaser and ReleaseCall types - they just seemed unnecessary [11:19] dooferlad: okay, land with $$merge$$ in the mp when ready [11:19] voidspace, there's juju/testing stub already there to support calling a type and inspecting the received calls [11:19] dooferlad: it's a more complex project, so may break first try, we'll see [11:19] fwereade: the default Http transport we use specifically checks the environment variables [11:20] dimitern: ok, interesting - I *am* having a problem right now with listening on the dummy channel [11:20] dimitern: I seem to get the same call twice instead of the two different calls I expect [11:20] dimitern: so maybe I should switch back [11:20] voidspace, it does seem a bit more complicated than it needs to be [11:21] voidspace, I'll add some comments with pointers [11:21] dimitern: adding a mockReleaser won't make it less complicated [11:21] dimitern: if you look at the latest diff the tests are quite clean now [11:22] not that they're all passing... [11:22] TestWorkerReleasesAlreadyDead doesn't get the correct release ops... [11:23] dimitern: but thanks, I will appreciate comments! [11:23] voidspace, ok, I really need to go out and catch the DMV before lunch break now [11:23] dimitern: cool [11:23] dimitern: I got your email - it looks fine by the way [11:23] voidspace, I'll send the review I have so far and continue when I'm back - mostly tests remain [11:23] dimitern: but enjoy the DMV... [11:24] dimitern: ok [11:24] :D yeah\ [11:24] mgz: waiting for bot... [11:25] mgz: library problem in Jenkins run [11:25] dooferlad: ta, checking [11:30] hm, go get golang.org/x/crypto and go get golang.org/x/crypto/... both exit non-zero for me [11:30] that's a bit of an issue [11:30] what's names actually using... [11:33] testing, utils, and mgo.v2 use various bits [11:33] wwitzel3: I got ensure-availability --to 1,2 working, although it requires a manual reset of jujud... I think mongo just didn't have time to initialize before we restarted.... not sure why it's different in this case from a normal state server creation. [11:35] but only utils needs the custom one, and only pbkdf2 and ssh [11:37] dooferlad: landed [11:37] the log is a bit annoyingly out of order, I probably need to throw in flushes [11:37] mgz: cool. Thanks! [11:44] voidspace, https://bugs.launchpad.net/juju-core/+bug/1403225 [11:44] Bug #1403225: charm download behind the enterprise proxy fails

[11:45] voidspace, comments 20-21 seem to indicate that unconditionally setting the env vars was sufficient to get a unit deploying [11:46] voidspace, and charmrevisionworker is only needed on state servers iirc [11:47] voidspace, was there another motivation for starting it early in the unit agent? [12:00] fwereade: I believe I was mistaken about unconditionally setting the env vars [12:01] fwereade: as once I'd started the proxyupdater early unconditionally setting env vars was not needed, but was considered harmless [12:01] fwereade: my final conclusion was that the existing logic around setting env vars was correct, just started too late [12:01] fwereade: and I didn't move charmrevisionworker - I moved proxyupdater [12:01] voidspace, isn't it necessary? I strongly suspect it's possible for proxy settings to change [12:02] fwereade: it is possible, but the logic that determines that was correct [12:02] voidspace, right, but cmd/jujud/unit.go:158 [12:02] voidspace, the unit agent doesn't run a crw [12:02] fwereade: there was a suspicion that the logic around *first setting* was faulty - but that proved to be incorrect [12:03] fwereade: but *anything* that needs external network access will need the proxy settings in place [12:03] fwereade: so if we have proxy settings it seems like they ought to be put in place before we do anything else [12:03] voidspace, but anything that doesn't have the proper network settings in place should just be exiting with an error and coming back up in a bit [12:04] voidspace, and that will be everything that needs network access if the proxy settings change while an agent's running [12:04] fwereade: if the agent is in process then it won't be a problem - the proxyupdater handles change to env vars without needing to restart [12:05] voidspace, right, and so it's similarly not a problem if we start up with the wrong proxy settings [12:05] voidspace, it's inelegant to bounce up and down drunkenly before settling, true [12:05] fwereade: however in practise it *was a problem* (and is now less of a problem) [12:05] fwereade: you're probably correct that moving the proxyupdater was papering over some other problem [12:05] (why didn't charm download get retried) [12:05] voidspace, there are two cases though [12:06] however it did solve the immediate problem (which was specifically - demo in 3 days need a fix released) [12:06] fwereade: I think charm revision worker was set to only retry once a day [12:07] fwereade: and to *not* die on error [12:07] voidspace, (I am not trying to rag on what you've done, just trying to work out what I can do that is not going to break stuff) [12:07]