mupBug #1519128 opened: lxd provider fails to cleanup on failed bootstrap <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1519128>00:02
davechen1ythumper: mwhudson go 1.5.2 release status https://groups.google.com/d/msg/golang-dev/JcZNxZgRR04/yjDXSO_RAQAJ00:21
davechen1ythumper: why does fslock have an IsLocked method ?00:22
mwhudsondavechen1y: very very close then00:23
davechen1yi just saw the ppc32 rel cl land00:24
davechen1ylooks like austin has got another horrid gc bug00:24
davechen1ybut i don't think it'll hold up the release00:24
davechen1yi asked russ last week if there was value in doing a release candidate for the rc00:24
davechen1ybut he reminded me that they can always relase go 1.5.3, so there is no value in waiting to get 1.5.2 perfect00:25
mupBug #1519133 opened: cmd/jujud/agent: data race <juju-core:New> <https://launchpad.net/bugs/1519133>00:26
davechen1yFound 7 data race(s)00:26
davechen1ythumper: mgz, I should have a PR ready to disable the -race build on the remaining failing packages00:32
davechen1ywould it be pssible to kick off another race job as soon as I check that in, or should I wait for the overnight run ?00:33
mupBug # opened: 1519141, 1519144, 1519145, 151914700:56
mupBug #1519149 opened: worker/uniter/remotestate: data race <juju-core:New> <https://launchpad.net/bugs/1519149>00:59
davechen1yaxw: thumper menn0 https://github.com/juju/juju/pull/380601:02
axwdavechen1y: LGTM01:05
mupBug #1519149 changed: worker/uniter/remotestate: data race <juju-core:New> <https://launchpad.net/bugs/1519149>01:05
mupBug #1519149 opened: worker/uniter/remotestate: data race <juju-core:New> <https://launchpad.net/bugs/1519149>01:08
davechen1y^ eventual consistency eh mup ?01:11
mupBug #1519149 changed: worker/uniter/remotestate: data race <juju-core:New> <https://launchpad.net/bugs/1519149>01:17
mupBug #1519149 opened: worker/uniter/remotestate: data race <juju-core:New> <https://launchpad.net/bugs/1519149>01:26
thumperoh shit01:41
davechen1ywallyworld: is there any way to kick off http://reports.vapour.ws/releases/3346/job/run-unit-tests-race/attempt/59701:42
davechen1ythis job immediately ?01:42
wallyworlddavechen1y: not sure, i'll see if i can01:43
davechen1yi'd like to get started on restoring the tests i just commented out01:45
wallyworlddavechen1y: it needs a revision_build param, i'm not sure if that is a git sha or something else01:46
wallyworldi can look at previous logs01:46
wallyworldunless sinzui is still around?01:46
sinzuidavechen1y: to re-run that same attempt?01:47
davechen1ysinzui: no, a new attempt please, at 7652514bc7127bf9e1c283479b32733933708da701:49
sinzuidavechen1y: which branch is that. That will trigger a full round of tests01:50
sinzuidavechen1y: CI got clobbered again. YES I will make CI pickup master tip now01:51
sinzuiericsnow: I forced the ubuntu alias to point to the wily lxd image. We have a pass. I will update the bug with what I did to make lxd and Juju happy http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/lxd-deploy-wily-amd64/51/console01:52
davechen1ysinzui: yes, that's on master now01:54
sinzuidavechen1y: your job will start in about 7 minutes.01:55
axwI'm finished being mean to anastasiamac, your turn now01:55
axwwallyworld: ^^01:56
anastasiamacaxw: \o/01:56
wallyworldoh, alright01:56
anastasiamacaxw: ur patience is phenominal and greatly appreciated!!!01:56
davechen1ysinzui: tahnks02:00
anastasiamacaxw: wallyworld: m hitting "land-me-quickly",... all bruised and battered \o/02:02
wallyworldmaster is blocked02:02
wallyworldjust joking!! :-D02:03
anastasiamacwallyworld: it's k. m on feature branch :D02:03
anastasiamacwallyworld: which somehow feels even more painful \o/02:03
natefinchaxw: got a second?02:18
axwnatefinch: heya, what's up?02:18
natefinchaxw: I was looking at bug 1517344, but not sure what the actual repro steps are.02:18
mupBug #1517344: state: initially assigned units don't get storage attachments <bug-squad> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1517344>02:18
* thumper pulls a sadface02:19
thumperinvestigating one bug, and found at least four others02:19
axwnatefinch: you'll need a charm that requires storage. just deploy it, and the storage doesn't get added anymore. I'll push my testing charm to LP02:19
thumpersinzui: if you see the race job pass, please make it voting :)02:20
natefinchaxw: I saw the storage docs mention cs:~axwalk/postgresql ... is that still a valid test case?02:20
axwnatefinch: I think so, but I haven't tried using it in a while02:20
* natefinch tries02:20
sinzuithumper: that job cannot be voting for 1.25 though. That will be tricky02:20
thumpersinzui: no, just master02:21
thumpersinzui: and the upcoming 1.2602:21
sinzuithumper: yeah, we don't have branch level voting. it will be tricky02:21
axwnatefinch: otherwise there's cs:~axwalk/trusty/storagetest02:21
thumpersinzui: oh?02:21
natefinchaxw: cool, thanks02:21
* thumper is surprised02:21
axwnatefinch: just "juju deploy cs:~axwalk/trusty/storagetest" *should* give you a unit of that service with a single "filesystem" storage instance02:22
thumperhow do you go about adding ci tests for new branches that don't work on old branches?02:22
thumpersinzui: ^^02:22
axwnatefinch: I think if you deploy the service and then add the unit (separate step), the second unit will get storage02:22
sinzuithumper: the test exit early with pass, I can do that for 1.25 and older, but we also not run the test.02:23
davechen1ysinzui: can I watch the progress of the job ?02:23
sinzuidavechen1y: yes02:23
thumpersinzui: that is probably fine02:23
davechen1ysinzui: could you tell me the link please02:23
sinzuidavechen1y: http://juju-ci.vapour.ws:8080/job/run-unit-tests-race/599/console02:24
davechen1yahh, it's a jenkins job02:24
davechen1ythat's what I needed to know02:24
davechen1ynow I can solve my own question02:24
sinzuithumper: Yeah, I thiknk so. We weren't learning anything from the 1.25 runs02:24
davechen1yand an empty stack trace for good measure02:25
axwdavechen1y: you have to be logged in02:25
davechen1yhow do I log in ?02:25
davechen1yi've never logged in02:25
davechen1ycan the job be changed to public02:25
davechen1yi don't think itneeds to be private02:25
natefinchlol "WARNING: config not found or invalid"  wait... what?  Which is it?02:32
davechen1ynatefinch: try double negative02:35
davechen1yconfig not not found or not invalid == success!02:35
natefinchI just ... how do you not know if it doesn't exist?  Why does the code not differentiate?02:41
natefinchalso, juju thinks some of the random juju-* processes in my bin directory are juju plugins and tries to run them when I use tab complete and ends up panicking because that's not what they are02:43
axwwallyworld: left some comments on your PR02:44
wallyworldaxw: ty02:44
davechen1yok  github.com/juju/juju/api/uniter1532.421s02:44
davechen1yyay cloud02:44
axwdavechen1y: the CI job takes >60s for the joyent tests, takes ~2s on my desktop :/02:45
davechen1yyay cloud02:45
davechen1ythe raison d'etre of false economies02:46
natefinchif only we had some way to run a cloud on top of our own fast bare metal....02:48
natefinch(not that we don't need to run cloud specific tests, obv...)02:48
davechen1ynatefinch: you mean like a laptop02:50
davechen1ywith ubuntu installed on it ?02:50
natefinchdavechen1y: I know they're hard to find in this company, but maybe we could scrounge up a few02:51
natefinchthumper: whelp.  One more thing to add to my airing of grievances against YAML this year.03:00
davechen1yYAML, the configuration format so flexible, no matter what the issue -- it's your fault.03:05
thumperdavechen1y: https://bugs.launchpad.net/juju-core/+bug/151763203:07
mupBug #1517632: juju upgrade-juju after upload-tools fails <juju-core:Triaged> <https://launchpad.net/bugs/1517632>03:07
thumperdavechen1y: hangout to chat about it?03:07
davechen1ythumper: i'll me you in the 1:103:07
wallyworldaxw: replied. since there's doubt, i can ask for clarification from rick etc03:09
natefinchmy favorite is still base 60 notation... so a value of 8080:22 is interpreted as 484822.0  but a value of 8080:61 is interpreted as a string "8080:61"03:09
axwwallyworld: yes, please03:14
mupBug #1519176 opened: apiserver/provisioner: tests unreliable under -race <juju-core:New> <https://launchpad.net/bugs/1519176>03:15
mupBug #1519176 changed: apiserver/provisioner: tests unreliable under -race <juju-core:New> <https://launchpad.net/bugs/1519176>03:18
mupBug #1519176 opened: apiserver/provisioner: tests unreliable under -race <juju-core:New> <https://launchpad.net/bugs/1519176>03:21
mupBug #1519176 changed: apiserver/provisioner: tests unreliable under -race <juju-core:New> <https://launchpad.net/bugs/1519176>03:27
mupBug #1519176 opened: apiserver/provisioner: tests unreliable under -race <juju-core:New> <https://launchpad.net/bugs/1519176>03:30
wallyworldaxw: i was wrong in my reply - deploy --series wily will cause subsequent add unit commands to use wily03:43
axwwallyworld: with your branch?03:43
axwwallyworld: or that's the expected outcome?03:43
wallyworldaxw: with my branch and master03:43
wallyworldthat's te current behavour03:43
wallyworldbut we still need --force to get such a unit on a non wily machine each time03:44
wallyworldthat's what i was trying to say03:44
wallyworldbut got confused03:44
axwwallyworld: ok, so can you just record the Force flag on the service then?03:44
wallyworldthat's what  i don't want to do03:44
wallyworldjuju add-unit will still used wily without --force03:44
wallyworldbut it will use a new wily machine03:45
mupBug #1519183 opened: featuretests: tests fail under -race because of crappy timing issues <juju-core:New> <https://launchpad.net/bugs/1519183>03:45
wallyworld--force is needed if we want to use a non wily clean/empty machne03:45
axwwallyworld: non capisco03:45
wallyworldquick hangout?03:45
wallyworldaxw: am in standup hangout fwiw03:46
mupBug #1519189 opened: worker/leadership: FAIL: TrackerSuite.TestGainLeadership <juju-core:New> <https://launchpad.net/bugs/1519189>04:03
cherylj davechen1y I see you've inherited bug 1517632.  Congrats :)04:08
mupBug #1517632: juju upgrade-juju after upload-tools fails <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1517632>04:08
cheryljdavechen1y: could you put in an update before you EOD?04:08
cheryljdavechen1y: I'll need to follow up with bootstack in the morning04:08
davechen1ycherylj: i'm working on something else today04:11
davechen1yi have no update04:11
davechen1yfeel free to unasign me04:11
davechen1y(thumper only gave me the bug 20 minutes ago)04:11
mupBug #20: Sort translatable packages by popcon popularity and nearness to completion <feature> <lp-translations> <Launchpad itself:Invalid> <https://launchpad.net/bugs/20>04:11
cheryljha, funny mup04:11
thumpercherylj: short answer is nothing on this one so far04:11
mupBug #1519189 changed: worker/leadership: FAIL: TrackerSuite.TestGainLeadership <juju-core:New> <https://launchpad.net/bugs/1519189>04:12
cheryljwallyworld: did you say you had an environment where you can reproduce bug 1517632?04:12
mupBug #1517632: juju upgrade-juju after upload-tools fails <juju-core:Triaged> <https://launchpad.net/bugs/1517632>04:12
wallyworldcherylj: one sec04:13
mupBug #1519189 opened: worker/leadership: FAIL: TrackerSuite.TestGainLeadership <juju-core:New> <https://launchpad.net/bugs/1519189>04:15
mupBug #1519190 opened: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:New> <https://launchpad.net/bugs/1519190>04:15
mupBug #1519191 opened: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:New> <https://launchpad.net/bugs/1519191>04:15
wallyworldcherylj: i think i saw it once on a stock 1.25 deployment i ran to specifically test the issue but thay env is long gone04:16
wallyworldbut in general, i was not able to repro again after that04:17
wallyworldbut i am pretty sure wayne said he could repro on 1.2504:17
cheryljwallyworld: okay, thanks.04:18
wallyworldsorry :-(04:18
wallyworldmaybe 1.25 is ok after all04:19
wallyworldand it nly affects 1.2204:19
axwwallyworld: forgot to ask: any issues with adding URL to RemoteService?04:25
axwwallyworld: then it'll be possible to have a different service name locally than what's in the service directory04:26
wallyworldaxw: i don't think so offhand. i havn't got that branch open but i would have thought wed be recording ServiceURL in the remote service data model. we are not?04:27
axwwallyworld: nope, just name, endpoints, life, relation-count04:27
wallyworldaxw: hmmm, i'm sure i meant to add it. sigh04:28
axwwallyworld: I'll add it in my branch04:28
cheryljwallyworld: in another upgrade bug....  Have you ever seen this message"  "upgrader.go:185 desired version is 1.24.7, but current version is 1.23.3 and agent is not a manager node"04:32
wallyworldcherylj: wow, no :-(04:32
cheryljI think the state server doesn't think it's the state server04:32
wallyworldyeah, that's really sucky04:32
cheryljthink there's any chance of recovery around that?04:33
mupBug #1498968 changed: ERROR environment destruction failed: destroying storage: listing volumes: An internal error has occurred (InternalError) <destroy-environment> <juju-core:Expired> <https://launchpad.net/bugs/1498968>04:33
wallyworldcherylj: looks like something hasn't replicated04:33
wallyworldcherylj: we'd need to see juju status to see what version each agent is04:33
wallyworldto et an idea of where to start04:34
cheryljI don't think any have upgraded.04:34
wallyworldcherylj: ah right ok. hmmm, do retrying the upgrade work?04:36
cheryljwallyworld: no :(04:37
wallyworldwe'd need logs etc then sadly :-(04:37
wallyworldand juju status04:37
cheryljI have machine-0 log.  Should I also ask for syslog?04:37
wallyworldwould be good to see allmacines.log04:38
wallyworldor at least logs from all the HA state servers04:38
wallyworldand syslog for mongo won't hurt04:38
cheryljhere's the worrisome part, though.  They went from 1.20 -> 1.23.3->1.24.7.  And I know 1.23 had issues.04:38
wallyworldand possibly --debug from client04:38
cheryljwondering if that had something to do with it04:38
wallyworldif they got off 1.23 that's a good sign04:38
cheryljthey didn't.  It's the step to 1.24.7 that hit this problem04:39
wallyworld1.23 tended to hang and not be able to be upgraded04:39
mupBug #1498968 opened: ERROR environment destruction failed: destroying storage: listing volumes: An internal error has occurred (InternalError) <destroy-environment> <juju-core:Expired> <https://launchpad.net/bugs/1498968>04:39
wallyworldcherylj: the symptom i was aware of was that agents got dealocked, but this seems different04:39
thumperif you use juju ssh to log into an lxd machine, then go 'less /var/log/juju/machine-3.log' you might not get things in the right order04:40
thumperNFI why04:40
thumperbut if you copy the file to the host, then look, the file is all good04:40
cheryljwallyworld: yeah...04:40
wallyworldcherylj: it may well be a related problem and the scripts meno did may help, but because that error message i have not seen before, can't be sure04:41
wallyworldhence logs etc04:41
cheryljokay, thanks wallyworld04:41
wallyworldthumper: lxd hates you. they put in that easter egg just for you and now you'v found it. well done04:41
* thumper goes to look for wine04:42
mupBug #1498968 changed: ERROR environment destruction failed: destroying storage: listing volumes: An internal error has occurred (InternalError) <destroy-environment> <juju-core:Expired> <https://launchpad.net/bugs/1498968>04:45
davechen1ysinzui: can you kick the job off again with 8b4e8b7d037c52c9a0df00d8227366033eea04d904:46
davechen1yi tried to do it myself but http://juju-ci.vapour.ws:8080/job/run-unit-tests-race/600/console04:46
sinzuidavechen1y: CI is still testing the last revision. Ci Will automaticlly start the next master or 1.25 revision04:47
davechen1yok, thanks04:48
sinzuidavechen1y: I think the next round of testing will be in 15 minutes. master tip will be selected04:49
davechen1ysinzui: thanks, I think I have now excluded all the troublesome packages04:55
sinzuidavechen1y: you rock04:56
sinzuidavechen1y: I am off to sleep: Your job is running. http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-race/601/console05:17
axwwallyworld: I thought you were going to undo all the state changes? aren't they all unnecessary for this branch, since the series is just encoded in the charm URL?05:23
axwwallyworld: i.e. the only place we check series is when resolving the URL05:24
wallyworldaxw: i left in the ones needed for unit placement05:24
wallyworldsorry, but i did remove the clean policy ones05:24
natefinchaxw: ahh, I see the problem with storage at service creation time.  Service.unitStorageOps  tries to read the database to get the service constraints, but obviously they haven't been written yet.05:32
axwnatefinch: yep, that'll be part of it. assignToNewMachine isn't even calling that though?05:35
natefinchaxw: it's during unit creation that I see the difference, not assignment05:36
axwnatefinch: ok. so the unit's not getting storage associated, and then of course when you go to assign it's got no storage so doesn't create attachments.. makes sense05:37
natefincheasy enough to do what I did with the rest of the stuff, which is factor out how the constraints are discovered and just pass them in05:38
natefinchyay, unused variable compiler error saves me again05:41
natefinchand fixed.05:43
axwnatefinch: excellent, thank you05:44
axwwallyworld: you're going to be adding support for add-unit --series right?05:44
axwwallyworld: or is it just add-unit --to --force05:45
wallyworldaxw: not in very next branch. am wondering if i should just hold off on that05:45
wallyworldthinking about just "juju add-unit --to 1 --force"05:45
wallyworldbut --to implies force i guess05:45
wallyworldas we discussed05:45
axwwallyworld: right, so I'm wondering if propagating Force is required at all05:45
axwwallyworld: if you specify --series, you'll need to record that on the unit doc05:46
natefinchhmm... I'd prefer a force there.. to keep me from screwing myself if I typo or just forget that a machine is the wrong series05:46
wallyworldi am still vascilating on whether we want --force05:46
natefinchor just an "are  you sure?" or something05:46
axwnatefinch: --to already overrides everything else05:46
axwas in, your constraints may be ignored if you use --to (e.g. in MAAS if you specify --to <node>)05:47
natefinchyeah, but almost everything else is a nice to have for performance etc. ... series is like "this stuff may totally not function"05:47
wallyworldaxw: actually, i forgot to mention - --to does not override series mismatch05:47
wallyworldsee assignToMachineOps05:48
wallyworldso i think that's what convices me we want --force05:48
axwwallyworld: right, so the question is do we change --to from meaning "do what I say" to "do what I say (except if it's series, in which case I have to force you to do what I say)"05:48
wallyworldso changing semantics for a non 2.0 release would not be good05:49
wallyworldi think being conservative here is good and then we get feedback from feature buddies05:49
wallyworldthat's IMHO05:50
wallyworldi can see both sides05:50
natefinchhopefully it'll generally be a non-issue as charms become more multi-series compatible05:50
axwyou're changing semantics one way or the other05:50
wallyworldwe aren't changing default --to behaviour05:50
wallyworldjust adding a new option05:50
axwwallyworld: no, but you are changing what --to means05:51
natefinchaxw: --to can't override a charm's series now05:51
axwdue to an existing limitation, yes05:51
wallyworldi'm not sure we are changing what --to means. --to means "do not choose a machine for me or create one, use this one"05:51
axwright. but why do I have to --force for series and not anything else?05:52
wallyworldpartly because that's the current semantics, and also --to now overrides placement, not compatability per se05:52
axwseems a bit arbitrary. I may have a charm that requires 64GiB RAM, but I've said to deploy to punydevice and it'll happily do that05:52
wallyworldoverriding series is more of a compatability issue potentially05:53
wallyworldi can se the point about memory05:53
natefinchyou can't use --to to put cs:trusty/mysql on a vivid machine in 1.25, can you?05:53
natefinchthen having it also fail with series in metadata seems completely consistent05:54
natefinchadding a flag that changes the behavior is certainly not breaking backwards compatibility of the CLI05:54
wallyworldthat's my argument also05:54
wallyworldbut i can also see the other side05:54
wallyworldbut for me, the backwards compatability argument wins05:55
natefinch--to may be inconsistent with respect to constraints, but that's the way it has been.  I don't think changing it at this point is a good idea.05:55
axwbackwards compatibility matters when you're changing something that was possible that something that is not possible. we're doing the opposite.05:56
natefinchanyway, past bedtime for me05:56
* axw continues review anyway05:56
axwnatefinch: good night05:56
axwwallyworld: what I'm getting at is: why would anyone care if they previously couldn't go "--to <machine-with-different-series>" and now they can?05:57
wallyworldpeople may have script that check errors etc05:57
wallyworldor expect errors05:58
axwwallyworld: I cannot fathom why anyone would script that, except in CI to test for failures05:58
wallyworldme either, but then again as we see every day, customers do weird shit with juju05:59
axwwallyworld: https://xkcd.com/1172/05:59
wallyworldvery relevant06:00
wallyworldok, i'll change it06:00
axwI call that argument "appeal to XKCD"06:01
wallyworldnot sure i fully agree, but we can iterate06:01
wallyworldi can honestly see both sides06:01
axwwallyworld: yes, this is my opinion of course. I think you should at least bring it up with fwereade06:02
axwmy not-very-humble opinion06:02
wallyworldafter i land the branch so that it will be too late06:02
axwheh :)  up to you06:02
wallyworldit was 2v1, maybe he will make it 2v206:03
axwwallyworld: oh shit. looks like azure-sdk-for-go is using a too-new version of x/crypto :/06:12
axwwallyworld: can't build on 1.2. are we updating soon?06:12
wallyworldaxw: so, this test TestDeployBundleInvalidSeries now fails with --to now not complaining about series mismatch. I think it's valid to accept the bundle case as highlighted in the test as something that should now work07:28
=== urulama__ is now known as urulama
davechen1ymgz: the -race build finally passed !!07:40
fwereadedooferlad, do you have a moment to look at http://paste.ubuntu.com/13479943/ please?08:48
dooferladfwereade: on it09:08
axwwallyworld: sorry, I missed your message. I think so, yes09:09
wallyworldaxw: np, i've pushed changes09:09
dooferladfwereade: please review: http://reviews.vapour.ws/r/3221/09:24
dimiternjam, fwereade, voidspace, standup?10:02
voidspacedimitern: omw10:04
voidspacedimitern: gah, 2fa dance10:05
voidspacedooferlad: http://pastebin.ubuntu.com/13491666/10:20
voidspacedooferlad: fails with http://pastebin.ubuntu.com/13491674/10:21
voidspacedooferlad: from that output the space name seems to be being serialised as "string" not "space"10:40
voidspacenext issue, unreserved ranges is a map not an array10:41
voidspacejust testing with real maas to see if that's my bug - probably is :-)10:41
dooferladvoidspace: looking10:43
voidspacedooferlad: hmmm... unreserved-ip-ranges should return an array10:48
voidspacedooferlad: looks like it's returning a map10:48
voidspacedooferlad: I haven't looked at the tests for unreserved ranges, just observing the error in my code (requested array got map)10:49
voidspacedooferlad: although your test is deserialising into an array10:50
voidspacedooferlad: I'll look again, it's possible there's a bug that only sends a map when the array is empty (I didn't populate the ranges first - haven't got that far in my test)10:51
dooferladvoidspace: OK10:51
voidspacehmmm... my code looks good10:53
voidspaceunless it should be "unreserved_ip_ranges"10:54
voidspacechecking the maas docs :-)10:54
voidspaceproblem is that maas ignores unrecognised ops10:54
dooferladvoidspace: I went with underscore10:54
dooferladvoidspace: which I think is what the doc has10:54
voidspacedooferlad: underscores are correct, the maas command line translates them10:54
voidspacedooferlad: however I missed an _ip off the middle of the op10:55
voidspaceso I'm calling the wrong op10:55
voidspacewhich is why I'm getting the wrong response10:55
voidspaceso another bug that testing has discovered...10:55
voidspacethe space name issue is still a real issue though as far as I can see10:55
voidspacedooferlad: dammit, I need "reserved_ip_ranges" not unreserved10:59
voidspacesorry :-/10:59
voidspacethat was a bug in my code too10:59
dooferladvoidspace: I did both11:00
voidspaceah, I get an EOF reading reserved_ip_ranges11:00
voidspaceI'll look into that11:00
voidspacedooferlad: when I call reserved_ip_ranges I'm looking for the range with "purpose" set to ["dynamic-range"]11:04
voidspacedooferlad: can I set that with the test server?11:04
dooferladIt would be easy enough to do11:06
voidspaceI can see the Purpose field on AddressRange exists11:08
voidspacedooferlad: note that the address range responses for reserved_ip_ranges and unreserved_ip_ranges are different11:08
voidspaceso *technically* having a Purpose field for the unreserved response is incorrect11:09
voidspacehowever I don't think anyone will actually care11:09
dooferladvoidspace: as long as your code doesn't care :-)11:09
voidspaceit doesn't :-)11:09
voidspaceI'm not currently using reserved ranges11:09
voidspacemaybe the code that does address allocation should use it11:09
voidspacebut even then it wouldn't care about an extra Purpose field11:10
voidspacegrabbing coffee11:10
dooferladvoidspace: also grabbing coffee11:13
wallyworldfwereade: hey, with series in metadata work, we now support "juju deploy mysql --series vivid --force" to allow a non-vivid charm to be deployed on a vivid machine. we'd like to also make --to for unit placement able to override series just as it overrides other machine constraints, ie "juju add-unit mysql --to 1" would deploy mysql on a vivid machine 1 even if mysql does not support vivid. Note that there was no use of --force in11:17
wallyworldthat add-unit command. The proposal is to make --to put a unit on a nominated machine and treat series as being overidden just the same as mem etc11:17
wallyworldthe counter option is "juju add-unit mysql --to 1 --force"11:17
wallyworldbut that gives series a special meaning for --to11:17
fwereadewallyworld, I must say I don't really understand the use case: when is someone expert enough to do that but can't add the series to the charm anyway?11:18
wallyworldnot for a charm store charm no11:18
wallyworldeg charm store charm supports precise, trusty11:19
fwereadewallyworld, and it opens that bag of rattlesnakes re subordinates etc11:19
wallyworldwell sort of, but when deploying a subordinate, a series check would be done11:19
wallyworldunless --to were specified11:20
fwereadewallyworld, you can't place subordinnates11:20
wallyworldthe semantics would be the same11:20
fwereadewallyworld, and it ends up meaning that the existence of a subordinate relation tells you nothing about whether or not subordinnates will exist11:20
wallyworldso there we'd use --force11:20
fwereadewallyworld, add-relation --force?11:21
fwereadewallyworld, don't think that works11:21
wallyworldthat's orthogonal the current issue though11:21
fwereadewallyworld, we just need to accept that if you allow series-breaking deploys we also cause arbitrary series-breaking deploys of any subordinnates11:21
fwereadewallyworld, it's not -- we're breaking a fundamental assumption on which all manner of things rest11:22
wallyworldonly to date with one charm  one series11:22
wallyworldthat model is on the way out11:22
fwereadewallyworld, I think "we will deploy stuff that works" is a kinda important principle11:23
fwereadewallyworld, the choice is simple11:23
wallyworldso this is paving the way to deal with that but also allow users control11:23
wallyworldwe have a clear directive to allow this to happen11:23
fwereadewallyworld, if we allow deliberate I-know-better breakage of one service, we inevitably open the dorr to surprising breakage of subordinates11:24
fwereadewallyworld, and that's fine, it's a choice we can make11:24
fwereadewallyworld, but I see no awareness that we're adding a whole new class of inscrutable failure mode to juju or what we're going to do about it11:24
wallyworldwell, that's moot - we've been told to do it11:25
fwereadewallyworld, ok, so part of that is *addressing the issues that it raises*11:25
wallyworldthere's not much we can do if a user deploys a precise charm to vivid and it breaks11:25
fwereadewallyworld, right11:25
fwereadewallyworld, that's fine11:25
fwereadewallyworld, the user said "do X, I know what I'm doing"11:25
wallyworldright, hence --to11:25
wallyworldwhich breaks mem and other constraints already11:26
fwereadewallyworld, no11:26
fwereadewallyworld, placement overrides constraints11:26
fwereadewallyworld, no complexity, no breakage, clear interaction model11:26
wallyworldit breaks things11:26
wallyworldif a charm needs 64M and you place it on a 2M machine, boom11:26
fwereadewallyworld, look, when you say "I want service X running on this series" that also, secretly and dynamically implies "I also want a bunch of other services forced onto this series too"11:28
fwereadewallyworld, (also... deploy-time and --to are *very* different...)11:28
fwereadewallyworld, deploy-time keeps us to one-service-one-series11:28
wallyworlddeploy supports --to i think11:28
fwereadewallyworld, you're right there, but that can work just fine11:29
wallyworldit breaks the same way though11:29
fwereadewallyworld, --to, when handled by juju rather than a provider, implies force-series-of-target-machine11:30
fwereadewallyworld, do we have a mandate to allow multi-series *services*? because I am pretty sure we agreed to descope that precisely because of these concerns11:30
wallyworldin the same way it forces a charm into an environment that might not suit it memeory wise11:30
wallyworldservices are single series11:31
wallyworldonce the service doc series attribute is set, that defines the series of the units11:31
fwereadewallyworld, ok, so add-unit --to will barf on series mismatch?11:32
wallyworldbut we still need to allow those units to be placed on any machine11:32
wallyworldit will now11:32
wallyworldbut not by the end of this11:32
wallyworldit will barf on OS mismatch11:32
fwereadewallyworld, if you allow add-unit --to, you just implemented multi-series services11:32
wallyworldin a way11:33
fwereadewallyworld, which is a monster of complexity and unintended consequences11:33
wallyworldas is a number other things in juju11:33
wallyworldwhich we have had to do11:33
fwereadewallyworld, we agreed *not* to do multi-series services11:34
fwereadewallyworld, at least in phase one11:34
wallyworldok, i'll tell people with pitch forks to come and see yu :-)11:34
fwereadewallyworld, multi-series services will be necessary and will be awesome11:35
fwereadewallyworld, but if we shoehorn them in like this we do nobody any favours11:35
wallyworldpeople want to override juju's behaviour11:35
wallyworldas with image id etc11:36
wallyworldwe are fighting a losing battle11:36
fwereadewallyworld, all I am trying to do is to develop a product that has a chance of fucking *working*11:36
wallyworldbut we'll hold off and see what pusback we get11:36
fwereadewallyworld, magical thinking is not actually a substitute for engineering11:37
wallyworldit works fine even with upload-tools, etc11:37
wallyworldwhich we said was evil11:37
wallyworldat some point, we have to cater for what users want even if it is not perfect11:37
fwereadewallyworld, upload-tools? you mean the feature that means we never know what version a client is running in the field? yeah that's fucking awesome11:38
fwereadewallyworld, yes11:38
fwereadewallyworld, I know11:38
wallyworldsarcasm aside, upload tools solves user problems11:38
fwereadewallyworld, I am advocating for us *thinking through consequences*11:38
wallyworldi don't like it either11:38
fwereadewallyworld, right11:39
fwereadewallyworld, it is a shitty half-assed solution11:39
wallyworldwe can solve consequences through iteration11:39
fwereadewallyworld, are you fucking kidding me11:39
fwereadewallyworld, we cannot just break the model and hope it'll magically work itself out11:39
wallyworldthat's not what  i said11:40
fwereadewallyworld, look, we talked about all this inn the spec11:40
wallyworldand yet users still ask for it11:40
fwereadewallyworld, so the spec changed to include multi-series services?11:40
fwereadewallyworld, and we didn't reestimate?11:40
fwereadewallyworld, or take the time to answer the hard questions that caused us to defer the multi-series service bit?11:41
wallyworldthe spec was updated yes, but full details of consequences not there becauses it's a requirements spec11:42
wallyworldi can strikeout some items for now and see what push back we get11:43
fwereadewallyworld, my understanding was that we'd drawn a line before multi-series services because the effort to do them right was *so much* higher11:44
wallyworldyeah, we try to11:46
fwereadewallyworld, I hope it's clear that I'm not even against it -- I just do not believe we will do anything but a shitty job of it if it slips in under the radar like this11:46
wallyworldsure, understood11:47
wallyworldfwereade: i think a lot of it comes down to - are we prepared to allow users to force subordinates onto a machine that the principal may also have been forced onto11:51
wallyworldor, we could continue to disallow that11:51
fwereadewallyworld, I *think* that doesn't quite come up?11:52
fwereadewallyworld, so long as each service has 1 series, you can only create subordinate relations between services with matching series11:52
fwereadewallyworld, and so, yes, we will want to be able to force subordinate series too11:53
fwereadewallyworld, but I think it keeps the door to the really surprising behaviour shut11:53
wallyworldis there really much difference between forcing a precise mysql charm onto a wily machine, and also forcing a rsyslog subordinate onto that wily machine?11:55
voidspacedooferlad: any idea on why "space" appears to be serialised as "string" in the test server?11:57
dooferladvoidspace: not yet11:57
dooferladvoidspace: hunting other bugs11:57
voidspacedooferlad: I can't currently deserialise a subnet - and *all* of my code needs to deserialise subnets11:58
voidspacedooferlad: so I can't currently test any of it :-/11:58
dooferladvoidspace: yea, will get to it ASAP11:58
voidspaceit *may* still be my fault, but I can't see why11:58
voidspacedooferlad: cool, thanks11:58
fwereadewallyworld, the difference is entirely in whether it's been explicitly requested11:59
voidspaceI'm continuing to write tests, but can't actually run them :-)11:59
voidspaceI also need to be able to set the dynamic range to test that code - but I only really need that for a single test11:59
fwereadewallyworld, running a charm in an unexpected environment is reasonable when the user has said they know better11:59
wallyworldfwereade: right, so add-relation could do that check, but it would need though on how to make it nice to use12:00
voidspacedooferlad: an NewSubnetWithDynamicRange or similar would be fine12:00
fwereadewallyworld, it's when that leaks into other services -- and especially we don't have a clear model for all the edge cases -- that we have a problem12:00
fwereadewallyworld, add-relation already does that check12:00
voidspacedooferlad: not necessarily any need for a general purpose mechanism for specifying the purpose of ranges12:00
fwereadewallyworld, I wholeheartedly agree that it would be awesome to do clever things that Just Work, but I would rather restrict the domain to simple things that Just Work and figure out how to grow from there12:02
wallyworldright, which is sort of what we were doing12:02
fwereadewallyworld, it is, so long as we don't introduce multi-series services12:02
fwereadewallyworld, and I think we really do get plenty of user value out of phase 112:03
wallyworldit is simple to deploy the initial multi-series units12:03
wallyworldthat Just Works, and the growing bit is how to allow explcit override for incompatible suborinates :-)12:04
wallyworldbut we'll skip that for now then12:04
fwereadewallyworld, strongly disagree -- it puts us into broken states and forces us to figure out how to get out of them12:04
wallyworldwhat's broekn? it's no more broken that deploying a trusty charm to a vivid machine in the first place12:05
fwereadewallyworld, AIUI the use case is "deploy a charm to a series not explicitly supported" not "deploy cross-series services"12:05
wallyworldbut the latter boils down to the former12:05
fwereadewallyworld, if I say "deploy trusty-X on vivid", I am explicitly telling juju to do something strange/new12:06
wallyworldsure, and if i say replace this trusty subordinate to this vivid mysql, same thing12:06
fwereadewallyworld, if it then turns out that it *also* meant "oh, and an arbitrary set of other services might have some of their units deployed on mixed series"12:06
fwereadewallyworld, that feels like a pretty harsh violation of least surprise12:07
dooferladvoidspace: space name issue fixed12:07
wallyworldbut it's the same basic premise - deploying charms onto machines with mismatched series if the user says it;s ok12:07
dooferladvoidspace: I also changed the JSON output to be pretty printed so debugging is easier12:07
wallyworldthere's no surprise, the user has ok'ed everything12:07
fwereadewallyworld, how so?12:08
wallyworldby telling juju it's ok to relate this subordinate to this principal even though the series don't match12:08
wallyworldmaybe this point is moot - all the charms will be migrated to multi-series :-)12:09
fwereadewallyworld, but that's just another implicit inroad into multi-series services -- yeah, exactly12:09
wallyworldbut as a user it would suck if i had a trusty rsyslog that i couldn't use12:10
fwereadewallyworld, it will suck exactly as much as it does today -- they can deploy another rsyslog to vivid and relate that one12:10
fwereadewallyworld, not great? sure12:10
fwereadewallyworld, but it's what you have to do already12:10
fwereadewallyworld, and it's not the problem we're trying to solve with force-series-deploy12:11
fwereadewallyworld, it's related, it's probably the *next* problem to solve12:11
wallyworldfwereade: well today you can't deploy the rsyslog to vivid - well you can, but the series is still trusty12:12
wallyworldso you are screwed12:12
fwereadewallyworld, but largely because it's a special case of "multi-series *services* are the logical next step from multi-series charms"12:12
fwereadewallyworld, huh? if you force rsyslog to vivid *surely* the service has series vivid?12:12
wallyworldmaybe, i'd need to check12:13
fwereadewallyworld, if we're checking charm series not service series then, ok, we need to update the model12:13
fwereadewallyworld, but that's not a major change afaics12:13
wallyworldfwereade: so if you have a trusty rsyslog, off hand, i don't think you can force it to vivid. if you try and deploy using --to, it ha to be to a trusty machine12:15
fwereadewallyworld, ok, now I'm super confused12:16
wallyworldyou can now with series in metadat awork12:16
fwereadewallyworld, I thought this work was, literally, you can now do that12:16
fwereadewallyworld, ok cool12:16
wallyworldbut not in 1.25 unless i am misremebering12:16
fwereadewallyworld, no we agree there12:16
wallyworldso in 1.25 you are screwed12:16
wallyworldand as a user that sucks12:17
wallyworldi want to tell juju to do my bidding12:17
wallyworldand not have juju say "no"12:17
fwereadewallyworld, no argument there... but I thought we were talking about the series in metadata work12:17
wallyworldright, but if i want multiseries services, then juju should do that12:17
wallyworldeven if i need to --force or --to12:17
fwereadewallyworld, in which case surely you can deploy whatever charm with whatever forced series you like, and get a service with the forced series that happens to use a charm for a different series12:18
fwereadewallyworld, I agree it should, yes12:18
fwereadewallyworld, but it should not do so by exploding the space of surprising deployment possibilities and hoping they aren't too painful12:18
fwereadewallyworld, especially not when we scoped it to solve a problem and ISTM that it is fulfilling that with deploy-time only12:19
wallyworldnot surprising if i ask juju to do it :-) but we've already been over that12:19
fwereadewallyworld, if we're missing anything, how about upgrade-charm?12:19
wallyworldon the list to look at12:19
fwereadewallyworld, in what world is that done *after* multi-series services though?12:20
fwereadewallyworld, that's necessary for a consistent implementation of deploy-force12:20
wallyworldin a world where you diliver stuff incrementally12:20
wallyworldinto a product notyet released12:20
wallyworldbut which will be usable by the time of release12:21
wallyworldbut along the way will have rough edges while stuff is developed12:21
fwereadewallyworld, missing upgrade-charm is absolutely one of those rough edges12:21
wallyworldyes it is12:21
wallyworldwhich is why it will be done before release12:21
fwereadewallyworld,  but having done deploy-series, fixing those rough edges surely comes before making a massive and unconsidered change to the model12:22
wallyworldsigh, it's not unconsidered12:22
fwereadewallyworld, which will create more rough edges than you can fix in a dedicated cycle12:22
fwereadewallyworld, you still don't seem to understand that if you tell juju put put service X on series Y, you will be surprised if service Z also ends up there12:23
fwereadewallyworld, "do what I say"? fine12:23
wallyworldi won't be surprised because service Z will not go there with an incompatible series unless i say so12:23
fwereadewallyworld, how will you tell it?12:24
wallyworldvia --force or similar to be decided syntax12:24
frobwaredimitern, dooferlad, voidspace: if we want to rebase our branch I'll need to push with fast-forward; we'll all need to agree when we should do that as it would be best if you have nothing locally in-flight.12:24
fwereadewallyworld, ...that doesn't sound "considered" to me12:25
dimiternfrobware, why should it matter if there's ongoing work?12:25
fwereadewallyworld, afaics your choices are to magically deploy to surprising series, or to *not* deploy to surprising series12:25
wallyworldthe general principal is, UX needs thought12:25
frobwaredimitern, because you wont' be able to pull into your local maas-spaces branch12:25
dimiternfrobware, provided each of us also rebases the in-progress work on top of the rebased maas-spaces12:25
frobwaredimitern, ok that should work too.12:26
wallyworldit's not magic12:26
wallyworldthe user needs to ok it12:26
wallyworldbut it's moot now a12:26
frobwaredimitern, I was trying to avoid the principal of least surprise12:26
fwereadewallyworld, so, when I add-relation foo bar, and foo and bar are both trusty, but foo/2 is on vivid, what do we do?12:27
fwereadewallyworld, and when I add another vivid unit of foo, what do we do then?12:28
wallyworlddepends on the charm and what it supports12:28
wallyworldif foo charm supports vivid, no problem12:28
fwereadewallyworld, but I thought you said we'd have to force it?12:28
frobwaredimitern, dooferlad, voidspace: OK to rebase our branch?12:28
wallyworldonly if the charm doesn;'t support the series12:28
wallyworldif it is a multiseries charm supporting trusty and vivid then yay12:29
dimiternfrobware, +1 from me12:30
fwereadewallyworld, then yay, except upgrades get tangly12:31
wallyworldwe just check that all the series onto which the charm is deployed are also supported by the new charm12:32
wallyworldwe can then make a call12:32
fwereadewallyworld, again, multi-series charms *will* be great, but the model does not currently accommodate them, and we do actually have to model them12:32
wallyworldwe can allow the upgrade but then prevent new units added to any unupported series12:33
fwereadewallyworld, race: I add a unit of precise just as you upgrade the service to a charm that doesn't support precise12:33
fwereadewallyworld, to do that right we need a bunch of synchronisation in state that doesn't currently exist12:33
fwereadewallyworld, again, it will be good12:33
fwereadewallyworld, but it's massive scope creep for phase 112:33
wallyworldi agree upgrades are messy and we are getting near the end12:35
fwereadewallyworld, yeah -- I think we can solve a problem, get a win, draw a line under it, examine the next problem with more clarity12:35
frobwaredimitern, if you're going to rebase your current branch then I'll communicate the commit ID I rebased to12:36
dimiternfrobware, ok, sounds good12:37
frobwarevoidspace, just want to confirm you're also OK if I rebase maas-spaces with master12:56
frobwaredooferlad, ans same for you too ^^13:06
voidspacefrobware: is that bug fixed?13:12
voidspacefrobware: the failing tests on master bug?13:12
voidspacefrobware: if not I'll have failing tests on maas-spaces13:12
voidspacefrobware: not the end of the world but we'll need to rebase again as soon as fixes land13:13
frobwarevoidspace, which bug? on my desktop (trusty)  the unit tests on master and the rebased maas-spaces branch are OK13:27
dimiternfrobware, voidspace, all seems green on master; I vote to do the rebase ;)13:35
frobwaredimitern, voidspace: pushing rebase13:45
dimiternfrobware, cheers, will have a look in a bit how it went13:47
frobwaredimitern, voidspace, dooferlad: diff against master reveals: http://pastebin.ubuntu.com/13492574/13:48
dimiternfrobware, that sounds correct - these should be the 13 commits that are ahead13:51
frobwaredimitern, voidspace, dooferlad: rebase comit was 8b4e8b7d037c52c9a0df00d8227366033eea04d913:53
dimiternfrobware, thanks, I'll rebase mine soon13:59
fwereadedon't suppose anyone's familiar with menn0's StatePool stuff?15:03
fwereadenatefinch, sent a few notes on the juju-min-version PR15:04
natefinchfwereade: awesome, thanks15:07
voidspacedimitern: frobware: this bug: https://bugs.launchpad.net/juju-core/+bug/151774815:09
mupBug #1517748: provider/lxd: test suite panics if lxd not installed <juju-core:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1517748>15:09
voidspacethe one that causes tests on master to fail for me15:09
voidspacethat we discussed yesterday :-)15:09
frobwarevoidspace, I just saw that master is blessed with the same revision that I rebased too15:09
voidspacefrobware: nonetheless I have failing tests on master on my machine15:10
frobwarevoidspace, does comment #3 make any difference for you?15:11
voidspacefrobware: read comment #4!15:11
voidspacefrobware: (but no)15:11
voidspaceI just responded15:11
voidspaceI'll look at the example config he suggests in a bit15:11
frobwarevoidspace, gee! I'ms so out touch - there's a comment #4 now...15:11
voidspacebut my user is in the lxd group15:12
voidspacefrobware: :-)15:12
voidspacefrobware: sounds like you've done the rebase anyway15:12
voidspaceah well...15:12
voidspaceI won't update the branch I'm working on until I'm ready for it to merge into our feature branch15:12
frobwarevoidspace, ok15:12
frobwarevoidspace, I have a wily machine, in a spare minute I'll try building and running the tests there.15:13
voidspaceI don't think wily is the issue15:14
voidspacedimitern has wily and tests pass  for him I believe15:14
voidspacewell, except the payload/persistence tests that also fail intermittently on master and for which there is another bug15:14
dimiternvoidspace, I haven't run make check since the rebase, but will do soon15:19
cheryljjillr, can you ping me when you get a few minutes?15:29
alexisbfrobware, I need more coffee, will be there ina minute15:32
frobwarealexisb, ack15:33
voidspacedooferlad: bug in subnetReservedIPRanges15:38
voidspacedooferlad: it panics if there are no InUseIPAddresses on a subnet (index out of range when looking up ipAddresses[0])15:39
voidspacedooferlad: also, in the current pushed branch the purpose array for the reserved_ip_ranges is nil rather than an empty array if there are no purposes15:45
voidspacedooferlad: defaulting to "assigned-ip" would be better15:45
dooferladvoidspace: I think I have both of those fixed. Just found a really odd bug though - need to fix it or unreserved_ip_ranges is broken16:02
voidspacedooferlad: cool16:03
voidspacedooferlad: I've worked around them for the moment16:03
voidspacejust fixed another bug in my own code around struct copying16:04
voidspaceso all the subnets were missing from Spaces16:04
voidspaceto be fair I knew that was probably the case and was waiting for my test to prove it16:04
voidspacefixed now16:04
mupBug #1461957 changed: Does not use security group ids <ci> <openstack-provider> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1461957>16:10
mupBug #1519403 opened: 1.24 upgrade does not set environ-uuid <juju-core:Triaged> <https://launchpad.net/bugs/1519403>16:10
jillrcherylj: hey there, what's up?16:21
cheryljjillr: just wanted to checkpoint with you on the upgrade stuff.  I set up a time for us to chat.  Would that work for you?  (you should have an invite in your inbox)16:21
cheryljjillr: I just saw that you accepted it :)16:21
jillrcherylj: that time works, just sent an accept16:22
cheryljcool, chat with you then :)16:22
jillrgood deal16:22
frobwarevoidspace, can you move off go 1.3.3 and to 1.5 ?16:22
frobwarevoidspace, or put another way - if you switch to 1.5 do you still see the failing test in your branch?16:23
voidspacefrobware: I can try that16:25
voidspacefrobware: up to my neck in subnet tests right now16:25
voidspacewill try in a bit16:25
frobwarevoidspace, sure16:25
dooferladvoidspace: latest gomaasapi code pushed.16:42
voidspacedooferlad: thanks16:42
dooferladvoidspace: didn't fix that index out of range, but the adding a range code is there.16:43
dooferladvoidspace: just going to tidy that up now16:43
voidspacedooferlad: now purpose is coming back as a string not an array16:43
dooferladvoidspace: is that not OK?16:44
dooferladan array seemed odd and I couldn't work out why it would be >1 thing.16:44
voidspacedooferlad: no, it's an array of strings16:44
voidspacedooferlad: me neither16:44
voidspacebut an array of one string is what it is...16:44
dooferladvoidspace: easy enough to change. Will do that while I fix the out of range stuff16:45
dooferladvoidspace: fixed16:54
voidspacedooferlad: SetNodeNetworkLink is new, right?17:22
voidspacedooferlad: could it take a systemId instead of a Node, that would be much more convenient17:22
natefinchericsnow: why does the controller in an LXD environment need to be wily?18:57
ericsnownatefinch: the juju deb is built with Go 1.3+, thus supporting the LXD provider18:58
natefinchericsnow: we're installing jujud via the deb on the target machine?  not just downloading it?19:00
ericsnownatefinch: from the stream that was built from the deb19:01
ericsnownatefinch: (or use --upload-tools)19:01
natefinchericsnow: right, but isn't what we download from the stream just a binary?19:02
ericsnownatefinch: essentially19:02
natefinchso.... it'll work wherever19:02
natefinchoh wait19:02
ericsnownatefinch: the stream matches the series19:02
natefinchI understand19:02
natefinchwe're intentionally shooting ourselves in the foot because of Ubuntu.19:03
ericsnownatefinch: pretty much19:03
cheryljjillr: I had one more thing I was going to ask!  You had an environment that we were able to get to 1.26-alpha1, right?19:11
jillrcherylj: no to the best of my knowledge we were never able to successfully upgrade from 1.22.8 to 1.26-alpha in our staging environment19:13
cheryljjillr: hmm, I thought wallyworld had gotten you guys a script to force it to that level.  But, there was a lot of back and forth, and maybe that was in a test environment on our side19:13
jillrcherylj: I know there was a script in the works, and we were doing some mongo surgery at one point but that was unsuccessful aiui19:14
cheryljjillr: also, do you want to schedule your test upgrade to 1.25.1?  Since we'll be all together in the US, we could get a couple people on a hangout to make sure things go through successfully19:15
jillrcherylj: if we have that script I can do another test deploy/upgrade later today to confirm where we are19:15
jillrcherylj: that would be great19:15
cheryljjillr: how does Monday, Dec 7 work for you?19:15
cheryljI imagine we'll have moved 1.25.1 to stable by then19:15
frobwarewhich releases of MAAS will juju 1.25 and 1.26+ support?  1.8 and 1.9, or older versions too?19:17
jillrcherylj: if we can shoot for US-west afternoon that would work19:17
jillrthat's actually an excellent question for us as well cherylj ^^ we have a couple MAAS 1.7 deploys we'll be working on with these upgrades19:17
cheryljjillr: if you have time, you could also verify that the VIP switch is fixed in 1.26-alpha1 before then, either by attempting an upgrade again or directly bootstrapping it and trying to recreate bug 151615019:18
mupBug #1516150: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-core:Triaged> <https://launchpad.net/bugs/1516150>19:18
cheryljfrobware, jillr, if we don't get an answer here, I'll make sure to bring it up in the release call this afternoon19:19
cherylj(for the MAAS support question)19:19
jillrcherylj: can definitely test the VIPs, and thx on the MAAS question19:19
cheryljfrobware: will the answer impact your work on that bonding bug?19:20
jillrcherylj: I dont readily see the script on staging, will want to get a new/current copy of that to be safe please19:20
cheryljjillr: https://github.com/wwitzel3/juju-upgrade-hack19:20
jillrcherylj: awesome, thx19:21
cheryljI really wish we could all get away from using the word "hack" in anything we produce / comment on19:21
jillrI dig the readme  :)19:21
cheryljhahaha, yeah19:21
cheryljjillr:  you could even try the upgrade to 1.25.1 since it's in proposed.  Don't have to futz with 1.26-alpha119:22
jillrcherylj: I'll plan to do a deploy with the VIPs in the high range (to not hit #1516150) first and test 1.26-alpha1 with that script today19:22
mupBug #1516150: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-core:Triaged> <https://launchpad.net/bugs/1516150>19:22
jillrcherylj: then if I have time or else tomorrow with the VIPs in the low range for testing 1516150, and also 1.25.1 time permitting19:23
cheryljjillr: awesome.  Just let me know if you run into problems19:23
jillrcherylj: will do19:23
natefinchericsnow: my bug fix: http://reviews.vapour.ws/r/3224/19:39
natefinchericsnow: I'll review your fixes now19:39
ericsnownatefinch: k19:40
davecheneysinzui: the -race build has passed a few times now20:07
davecheney(minus the ususal mongo db rubbish)20:07
davecheneycan run-unit-tests-race be made voting please20:07
natefinchOMG that would be amazing20:10
natefinchcan we set the landing bot to run with -race too?20:11
sinzuidavecheney: alredy voting :) I added a second retry since the other voting unit tests also retry20:11
=== natefinch is now known as natefinch-afk
davecheneysinzui: fabulous!20:22
mupBug #1519473 opened: High resource usage and possible memory leak 1.24.5  <sts> <juju-core:New> <https://launchpad.net/bugs/1519473>20:50
wallyworldcherylj: jillr: just saw backscroll, didn't read in detail, but i did upgrade a 1.22.8 to 1.26-alpha1 on jujumanage@blah and the next day it was reset again20:59
wallyworldand then wayne took that and made it into a script20:59
jillrwallyworld: thx. I've got a redeploy cooking now, will give it a run via the script soon as this is done21:00
fwereadesinzui, awesome!21:01
fwereadeand davecheney, also awesome, thank you very much21:02
thumperfwereade: hey21:02
thumperfwereade: can you chat now?21:02
fwereadethumper, let's21:02
thumperfwereade, menn0: https://plus.google.com/hangouts/_/canonical.com/migrations?authuser=121:02
menn0thumper: on my way21:02
davecheneyfwereade: i'm just writing something to the troups21:03
alexisbwallyworld, thumper when the both of you are free we need to chat, after the release call if you would like21:49
wallyworld4 words guys hate21:50
wallyworldwe need to talk21:50
wallyworldi'm free now if that helps, not sure about thumper21:50
alexisbit should be the three of us21:51
wallyworldsure, i was waiting for thumper to confirm also :-)21:52
alexisbwallyworld, maybe we should keep pinging thumper21:54
wallyworldyeah, let's ping thumper21:54
* thumper is on a call with menn0 and fwereade21:54
thumperbut can come now21:54
alexisbso that thumper continues to here "ding"21:54
* rick_h_ wonders if you thump a thumper vs ping a thumper 21:54
rick_h_cruel menn021:55
wallyworldthumper ding ding21:55
wallyworldthumper ding ding21:55
alexisbthumper, ^^^21:55
rick_h_so not among friends here21:55
alexisbwallyworld, ^^21:55
cheryljmenn0: can you bump up bug 1517748 in your review queue today?  We're waiting on that for alpha222:12
mupBug #1517748: provider/lxd: test suite panics if lxd not installed <juju-core:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1517748>22:12
menn0cherylj: will do ... have been in calls and still am22:13
cheryljmenn0: thanks!22:13
menn0ericsnow, cherylj: ship it with questions22:19
ericsnowmenn0: thanks22:20
thumpersinzui: I *need* CI to run over the controller rename22:27
thumpersinzui: but we are going to have to be careful about how things are defined to be "multiple environment"22:27
menn0ericsnow: i'm happy with both those responses. thanks.22:28
ericsnowmenn0: no, thank you :)22:28
sinzuithumper: CI really cannot. most of the functional tests will fail and we need to clean the damage by hand22:34
sinzuithumper: I will ask abentley to take up the controller insullation work. I have fixes for 80% of jobs, the remaining 20% are hard. if Aaron and I agree that we can accept some known failures for a few run, we can run without complete support22:53
mupBug #1519527 opened: 1.25.1 as proposed:  1 or more lxc units lose agent state <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1519527>22:53
thumperwhat are the hard points?\22:54
thumpersinzui: worth noting that my idea of saying "look for create-environment" will soon be wrong :-|22:54
thumperas it will be "create-model"22:54
thumpersinzui: also... part of the clouds and credentials spec, the cache.yaml file is likely to be replaced too22:54
sinzuithumper: several functional tests don't use the common args and bootstrap helpers. TRheir bepoke code needs to be removed, or in the case of quickstart tests, we need to add the new intelligence22:55
mupBug #1519527 changed: 1.25.1 as proposed:  1 or more lxc units lose agent state <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1519527>23:02
mupBug #1519527 opened: 1.25.1 as proposed:  1 or more lxc units lose agent state <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1519527>23:05
wallyworldaxw: anastasiamac: sorry, in another meeting, delayed by 10 minutes or so23:14
axwwallyworld: sure, ping when you're ready23:14
anastasiamacwallyworld: k23:15
wallyworldaxw: anastasiamac: almost there, 5 more minutes23:35
anastasiamacwallyworld: k23:35
wallyworldanastasiamac: axw: there now23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!