thumperdavecheney: did you find a simple reproduction test case for the dbus issue?00:05
davecheneyworking on it now00:07
davecheneywill time box it til lunch00:07
davecheneythen move on to '63200:07
davecheneymenn0: you're on call reviewer ? http://reviews.vapour.ws/r/3228/00:20
menn0davecheney: looking00:33
menn0davecheney: I don't completely get the fslock code, but ship it I guess00:47
davecheneymenn0: IMO the fslock code is broke00:47
davecheneyand that fix just made it worse00:47
menn0yeah the fix didn't make any sense to me00:48
davecheneylook at line 11100:48
davecheneyline 125 is a noop00:48
menn0davecheney: exactly, that's what didn't make any sense00:48
davecheneyi want to revert the change so I can reopen the bug00:49
davecheneyfunc (conn *Conn) Signal(ch chan<- *Signal)00:49
mupBug #1519097: juju/utils/fslock: data race caused by createAliveFile running twice <juju-core:Fix Committed by dooferlad> <https://launchpad.net/bugs/1519097>00:49
davecheneythumper: i screwed around with dbus to try to make a repro but it's going to be a lot of work00:50
davecheneywaigani: do you have the panic message you got ?00:50
davecheneyi'll raise a bug with the dbus project00:50
davecheneythumper: I've created a fake dbus read/write/closer in an attempt to be a message pump that just spews out signal messags00:50
waiganidavecheney: yep, one sec00:51
davecheneybut it won't work unless it can emulate all the dbus connection handshaking00:51
waiganidavecheney: here you go: http://pastebin.ubuntu.com/13488000/00:51
davecheneywaigani: ta00:55
davecheneywaigani: https://github.com/godbus/dbus/issues/4501:04
davecheneyi'll look at fixing it this week01:04
waiganidavecheney: perfect. Thank you :)01:05
waigani insane unit test rig, indeed01:05
davecheneyit's unreasonable for other people to have to install all the stuff we do to reproduce our bugs01:10
davecheneythumper: cherylj perhaps this is the problem02:04
davecheneylucky(~/src/github.com/juju/juju) % juju set-env agent-stream=devel02:04
davecheneyWARNING key "agent-stream" is not defined in the current environment configuration: possible misspelling02:04
davecheneythumper: cherylj I cannot reproduce https://bugs.launchpad.net/juju-core/+bug/151763202:12
mupBug #1517632: juju upgrade-juju after upload-tools fails <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1517632>02:12
davecheneyworks for me02:12
thumperdavecheney: please comment on the bug as non-reproducable with what you tried, and unassign from you02:13
davecheneythumper: done02:16
cheryljdavecheney: yeah, you'll see that error if you haven't set agent-stream before.  It'll still pick up the correct stream.02:17
davecheneywhich it did02:20
davecheneyand worked fine02:20
cheryljyeah, at this point, I'll need to see if the bootstack team can recreate.02:20
thumperclucking bell02:21
thumperI have the fix for a bug02:21
thumperthe hard bit is testing the freaking thing02:21
=== natefinch-afk is now known as natefinch
cheryljwallyworld: ping?03:02
cheryljhey wallyworld, I've got a question for you.  The people who ran into that weird 1.23 -> 1.24 upgrade error yesterday are asking what they should do now - do a restore to 1.23, or do a file-level backup to 1.20, before they upgraded to 1.2303:03
mupBug #1517992: juju-upgrade to 1.24.7 leaves juju state server unreachable <juju-core:Triaged> <https://launchpad.net/bugs/1517992>03:04
cheryljif you're interested in taking a look03:04
cheryljI'm not sure what problems they could run in to with the file level backup.03:04
wallyworldwhen you say "do a file level backup to 1.20", what do you mean?03:04
cheryljLike restoring through something like crash plan or something03:05
cheryljoutside of juju03:05
wallyworldso you mean try and go back to 1.2003:06
wallyworldand then upgrade to 1.2403:06
wallyworldmenno has a script to upgrade off 1.2303:06
wallyworldi'd go that path first03:06
wallyworldas it has been tested and used by customers03:07
cheryljdo you know where I can find it?03:07
wallyworldmenn0: where's you 1.23 upgrade script?03:07
wallyworldthere was an email somewhere03:07
* menn0 looks03:08
* menn0 remembers03:08
menn0it's a juju plugin03:08
menn0in the standard repo03:08
wallyworldcherylj: that that help? ^^^^^03:09
cheryljmenn0: they're seeing this error on their state server:03:10
cherylj2015-11-19 17:28:27 DEBUG juju.apiserver.upgrader upgrader.go:185 desired version is 1.24.7, but current version is 1.23.3 and agent is not a manager node03:10
cheryljwould that script help in the case where the state server doesn't think it's a manager node?03:10
menn0that could be a side effect of the condition03:11
menn0cherylj: oh hang on, the message is from on the state server?03:11
cheryljmenn0: yeah03:12
* thumper headdesks03:16
menn0cherylj: weird. in the state server's logs does it look like most of the workers have have shut down?03:16
thumperI don't like this but submitting a fix with no test03:16
cheryljmenn0: the state server will start up, then shut down as it's trying to do an upgrade, but then that fails because of that error03:17
cheryljI mean, it will shut down the workers to try and do an upgrade03:18
menn0cherylj: hmmm, not sure.03:19
* menn0 looks at that code03:19
thumpermenn0: http://reviews.vapour.ws/r/3230/03:20
menn0cherylj: the plugin might still get the state server through it03:20
menn0cherylj: it'll change the tools symlink for the agent to the new version and restart the agent03:21
menn0cherylj: which will get it running the new version03:21
cheryljmenn0: okay, I will have them give it a try.  Thanks!03:23
menn0thumper: ship it03:24
thumpermenn0: ta03:24
menn0cherylj: they'll want to follow the instructions for installing juju-plugins. once they have the "juju unstick-upgrade" command will be available.03:25
cheryljthanks, menn0.  Hopefully this will work for them!03:26
cheryljjust one more question.  This was a failed upgrade off of 1.23 (to 1.24.7).  Will it still be okay to run the script?03:27
cheryljmenn0: ^^03:28
menn0cherylj: yes03:40
menn0cherylj: it addresses specific problems with getting off 1.23 to something newer 1.24 and up03:40
cheryljmenn0: cool, thanks.  Just wanted to double check :)03:40
thumperwallyworld: got a quick minute?03:53
thumper1:1 hangout03:54
davecheney  04:06
* thumper is done04:07
mupBug #1438951 changed: destroy-enviroment --force destroy all aws instances <destroy-environment> <ec2-provider> <juju-core:Expired> <https://launchpad.net/bugs/1438951>04:18
mupBug #1472009 changed: manual provisioning with juju requires systemd-services <manual-provider> <systemd> <juju-core:Expired> <https://launchpad.net/bugs/1472009>04:18
mupBug #1438951 opened: destroy-enviroment --force destroy all aws instances <destroy-environment> <ec2-provider> <juju-core:Expired> <https://launchpad.net/bugs/1438951>04:24
mupBug #1472009 opened: manual provisioning with juju requires systemd-services <manual-provider> <systemd> <juju-core:Expired> <https://launchpad.net/bugs/1472009>04:24
mupBug #1438951 changed: destroy-enviroment --force destroy all aws instances <destroy-environment> <ec2-provider> <juju-core:Expired> <https://launchpad.net/bugs/1438951>04:27
mupBug #1472009 changed: manual provisioning with juju requires systemd-services <manual-provider> <systemd> <juju-core:Expired> <https://launchpad.net/bugs/1472009>04:27
mupBug #1438951 opened: destroy-enviroment --force destroy all aws instances <destroy-environment> <ec2-provider> <juju-core:Expired> <https://launchpad.net/bugs/1438951>04:33
mupBug #1472009 opened: manual provisioning with juju requires systemd-services <manual-provider> <systemd> <juju-core:Expired> <https://launchpad.net/bugs/1472009>04:33
mupBug #1438951 changed: destroy-enviroment --force destroy all aws instances <destroy-environment> <ec2-provider> <juju-core:Expired> <https://launchpad.net/bugs/1438951>04:36
mupBug #1472009 changed: manual provisioning with juju requires systemd-services <manual-provider> <systemd> <juju-core:Expired> <https://launchpad.net/bugs/1472009>04:36
davecheneymenn0: http://reviews.vapour.ws/r/3232/05:04
wallyworldmattyw: is there a hangout?07:00
mattywwallyworld, ashipika grrr, should be one in the meeting thing?07:00
wallyworldnot that i can see07:01
mattywI remember giving it a "witty" name07:01
ashipikamattyw: how about https://plus.google.com/hangouts/_/canonical.com/cross-model-relations07:01
mattywashipika, heading there now, I can't even add a hangout to the meeting it seems07:01
wallyworldurulama: i have run into a problem. the charm store PutArchive function, called via the charmrepo UploadArchive(), complains when a charm is uploaded without a Series in the URL. But with series in metadata, it's perfectly ok to do this.07:50
wallyworldso I have a bunch of failing juju tests07:51
urulamawallyworld: so, yes, if series is in metadata, then you don't need it in the url. if it's not, then it's an old charm and series must be in the url as before07:51
wallyworldok, i need then to look at the test charms used by juju, thanks07:52
urulamathat behaviour is required to keep things backward compatible (and also makes sense, series must be provided somewhere in the uplaod)07:53
frobwaredimitern, ping08:16
dimiternfrobware, hey08:16
frobwaredimitern, re: 1519527 - are you on MAAS rc1 or rc2?08:17
dimiternfrobware, on rc1 still08:17
dimiternfrobware, but it was upgraded one too many times I think it's time for a fresh install08:18
dimiternfrobware, I was having issues with the old desktop pc I'm using - 1G RAM only, i386 P4 and occasionally overheating and throttling down - all that slows down machines deployment a lot08:19
frobwaredimitern, I was asking to see if the issue came in rc2; I still have rc1 so will try there first.08:23
frobwaredimitern, good morning btw. ;)08:23
dimiternfrobware, good morning :)08:25
dimiternfrobware, I'm done with service bindings in state - proposed it late last night08:25
dimiternfrobware, I'm doing a quick live test first and then will update the PR's description and ask for reviews08:26
frobwaredimitern, sounds great08:27
dimiternfrobware, wait until you see the diff :)08:28
frobwaredimitern, could do with brainstorming session later regarding rendering /e/n/i for bonds.08:29
dimiternfrobware, sure08:29
dimiterndooferlad, ping08:39
dimiternfwereade, morning!08:52
fwereadedimitern, o/08:52
jammorning dimitern08:52
dimiternjam, morning :)08:52
dimiternfwereade, I have a review for you, if you can have a look: http://reviews.vapour.ws/r/3223/08:53
dimiternfwereade, it's a bit large, but mostly due to heavy testing :)08:53
voidspacedooferlad: ping09:27
dooferladvoidspace: hi09:27
voidspacedooferlad: did you see my messages about SetNodeNetworkLink about 5:20pm last night?09:28
dooferladvoidspace: no09:28
voidspacedooferlad: SetNodeNetworkLink is new, right?09:28
voidspacedooferlad: it would be much more convenient if it took a SystemID rather than a Node09:28
voidspacedooferlad: as getting a node is inconvenient, and constructing one just to pass a system id (all the function actually needs) is a minor burden :-)09:29
dooferladvoidspace: OK, can you write what you want in an email / task? I am looking at another problem + have meetings09:29
voidspacedooferlad: ok09:29
voidspacedooferlad: np, see you at standup09:29
fwereadedimitern, reviewed, ping if questions09:40
dimiternfwereade, cheers!09:41
wallyworldurulama: there's still a problem. the charmstore.v5 func (h *ReqHandler) serveArchive(id *charm.URL...) method expects id to have series set. but it doesn't. the content which is uploaded has series in metadata, but that handler checks id.Series even before looking at the contents of the request09:55
wallyworldso it seems you can't upload a charm with url "~user/wordpress" even if the metadata.yaml has series09:56
wallyworldthat's using charmrepo.v2 csclient  UploadCharmWithRevision()09:57
urulamadid you set the export?09:58
wallyworldthis is for tests09:58
wallyworldurulama: looking at the code, i can't see how it could possibly work09:58
urulamawhich code?09:59
wallyworldthe code path used does not allow an id with out a series09:59
wallyworldcharmrepo.v2 csclient  UploadCharmWithRevision()09:59
urulamayou cant upload a charm with revision!09:59
wallyworldno, there is a revison10:00
wallyworldi just left off the params10:00
wallyworldthe code is10:00
wallyworlderr = client.UploadCharmWithRevision(id, ch, promulgatedRevision)10:00
urulamayes, promulgated revision :)10:00
wallyworldwhere promulgatedRevision is 3 or whatever10:00
wallyworldid is "wordpress-3"10:00
wallyworldch is a charm with series in metadata10:00
urulamathat the case to support the ingestion, where we have to use that10:01
wallyworldi follow the code and i can see how it would fail, the code doesn't allow id to have an emoty series10:01
urulamauploads should never set revisions in normal cases10:01
wallyworldso all this is in existing test code which is failing now tht series is not in the url but in metadata10:01
dimiternvoidspace, frobware, jam, fwereade, standup?10:02
urulamatest failing in juju or where?10:02
wallyworldtest failing in juju10:02
wallyworldit is uploading charms to then test bundle deployment10:02
wallyworldwe used to force a url to have the trusty series10:02
wallyworldbut now the test allows the url series to be "" because the series is in charm metadata10:03
wallyworldif i use the url "trusty/wordpress" then subsequent repo.Resolve("wordpress") calls fail10:03
wallyworldbut i should just be able to upload to "wordpress" and it should pick the series from the metadata10:04
voidspacedimitern: omw10:04
wallyworldbut the code errors immediately because it inspects the id and sees series = ""10:05
urulamawallyworld: so, uploads are of form cs:wordpress-3 then10:05
urulamarogpeppe: ^ seems core expects the case of name-revision uploads, the one we don't allow anymore10:05
wallyworldthe tests were written a while back, not by me so i am not sure of their heritage10:05
rogpeppewallyworld, urulama: looking10:06
wallyworldtestcharms.UploadCharm(c, s.client, "trusty/wordpress-0", "wordpress") is how it used to be10:06
wallyworldtestcharms.UploadCharm(c, s.client, "wordpress-0", "wordpress") is how i changed it10:07
urulamayes, this is not allowed, but might be a bug on our side10:07
wallyworldbecause the upload charm was modified to upload a charm with series in metadata10:07
rogpeppewallyworld: which commit of charmstore are you using?10:07
wallyworldthe latest10:07
rogpeppewallyworld: 2ce00261132ea5e70753c67d4c39e3f8d6e5f6f0 ?10:07
wallyworldfrom juju core deps.tsv10:08
urulamawallyworld: that's not the latest10:08
wallyworldi also tried pulling tip as well10:09
urulamawallyworld: but i don't think it matters in this case10:09
rogpeppewallyworld: you shouldn't be uploading the charm with a revision number10:09
wallyworldok, we can change core10:09
rogpeppewallyworld: the revision number should be chosen by the charmstore itselg10:09
wallyworldbut the rev number doesn't affect the series issue10:09
rogpeppewallyworld: it does10:09
wallyworldthe charmstore http handler for archive post seems to bail10:09
wallyworldwhen id has series = ""10:10
rogpeppewallyworld: because we only check that there's a series if the request is a PUT10:10
rogpeppewallyworld: not a POST10:10
rogpeppewallyworld: PUT is done when there's a specified revision id10:10
rogpeppewallyworld: POST otherwise10:10
wallyworldok, so i change juju core's tests to leave off revision10:11
wallyworldlet me do that10:11
urulamaalready mentioned this, so i think the tests are just wrong. the ones with revision should fail and the ones to be used are without revision10:11
rogpeppewallyworld: the reason we still check for series in PUT is that PUT is really there just for the legacy ingestion10:11
wallyworldrogpeppe: ok, so i just made that revision param -110:12
wallyworldwe'll see if test works10:12
rogpeppewallyworld: presumably it's a new test, otherwise it would have failed anyway, right?10:13
rogpeppes/failed anyway/failed beforehand/10:13
wallyworldrogpeppe: i annotaed and tests were written in sept by francesco10:14
wallyworldrogpeppe: but using -1 as rev still didn't work10:14
rogpeppewallyworld: hmm, but we didn't have multi-series charms back then10:14
rogpeppewallyworld: which test is failing?10:14
wallyworldno but the tests used to force a series10:14
wallyworldie UploadCharm("trusty/wordpress"...)10:15
wallyworldi'm removing the series10:15
urulamafrankban: hey, seems that some tests for bundle are failing in juju now that we have multiseries ... can you check with wallyworld, please10:15
rogpeppewallyworld: please tell me which test is failing so i can have a look at what's being tested10:15
wallyworldone sec10:15
wallyworldi'm modifying it because if i let it upload to "trusty/wordpress") then a call tp repo.Resolve("wordpress") fails10:16
wallyworldand i should no longer need to specify the series in the upload url anuway10:16
wallyworldrogpeppe: i haveto go get my wife, bbiab10:16
rogpeppewallyworld: k10:17
wallyworldrogpeppe: so a real issue here is that in the core code to process a charm url at deploy time, we were adding in the "default-series" env config propety as the series if the url had an empty series10:18
wallyworldthis should not be done10:18
wallyworldhence we now call repo.Resolve("wordpress") and not Resolve("trusty/wordpress")10:19
rogpeppewallyworld: yup, there are definitely a bunch of changes need to be made in core10:19
urulamawell, hm it should be done for legacy charms, right10:19
wallyworldunless the user does cs:trusty/wordpress of course10:19
wallyworldbut this change in part as made these bundle tests fail10:19
rogpeppewallyworld: so that test passes for me10:20
wallyworldyes because you don't have the above mods10:20
wallyworldcomment out the code in resolveCharmStoreEntityURL()10:20
wallyworldwhich adds the default-series if no url serie sis set10:21
wallyworldurulama: for legacy charms, surely we can still use cs:legacycharm directly without a series10:21
urulamayes, indeed, it'll use default-series10:21
wallyworldrogpeppe: so the issue is: test uploads to "trusty/wordpress", then the bundle code tries to repo.Resolve("wordpress") and boom10:22
wallyworldit says no charm found10:22
rogpeppewallyworld: hmm, "wordpress" *should* resolve correctly to "trusty/wordpress-0"10:22
rogpeppewallyworld: investigating10:22
wallyworldrogpeppe: ok, ty, bbiab and i will ping you10:23
wallyworldrogpeppe: urulama: btw, i have juju fully functional with new charn store , just getting the tests to pass10:23
rogpeppewallyworld: great!10:23
wallyworldall mltseries stuff works, incl overrides10:23
wallyworldok, really bbiab now10:23
urulamasee you later10:23
rogpeppewallyworld: ah!10:24
rogpeppewallyworld: i see the problem!10:24
urulamarogpeppe: what is it?10:24
rogpeppeurulama: it's that we don't allow wordpress-1 to resolve to trusty/wordpress-1 because that's a silly way to specify a charm10:24
rogpeppeurulama: because wordpress-1 looks like it's specifying a particular revision of a charm, but that makes no sense when it might resolve to trusty or precise or ...10:25
urulamaright, name-revision is not allowed10:25
rogpeppeurulama: yeah, and that's what the test is doing10:26
urulamaas written 20min ago :) "seems core expects the case of name-revision uploads, the one we don't allow anymore"10:26
rogpeppeurulama: trivially fixed (in that test case anyway)10:26
urulamaah, uploads ... i've meant resolution10:26
rogpeppeurulama: deleting two characters fixes it10:27
dimiternfrobware, https://github.com/lxc/lxd says LXD needs 1.3 and there's a PPA I guess you could try on trusty10:32
voidspacefrobware: so a fix for the intermittently failing payload/persistence bug has landed on master but isn't yet on maas-spaces10:38
voidspacefrobware: could you rebase again please :-)10:38
frobwarevoidspace, in progress10:40
frobwarevoidspace, dimitern, dooferlad: rebased maas-spaces to de99d4c3da857e478c60a57c806b0d8645078aba10:45
dimiternfrobware, great, I'll rebase mine and hopefully drop a commit or two fixing already resolved issues on master10:46
dimiternvoidspace, frobware, dooferlad, nice! so in the rebased maas-spaces, I only see the provisioner test failing now11:18
voidspacedimitern: me too11:20
voidspaceconflicts when I merge with my branch though :-/11:21
voidspaceah well, this is why we rebase11:21
mgzare you actually rebasing?11:22
mgzrather than merging in trunk?11:23
mgzso, the previously tested revs of your feature branch are all lost to the aether?11:23
voidspacemgz: no11:23
voidspacemgz: we're rebasing our feature branch11:23
voidspacemgz: and will then merge back onto trunk11:23
voidspacemgz: oh, hmmm... maybe11:24
voidspacemgz: but then the merge back onto trunk will itself be tested11:24
mgzI mean, it's a choice, old feature branch results are of limited worth if they're red11:24
mgzbut it does screw with the "look it passed, it's ready to merge" process11:25
voidspacemgz: I think it's a worthwhile trade-off11:25
voidspacemgz: it still needs to pass to merge11:25
dimiternmgz, we intend, I think, to stop rebasing and use merging as we're preparing to get it blessed and merge it in master11:26
mgzthat sounds perfectly sane.11:26
mgz...don't you need someone with write access to the repo to push --force the feature branch after rebase?11:29
dimiternmgz, btw I saw the mail about the voting status of the run-unit-tests-race job11:29
frobwaremgz, yes, that's what I'm doing.11:29
dimiternmgz, I did file a but a while ago that it won't ever pass if the timeout is not increased - had that happened?11:29
mgzokay, as long as that works.11:29
mgzdimitern: the stuff that was timing out has been skipped for now and bugs filed, so dave has some of that covered11:30
dimiternmgz, nevertheless, it still won't pass on a comparable machine with the same timeout as the race detector always slows things down11:31
dimiternmgz, I'll be happy to be proven wrong though, just sayin.. ;)11:32
mgzyeah, I know, I think some of the work will just need to be fixing some stuff like that in tests.11:32
wallyworldrogpeppe: saw backscroll, changing test to testcharms.UploadCharm(c, s.client, "trusty/wordpress", "wordpress") was not all that was needed. charmrepo csclient UploadCharmWithRevision() requires the charm id to have a revision so i had to set that to < -111:34
frobwaredimitern, I wonder why we would stop rebasing? We can continue to do that, leaving a final merge into master11:34
wallyworld>  -111:34
wallyworldthat gets further along till next error, thanks for help, i think i can fix the rest11:35
rogpeppewallyworld: you can still do UploadCharm(c, s.client, "trusty/wordpress-1", "wordpress")11:36
mgzfrobware: mostly just adding rebased revs after a bless should really have a ci retest before a merge is proposed11:36
rogpeppewallyworld: (as the test did before)11:36
rogpeppewallyworld: that worked for me11:36
wallyworldrogpeppe: ah, oh, what which string do i remove the -3 from11:37
* rogpeppe goes back to check11:37
wallyworldah i think i know11:38
mgzdimitern: thanks for responding on the 1.25.1 lxc address bug, I'll chase that up later today. didn't see anything relevent in the changes to .1 apart from the maas 1.9 pokings from you guys11:38
wallyworldrogpeppe: in the bundle11:38
dimiternfrobware, AIUI because the CI jobs are configured to test specific revisions and changing them might not trigger a CI run << mgz can clarify11:38
wallyworld            mysql:11:38
wallyworld                charm: mysql-111:38
rogpeppewallyworld: you need to remove the -1 from "mysql-1"11:38
wallyworldgreat, wil try that, ty11:38
frobwaredimitern, mgz: ok, gotcha. but presumably as and when the time comes we can force a retest11:39
rogpeppewallyworld: because mysql-1 is ambiguous with respect to non-multi-series charms11:39
rogpeppewallyworld: it's always been dodgy, but now we explicitly prohibit it11:39
wallyworldrogpeppe: refresh me, what can it be confused with?11:39
mgzfrobware: yeah, the rebase process is just a bit more error prone, and means past tests are non-repeatable. new testing is always fine.11:39
rogpeppewallyworld: so if you're specifying a revision number, you want an exact version of a charm11:39
rogpeppewallyworld: but if you specify a revision number but no series, you're saying "i want this revision of any one of a number of possible series"11:40
rogpeppewallyworld: but there's no link between revision numbers of different series11:40
rogpeppewallyworld: so it doesn't really make sense to specify a charm like that11:40
wallyworldah right yes11:40
wallyworldrogpeppe: but i now i still get cannot resolve URL \"cs:mysql\": charm or bundle not found")11:41
rogpeppewallyworld: and in the new multi-series world, wordpress-1 *is* unambiguous11:41
wallyworldbecause the upload was done for trusty/mysql not mysql. i think i need to add some fake charm metadata to the test11:41
wallyworldi had that before but got rid of it11:41
rogpeppewallyworld: this passes for me: http://paste.ubuntu.com/13501743/11:41
wallyworldthe test now just uploads an empty archive11:42
rogpeppewallyworld: "mysql" should resolve to "trusty/mysql-1"11:42
wallyworldrogpeppe: yes but your code does would explcitly force juju core to add "trusty" to the requested url11:42
rogpeppewallyworld: no it wouldn't11:42
wallyworldreally? i did in master11:43
rogpeppewallyworld: that only applies when you specify a revision number too11:43
rogpeppewallyworld: and when the charm is not multi-series11:43
wallyworldif ref.Series == "" {11:43
wallyworldif defaultSeries, ok := conf.DefaultSeries(); ok {11:43
wallyworldref.Series = defaultSeries11:43
rogpeppewallyworld: i thought you removed that code11:44
wallyworldyes, but if i add it back the test passes11:44
wallyworldif i take it out the test fails11:44
wallyworldso mysql is not resolving to trusty/mysql-111:44
wallyworldbecause i think the test uploads an empty archive11:45
rogpeppewallyworld: i got the test passing with that code removed11:45
rogpeppewallyworld: that shouldn't matter, i think11:45
wallyworldhmmm, ok, i'll poke a few things11:45
rogpeppewallyworld: one mo, i'll just check again11:45
* dimitern steps out for ~1h11:48
rogpeppewallyworld: so i've pushed a branch called "wallyworld-test" to rogpeppe/juju11:48
wallyworldrogpeppe: yes, so i had to modify the test to upload real charm metadata and that got it passed that bit11:48
rogpeppewallyworld: that test passes for me with the differences you can see11:48
rogpeppewallyworld: i'm surprised that was necessary11:48
wallyworldyeah, but it worked, i''ll check your branch11:49
rogpeppewallyworld: anyway, AFAICS testcharms.UploadCharm *is* uploading a real archive11:51
wallyworldRepo.CharmArchive(c.MkDir(), name)11:51
wallyworldit makes an empty dir11:51
wallyworldah wait11:52
rogpeppewallyworld: that makes an empty dir and then copies the charm archive into it11:52
wallyworldit copies11:52
wallyworldrogpeppe: damn, so my other other change that i can see might be of significance is that the charmrepo client asks for supported series in the Resolve() call. i still get the test failure but it all works live for real deployments. maybe if you get a chance you could look at this. ignore the unrelated crap, you'll see the change to resolveCharmStoreEntityURL() is essentially the same as yours. https://github.com/juju/juju/compare/12:01
wallyworldi'll keep looking as well, no hurry12:01
wallyworldjust if you get a moment12:01
wallyworldi still get12:02
wallyworld    c.Assert(err, jc.ErrorIsNil)12:02
wallyworld... value *errors.Err = &errors.Err{message:"", cause:"not found", previous:(*errors.Err)(0xc820424550), file:"github.com/juju/juju/cmd/juju/commands/deploy.go", line:341} ("cannot deploy bundle: cannot resolve URL \"mysql\": cannot resolve URL \"cs:mysql\": charm or bundle not found")12:02
wallyworldi retian some old behaviour for local:12:02
rogpeppewallyworld: looking12:28
wallyworldty, maybe fresh eyes will solve it12:28
rogpeppewallyworld: so your branch passes that test for me12:32
rogpeppewallyworld: (i needed to update charm to the export-unsupported-series-error branch)12:32
rogpeppewallyworld: does your branch have a current dependencies.tsv file?12:33
wallyworldrogpeppe: my branch also pulls in https://github.com/juju/charmrepo/pull/5512:33
wallyworldyeas except for the above which is new12:34
wallyworldi haven't added that to dependencies.tsv yet12:35
wallyworldas it has not landed12:35
rogpeppewallyworld: i checked that out, and the test still passes12:35
rogpeppewallyworld: could you paste me the result of running godeps -t in the commands directory?12:36
wallyworldrogpeppe: http://pastebin.ubuntu.com/13501930/12:36
rogpeppewallyworld: hmm, looks like there are some charmrepo changes you haven't pushed12:37
wallyworldrogpeppe: yes, i hacked the store url to point to the beta store12:37
wallyworldthat is the only change12:37
rogpeppewallyworld: does your test still fail when you use the published version?12:38
wallyworldthe official store url?12:38
wallyworldrogpeppe: oh, ffs. there was a change to charmrepo UploadCharmWithRevision I must have made earlier and didn't see. now the test psses12:40
wallyworldthe only change in charmrepo NOW is the store url change12:40
wallyworldnow i can finish some final unit tests and propose12:40
rogpeppewallyworld: ok, np12:40
wallyworldi'll land after new store is live12:41
wallyworldthanks for help with the charm urls12:41
rogpeppewallyworld: np12:41
wallyworldwill be good to get this working :-)12:41
rogpeppewallyworld: i'm glad we've got godeps :)12:41
wallyworldmy changes to charm repo were not to push :-)12:44
wallyworldjust to test the bew store12:44
mupBug #1519848 opened: Add IPv6 tests for cases using net.JoinHostPort <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1519848>14:35
mupBug #1519848 changed: Add IPv6 tests for cases using net.JoinHostPort <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1519848>14:38
mupBug #1519848 opened: Add IPv6 tests for cases using net.JoinHostPort <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1519848>14:41
voidspacedooferlad: ping16:14
mupBug #1519877 opened: 'juju help' Provider information is out of date <juju-core:New> <https://launchpad.net/bugs/1519877>16:14
dooferladvoidspace: pong16:31
voidspacedooferlad: how do I set a reserved ip range with a purpose?16:31
voidspacedooferlad: I can't use the method from the tests because it uses private members to do it16:32
voidspacedooferlad: and I can't see it exposed at all on the public api16:32
voidspaceI may just be missing something obvious16:32
dooferladvoidspace: AddFixedAddressRange and set the purpose in the passed AddressRange16:33
voidspacedooferlad: on Subnet?16:33
voidspacedooferlad: but the Subnet returned from NewSubnet is a pointer to a copy16:34
voidspacedooferlad: so adding the range to it doesn't set the range on the server16:34
voidspace(it's not what the test does for this reason)16:34
voidspaceI don't believe I can do that anyway16:35
voidspacelet me try16:35
voidspacedooferlad: ah, and AddFixedAddressRange requires me to construct an AddressRange16:35
dooferladI thought that NewSubnet returned a pointer to the created subnet, not a copy.16:35
voidspacedooferlad: and I can't set startUint or endUint as they're private16:36
dooferladvoidspace: Hmm, you really shouldn't need to do that. I think that I should auto-fill them for you.16:36
voidspacedooferlad: well, I'm calling subnet.AddFixedAddressRange - but I'm getting nul back from the reserved_ip_ranges call16:37
voidspacewhich should really be an empty array16:37
voidspacebut it shouldn't really be empty - but it is16:37
dooferladvoidspace: OK, I need to fix that whole flow.16:37
voidspacedooferlad: cool, thanks16:38
voidspaceyou should have emails with all those points in them16:38
voidspacedooferlad: any progress?18:20
cheryljdimitern, frobware:  Did you see the latest updates for bug 1519527?18:57
mupBug #1519527: 1.25.1 proposed:  lxc units all have the same IP address <openstack> <sts> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1519527>18:57
dimiterncherylj, yep, I'm in a call with mpontillo even as we speak18:58
cheryljthanks, dimitern!18:58
dimiterncherylj, seems more and more like a maas issue18:58
cheryljgood to know :)18:58
mupBug #1496237 changed: peergrouper tests very unstable with Go 1.5 <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1496237>21:00
mupBug #1496237 opened: peergrouper tests very unstable with Go 1.5 <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1496237>21:06
mupBug #1496237 changed: peergrouper tests very unstable with Go 1.5 <intermittent-failure> <tech-debt> <test-failure> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1496237>21:18
mupBug # changed: 1382556, 1412621, 1452082, 1464633, 1478943, 1483879, 1494542, 1494868, 1496972, 1499426, 1511138, 1512399, 1513492, 1513982, 1517748, 151812821:21
thumperaxw: http://reviews.vapour.ws/r/3240/21:56
wallyworldthumper: i talked with andrew and the best we came up with is disallow in modern juju and require people to use an older client if they really want to do it22:28
thumperwallyworld: see  http://reviews.vapour.ws/r/3240/22:28
wallyworldok, after release call22:29
davecheneymorning, http://reviews.vapour.ws/r/3232/22:38
davecheneyis anyone able to review this22:38
fwereadedavecheney, LGTM22:58
davecheneyfwereade: thanks22:59
sinzuithumper:  I think th issue is that status just hangs. Nothing is returned. After 300 seconds, the sript declares a failure. http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/aws-upgrade-20-trusty-amd64/339/console is just about to start the upgade23:12
sinzuimark timer23:12
sinzuitimer comlete23:17
sinzuiyes, status was called 4 times. the first 3 returned quickly, the 4th call hung for 5 minutes23:18
thumperdog walk time23:28
mupBug #1519994 opened: leader-elected hook never fires <juju-core:New> <https://launchpad.net/bugs/1519994>23:33
mupBug #1519995 opened: Upgrades from 1.20.11 to 1.25.2 fail because of status <blocker> <ci> <regression> <status> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged by thumper> <https://launchpad.net/bugs/1519995>23:33

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