/srv/irclogs.ubuntu.com/2013/02/28/#juju-dev.txt

thumperdavecheney: bug 113495900:05
_mup_Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 >00:05
arosalesdavecheney: aroun?00:16
arosalesaround, that is :-)00:16
davecheneyarosales: two secs00:24
davecheneystill on the phone00:24
davecheneythumper: thanks00:24
arosalesdavecheney: thanks00:25
arosalesdavecheney: when you are free I am using a the following for hpcloud in the environments.yaml file: http://pastebin.ubuntu.com/5572190/00:30
arosalesand I am getting the error error: secret-key: expected nothing, got "<redacted>"00:31
=== wedgwood is now known as wedgwood_away
arosalesdavecheney: I have tried variations of adding in "tenant-name" and "region" with no sucess00:38
arosales*success, that is.00:38
arosalesI did get AWS to bootstrap though and deploy wordpress/mysql00:39
davecheneyarosales: just finishing up00:41
davecheneyarosales: tip: remove secret key00:44
davecheneyit isn't used in our juju00:44
davecheneyi think it was optional in 0.600:44
arosalesaccess key too?00:45
davecheneyarosales: I usually let those flow through from sourceing .novarc00:45
arosalesdavecheney: I am not sourcing a novarc file00:45
arosalesso I think I need them somewhere00:46
arosalesdavecheney: aws set up worked, with the keypair access set up. Specifically putting in my access-key and secret-key embedded in the environments.yaml file.00:48
arosalesits just hpcloud environments.yaml file that is giving me guff.00:48
davecheneyarosales: ok, you have my complete attention :)00:49
arosales:-)00:49
arosalestldr I can't get hpcloud environment.yaml to work with go-juju00:50
davecheneyi've only tested against canonistack, and I let the valyes flow throught from sourceing my .novarc00:50
arosalesmy env.yaml for hpcloud is @ http://pastebin.ubuntu.com/5572190/00:50
davecheneylets see what I am missing00:50
wallyworld_arosales: if you have the latest go juju you can run "juju generate-config" and it will give you a boilerplate file00:50
arosaleswallyworld_: thanks, I also tried using that template00:50
davecheney^ what wallyworld said00:51
arosalesbut no go00:51
wallyworld_you should just havve needed to change the auth url00:51
wallyworld_worked for me anyway00:51
arosaleswallyworld_: and add in my credentials00:51
wallyworld_what version of juj you running?00:51
arosaleswallyworld_: I agree, but alas no bootstrap00:51
wallyworld_arosales: i just source a nova rc for that so they come from env vars00:51
arosaleswallyworld_: 1.9.9-2~923~quantal100:52
wallyworld_ok, latest version then00:52
arosaleswallyworld_: davecheney: so it is a requiment to source a novarc then?00:52
arosalesand if not get breakage?00:52
wallyworld_no, but if not, you need to have env vars set or edit the yaml00:53
davecheneyarosales: sorry, you've probably done this already, can you paste the output when you do00:53
davecheneyjuju bootstrap --debug -e '$YOURENV'00:53
arosaleswallyworld_: I got those creds in the yaml directly00:53
wallyworld_ok00:53
davecheneyyou can use paste.canonical.com for more private stuff00:53
wallyworld_incl region and tenant etc?00:53
arosaleslet me sanitize the output real quick00:54
arosalesdavecheney:00:55
arosales$ juju --debug bootstrap -e hpcloud00:55
arosales2013/02/27 18:53:59 JUJU environs/openstack: opening environment "hpcloud"00:55
arosales2013/02/27 18:53:59 JUJU juju bootstrap command failed: secret-key: expected nothing, got "<redacted>"00:55
arosaleserror: secret-key: expected nothing, got "<redacted>"00:55
davecheneyremove the secret-key line from your enviornment.yaml00:56
davecheneyyou may have to remove others00:56
wallyworld_arosales: can you pastebin your yaml - it seems out of date00:56
davecheneydid generate-config generate this config ?00:56
davecheneyor is this an old one that used to work with 0.600:56
arosalesdavecheney: if I remove the secret key how do I authenticate?00:56
davecheneysecret-key is a noop in our juju00:56
arosaleswallyworld_: http://pastebin.ubuntu.com/5572190/ is my latest env.yaml I made from the boilerplate00:56
wallyworld_arosales: you sure?00:57
arosalesdavecheney: I tried my config from juju-py and it didn't work so I tried with the boilerplate00:57
arosaleswallyworld_:  yes :-)00:57
wallyworld_ah ok, did you replace the admin-secrect with redacted?00:57
arosaleswallyworld_:  I am crazy most the time, but I just did this ;-)00:57
wallyworld_it should have been a random nmber of sorts00:58
arosaleswallyworld_: correct, I don't want to post my keys in the public ;-)00:58
arosaleswallyworld_: I did get aws bootstraped, just hp giving me issues.00:58
wallyworld_auth mode should be userpass i think00:58
davecheneyarosales: go juju does not use the secret-key configuration item00:58
davecheneyyou have to remove it00:59
arosaleswallyworld_: for authmod = keypass ?00:59
davecheneyarosales: i don't thikn goose supports that either00:59
davecheneythe only methods it supports is legacy and userpadd00:59
davecheneyuserpass00:59
wallyworld_arosales: what i meant before was that i think an earlier version of the boilerplate did have "redacted" in it00:59
arosalesdavecheney: so this is a bug then00:59
arosalesdavecheney: I think what you are telling me is I need to have my keys in a novarc, and it _can't_ be embedded in the env.yaml00:59
wallyworld_arosales: authmode should be userpass01:00
arosalescorrect?01:00
wallyworld_keypair is not supported yet01:00
wallyworld_for openstack01:00
arosalesreally?01:00
arosales:-(01:00
wallyworld_not a bug, just not supported01:00
arosalesmost folks use keys01:00
arosalesbug for 13.04 by default01:00
arosalesat lest in my opinion01:00
davecheneyarosales: I will raise a bug01:00
davecheneyyou are correct01:00
davecheneythe way the configuration works is01:00
davecheneymost items in ~/.juju/environments.yaml01:01
arosalesdavecheney: I can open the bug, I just wan't sure if it was pilot error01:01
wallyworld_arosales: its just that we have not ad the resources to get to it yet01:01
davecheneywill take values from ENV values if they are missing from the yaml file01:01
arosaleswallyworld_: understood, I just wanted to ask more folks to use go-juju and ran into this01:01
arosalesshould be noted in the release notes.01:02
arosalesunder known bugs01:02
davecheneyarosales: I will make sure it is noted in the next release notes01:02
wallyworld_userpass works ok with hpcloud :-)01:02
arosaleswallyworld_: ok, I"ll give that a try later tonight01:02
arosaleswallyworld_: davecheney thanks for the help01:02
arosalesdavecheney: would you like me to open the bug01:02
wallyworld_hence we needed to get other stuff working first :-)01:02
davecheneyarosales: yes please01:03
arosalesdavecheney: will do01:03
arosalesI'll get that logged later tonight.01:03
* arosales needs to attend to some daddy duty01:03
wallyworld_arosales: also, i found a showstopper yesterday which we are fixing asap - go juju won't be able to deploy to hp clound until fixed, even once you get your env sorted01:03
arosalesah, ok01:03
* davecheney thinks he knows what that one is :)01:03
arosaleswallyworld_: could you give me a ping when that lands in the ppa?01:04
arosalesor even to the juju list would be better01:04
wallyworld_arosales: sorry :-( still a work in progress, trying to get it done asap01:04
wallyworld_arosales: sure, no problem. aiming for next release hopefully01:04
davecheneyarosales: there is a juju-core-daily ppa01:04
arosaleswallyworld_: thanks01:04
davecheneywhich you can use if you're super keen01:04
wallyworld_arosales: thanks for your patience also, and sorry for the issues01:04
arosalesdavecheney: I may have to use that to get the fix01:04
arosaleswallyworld_: no worries part of trying out bleeding edge :-)01:05
arosalesthats part of the fun right?01:05
wallyworld_oh yes, very bleeding right now01:05
* arosales has to run01:05
arosaleslater fellas01:05
arosalesbe back online later tonight though01:05
arosalesthanks again01:05
wallyworld_ok, see ya01:05
=== arosales is now known as arosales-afk
davecheneyarosales: thanks for being a beta tester, i'll buy you a chocolate or a teddy bear in Altanta as a boobie prize01:05
wallyworld_davecheney: so about that mp....01:06
davecheneywallyworld_: sorry, a lot has scrolled off the screen01:06
wallyworld_yeah :-) np01:06
wallyworld_[09:53:17] <wallyworld_> davecheney: hi, a quick clarification on your concern about returning an unexported error01:07
wallyworld_[09:53:38] <wallyworld_> i coped the pattern used already in the state package for notFoundError01:07
wallyworld_[09:54:25] <wallyworld_> i guess the original author didn't want people to access anything other than Error() ?01:07
wallyworld_[09:55:24] <wallyworld_> that fact that we don't need the error exported (it's not used anywhere) - does that imply it can stay as is for now?01:07
davecheneyahh,yes01:07
davecheneysorry01:07
wallyworld_np01:07
davecheneyok, as I understand it01:07
davecheneyif you return a private type, with a public Error method01:07
davecheneythat satisfied the error interface01:07
davecheneybut callers may not be able to use a type asserting to tell what kind of error it is01:08
wallyworld_davecheney: there's a helper mthod for that01:08
wallyworld_IsNotFound()01:08
wallyworld_IsUNauthorised()01:08
davecheneyhaving said that, it looks like the method was doing the wrong thing01:08
davecheneyin which case, it does not help to comment that the type of the error will be x (little x, not exported) becuase there is nothing that can be done with that information01:08
davecheneymaybe in return you could replace the text with a hint to pass the error to IsNotFound(err)01:09
davecheneythat was all I ways saying in that comment01:09
davecheneyreturning unexported errors is something that gets on peoples' goat in the stdlibrary01:09
davecheneyfor example, errClosing01:09
wallyworld_davecheney: yeah, understood. i have no firm opinion being a Go noob. i was just being consistent with what was already done by someone else for notFounfError01:10
wallyworld_so i was going for consistency01:10
davecheneyok, lemmie review again, if you've already got 2 LGTM, then don't wait for me01:11
wallyworld_davecheney: i don't mind waiting - if there's an idiomatic issue like htis, i'd rather get it sorted instead of having the wrong thing cargo culted. as it is, i copied what was there before01:11
wallyworld_i assumed that it was done the right way previously for notFound01:12
davecheneyok, bio break, then review01:12
wallyworld_davecheney: ok, i have to run an errand, back in a bit and will look01:12
davecheneywallyworld_: re your CL02:17
davecheneythe previous type, ErrUnauthorized was exported02:17
davecheneyi'll put my comments in the review02:18
wallyworld_davecheney: it was, but only because it was a var. the other error commonly used in state package, notFoundError, was not exported.02:46
wallyworld_the implementation has changed from a var to a type, and there's a helper method used to discriminate the error type02:46
wallyworld_there already is a helper method in the MP too - IsUnauthorised()02:47
wallyworld_so, i'll add the comment as requested. thanks for looking02:48
davecheneywallyworld_: SGTM, either of those choices is fine02:49
wallyworld_ok, np. thanks. i just wanted to be 100% sure you were happy02:49
davecheneyno, thakn you02:49
davecheneythis isn't the end of the world02:50
davecheneybut its nice to go the extra mile02:50
wallyworld_there's a fair bit of inconsistency in places02:50
wallyworld_and then it gets cargo culted02:50
davecheneydo you want to raise an issue for the worst offenders02:50
davecheneyotherwise i fear they may never be addressed02:50
* davecheney appologises for sounding like a issue whoring broken record02:51
davecheneyi used to work for an issue tracker company02:51
wallyworld_i have no real concrete examples - but as i find them again i should keep a list02:51
wallyworld_it's just a general perception02:51
davecheneyand it was beaten into me that if there was no issue, it didn't happen02:51
wallyworld_yeah agreed02:51
davecheneyi'd like it if you kept that list in an issue02:51
davecheneyor at a minimum google docs02:51
wallyworld_sure.02:51
davecheneyon your own workstation isn't helpful02:51
wallyworld_some of it could be contentious eg error handling02:52
wallyworld_i have a philosophical difference in opinion with a few others i think02:52
davecheneyeven more reason to flush it out into the open02:53
wallyworld_a list also would determine if my perceptions are real02:53
wallyworld_perhaps there's not much to it02:53
* davecheney shrugs02:55
davecheneyi dunno how much there is02:55
davecheneybut setting a precident now is important02:55
davechen1ythumper: excellent proposal03:09
davechen1yi was going to propose something like that myself03:09
thumperdavechen1y: I was just about to ping you about it :)03:09
thumperjust a little editing and the help one is following03:09
davechen1ythumper https://bugs.launchpad.net/juju-core/+bug/113495903:14
_mup_Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 >03:14
davechen1yhow come I didn't get a notification about this one ?03:15
davechen1yi'm listed as the bugmaster on this project03:15
davechen1yor, to put it another way03:15
davechen1yhow can I change things so I get all notificatoins for all bugs on juju-core03:15
thumperI'm not sure...03:15
thumperyou should have03:15
thumpersure you don't have some weird ass email rules?03:15
davechen1yi have no email rules03:15
davechen1yi hate thunderbird so much03:15
davechen1yi'm not going to give it the satisfactoin of asking it to take on more responsibility03:16
davechen1yok, think I fixed it03:17
davechen1yi was sure the entire gophers team was subscribed03:17
wallyworld_thumper: do you have a copy of juju tools for precise compiled from tip you can share with me?04:40
wallyworld_actually, never mind, found some i think04:42
arosaleswallyworld_: question for you if you are free05:19
wallyworld_sure05:19
arosaleswallyworld_: are there any other package requirements for running go-juju other than juju-core?05:26
arosalesI retract that question I was able to get AWS deployed, so I think I have the requirements meet05:27
wallyworld_\o/05:27
arosaleshp still giving me some issues05:27
wallyworld_yeah, i found problems with jujud and other things, working on fixing now. sadly, hp cloud runs a different version to canonistack = problems05:27
arosaleswallyworld_: any idea what this error means05:29
arosales2013/02/27 23:29:06 JUJU juju bootstrap command failed: cannot find tools: no compatible tools found05:29
wallyworld_arosales:  you need to specify --upload-tools when using bootstrap as there is no well defined public bucket yet like for ec205:30
wallyworld_so for now, when testing, we just upload our own copy05:30
wallyworld_there will ultimately need to be a public place where the tools tarball lives which everyone shares05:31
arosaleswallyworld_: is there a test bucket I can use?05:32
arosalesI am thinking I need to state something to the effect "juju --upload-tools <something> bootstrap -e hpcloud"05:33
wallyworld_not that has been setup. if you use --upload-tools, it just puts a copy in your control bucket, around 2Mb i think05:33
wallyworld_just "juju bootstrap --upload-tools -e hpcloud"05:33
wallyworld_if you specify a public bucket url in your yaml, it will use that05:34
wallyworld_but that implies the tools have been pre-uploaded separately05:34
wallyworld_which we will do at some point05:34
wallyworld_and publicise the public bucket url, like for ec205:34
wallyworld_but for now, the above bootstrap command does the job05:35
wallyworld_bear in mind, bootstrap will fail for other reasons, currently being fixed05:35
arosalesgotcha05:35
arosalesinteresting how this didn't parse05:35
arosales$ juju --debug --upload-tools bootstrap -e hpcloud05:36
arosaleserror: flag provided but not defined: --upload-tools05:36
arosalesbut you way did05:36
wallyworld_maybe that neds to go at the end05:36
wallyworld_?05:36
arosalesyup, worked when I did it your way, odd it parsed it correctly when at the end05:36
wallyworld_yeah, odd i agree05:36
arosalesso it looks like I need have Go in my path?05:36
arosaleserror: cannot upload tools: build command "go" failed: exec: "go": executable file not found in $PATH;05:36
wallyworld_ah, you need the juju-core source and go to build the tools. hang on, i'll give you a url from which yo can download the tools tarball and upload manually to your hp cloudcontrol bucket05:37
wallyworld_you running precise or qantal?05:38
arosalesquantal05:38
wallyworld_http://juju-dist.s3.amazonaws.com/tools/juju-1.9.9-precise-amd64.tgz05:38
wallyworld_sorry, subst quantal in there05:38
wallyworld_upload the tarball to a tools dir in your control bucket05:39
arosalesin the gophers ppa I see "golang-stable" and "cobzr" do I need those?05:39
wallyworld_cobzr is for if you are doing devel work05:41
wallyworld_golang is Go itself05:41
* arosales looking for hp cloudcontrol bucket . . .05:47
wallyworld_arosales: i think i had to create mine manually, using the yaml control bucket vaue as the name05:48
wallyworld_if you tried bootstrap once, it may have made it for you already though05:48
arosaleswallyworld_: I should see that in the object store for region 1, correct?05:49
wallyworld_depends on the region in your yaml but yes05:49
wallyworld_it is for me05:50
arosalesah yes, given I am trying to work in region 105:50
arosalesI don't see one there so sounds like I need to make one with the name in my env.yaml05:51
wallyworld_arosales: fyi, my control bucket is juju-e802cb1c2e3ab47e3e4a1071cef25a9c05:51
wallyworld_you may be able to see that one05:51
wallyworld_depending on your credentials05:53
* arosales uploading . . .05:55
arosaleshrm, still getting the cannot upload tools error05:59
arosaleshttp://pastebin.ubuntu.com/5572611/05:59
* wallyworld_ looks06:01
wallyworld_arosales: unless you have the dev stuff installed locally, you need to upload manually the tarball and bootstrap without the upload tools flag06:02
wallyworld_upload-tools is more of a dev option06:02
arosalesok, I uploaded manually so I'll drop the upload-tools option06:03
arosaleswallyworld_: closer, but still not finding the tools06:05
arosaleshttp://pastebin.ubuntu.com/5572619/06:05
wallyworld_arosales: you uploaded quantal tools right? check you yaml and see if there is a default-series value in there06:06
wallyworld_if it says precise, you need to comment it out06:06
wallyworld_you also need to change the image id to a quantal one06:07
arosalesand I do have a object store container in az1 matching my control bucket in my env.yaml with juju-1.9.9-precise-amd64.tgz in it06:07
wallyworld_75839 from memory06:07
wallyworld_oh, so you have uploaded a precise tarball?06:07
wallyworld_i thought you were running quantal?06:07
arosalesI do have     default-series: precise in my env.yaml but my client is quantal06:07
arosalesdo they need to match06:07
wallyworld_no06:07
wallyworld_as long as default-series = tools tarball = image type you should be ok06:08
arosalescorrect I uploaded the precise tar file when I noticed my yaml had the default series for precise06:08
wallyworld_hmmm. not sure why it is complaining. did you upload tarbal to a tools container in the bucket?06:09
arosalesah I don't have it under a tools dir06:10
wallyworld_that would do it06:10
arosaleswallyworld_: nice catch on the missing tools dir, my bad.  That does get me closer06:13
arosaleshttp://pastebin.ubuntu.com/5572624/06:13
arosaleslooks like it has m1.small06:13
arosalesI think for HP that needs to be standard.small, right?06:14
wallyworld_arosales: yeah, that has been changed, but may have missed the 1.9.9 release06:14
wallyworld_you now specify the flavour in the yaml06:14
wallyworld_using default-instance-type06:15
arosalesvia     default-instance-type: standard.small06:15
arosalesok06:15
wallyworld_but it may not be in the 1.9.9 release06:15
wallyworld_that is deprecated btw, until we get constrainst further progressed06:15
arosalesseem it didn't like that yaml parameter06:16
arosaleshttp://pastebin.ubuntu.com/5572629/06:16
arosalesI can untar the precise yaml and correct06:16
wallyworld_arosales: the code to process it may not have made the 1.9.9 release06:17
wallyworld_so you might be out of luck until the next drop06:17
arosalesah there is just an executable in that tar file06:17
wallyworld_yes, jujud06:18
arosalesya looks to be that way06:18
arosales:-(06:18
wallyworld_sorry06:18
arosalesso close but yet so far06:18
wallyworld_go juju works for ec206:18
arosaleswe wanted to try some scale testing on HP06:18
wallyworld_close for openstack, but we only *just* finished the core code and are sorting out the final bits and oieces06:18
wallyworld_i'm really hopeful we'll be there for next release06:19
arosales Looks like 1.9.10 is expected on march 9 if all goes well06:21
arosaleswallyworld_: thanks for your time and help. I was going to write this up and send it out to folks wanting to deploy on HP cloud.  But I'll wait for that once the control tools are ready06:22
arosaleswallyworld_: would you suggest I use the daily ppa?06:23
wallyworld_arosales: no problem, i'm just sorry we're not quite there yet. the daily ppa would have all the latest fixes in it (and maybe also bugs). but i can't be worse than now right06:24
wallyworld_s/i/it06:24
wallyworld_you still won't be able to get a system fully working though06:24
wallyworld_still some more things to sort out06:24
arosalesok, perhaps it is best to wait for 1.9.10 then06:25
arosalesbtw, do you have a pointer to the daily?06:25
wallyworld_not handy but i can find it06:25
wallyworld_arosales: https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily06:29
wallyworld_from there you can grab the one you want06:29
arosaleswallyworld_: thanks for link, and thanks again for your time to help me step through the openstack setup for HP. Much appreciated06:31
wallyworld_no problem at all, please to help.06:31
wallyworld_hopefully next time we talk thiings will be working :-)06:31
arosaleswallyworld_: do you want me to open up a bug on the control file needing updated to have standard.small?06:32
wallyworld_arosales: no, already fixed :-)06:32
wallyworld_just not in the release yet06:32
arosalesok06:32
arosalesgotcha, enjoy the rest of your day.06:33
wallyworld_you too, almost wine o'clock here :-D06:34
arosalesnice06:39
arosalesI guess if I were to try the daily on HP I would need a matching control bucket tar file, which probably isn't available just yet . . .06:45
wallyworld_correct07:02
wallyworld_but you can get one from ec207:03
wallyworld_no07:03
wallyworld_i don't think we upload the daily tarballs07:03
arosalesyup, I didn't see one on ec2 with the urls I tried. have a good evening wallyworld_ ttyl07:50
fwereademorning gents08:11
fwereadeI am reverting to r942, because r943 and all following were committed with failing tests08:12
dimiternfwereade: morning08:12
fwereadedimitern, heyhey08:13
fwereadedimitern, I has a grumpy: please run the full test suite before you submit08:13
dimiternfwereade: I saw that bug report about failing uniter tests08:13
dimiternfwereade: I *did* several times!08:13
fwereadedimitern, frankly, please run it before yu even propose08:13
fwereadedimitern, hm, that is odd then08:13
dimiternfwereade: I always do08:13
dimiternreally odd08:14
fwereadedimitern, sadly they're failing consistently for me in r943, and ok in r942, so I'm backing everything out until we can figure out what went wrong08:14
dimiternfwereade: ok, I'll investigate what went wrong08:15
rogpeppemornin' all08:15
dimiternrogpeppe: hiya08:15
rogpeppefwereade: yeah, i get a compilation failure in trunk08:15
fwereaderogpeppe, a *compilation* failure? goose maybe?08:16
dimiternrogpeppe: where?08:16
rogpeppefwereade, dimitern: it's pretty weird actually:08:16
rogpeppestate/assign_test.go:5: cannot use &txn.Op literal (type *txn.Op) as type txn.Op in return argument08:16
rogpeppebut that's on an import statement08:17
dimiternrogpeppe: hmm08:17
rogpeppei'll blow away $GOPATH/pkg and see if it still happens08:17
fwereaderogpeppe, huh, I didn't see that myself :/08:17
dimiternrogpeppe: what did you run?08:17
rogpeppedimitern: go test ./...08:17
rogpeppedimitern: in juju-core root08:17
fwereadedimitern, rogpeppe: for form's sake, can I get a quick check of https://codereview.appspot.com/742204408:17
dimiternfwereade: I run go test -i ./... && go test ./... in worker/uniter several times when I was changing the uniter tests (to compare timings) - all was fine08:18
dimiternfwereade: I'm on it08:18
fwereadedimitern, you didn't change the uniter tests in r943 -- that was the SetCharm branch08:19
dimiternfwereade: hmm08:19
dimiternfwereade: well, yes I confess i didn't run the uniter tests when I did setcharm stuff, because it was only in state/ and all tests there run fine08:20
fwereadedimitern, IMO we should *always* be running the full test suite before we commit (really, before we propose)08:21
rogpeppefwereade: +108:21
dimiternfwereade: go test ./... in juju-core/ you mean?08:22
fwereadedimitern, we changed behavior in state -- anything that uses state *might* have been depending on something we changed08:22
fwereadedimitern, yeah08:22
rogpeppefwereade: we should probably be running the live tests actually.08:22
dimiternfwereade: ok, sorry, I promise I'll do that from now on08:22
fwereadedimitern, thanks :)08:22
fwereaderogpeppe, hmm, what's the point of the double then?08:23
dimiternfwereade: i guess all my changes before were isolated enough so running the tests for what I changed was good enough08:23
fwereaderogpeppe, if the double can't tell us when we've broken things I question its value08:23
rogpeppefwereade: it means that you get *some* confidence. but it doesn't run all the agents.08:23
fwereadedimitern, it's a tempting idea, but it has a tendency to bite one in the ass ;)08:23
dimiternrogpeppe: I have this failure in rpc: http://paste.ubuntu.com/5572797/08:24
rogpeppedimitern: can you reproduce it (it works ok for me)08:24
rogpeppe?08:24
dimiternrogpeppe: I just ran all tests (still running)08:25
rogpeppefwereade: that compilation failure only happens against go tip. something weird's up.08:25
rogpeppefwereade: i suspect a inlining bug08:26
fwereaderogpeppe, grar08:26
rogpeppefwereade: i have an idea where it might lurk actually.08:26
dimiternfwereade: instead of reverting everything, can't we just revert my setcharm stuff?08:28
dimiternrogpeppe: running all tests again rpc was a PASS08:29
rogpeppedimitern: hmm, i'll have a look at it08:29
rogpeppesome days, everything seems broken08:29
dimiternbut this time I have a build failure in store08:29
dimitern# launchpad.net/juju-core/store08:29
dimiternstore/lpad.go:7: import /home/dimitern/work/go/pkg/linux_amd64/launchpad.net/lpad.a: not a package file08:29
rogpeppedimitern: that does seem weird08:29
rogpeppedimitern: it might be because you interrupted a compilation in an odd place, i suppose08:30
rogpeppedimitern: try blowing away that file and trying again08:30
dimiternrogpeppe: that solved it08:32
dimiternfwereade: before you revert all that, let me just check if reverting the setcharm cl will solve the issues08:33
rogpeppehmm, i think i've found where my compilation error comes from: func (@"".s·2 *@"".Settings "esc:0x0") @"".assertUnchangedOp () (? @"labix.org/v2/mgo/txn".Op) { return &@"labix.org/v2/mgo/txn".Op{ C:@"".s·2.@"".st.@"".settings.Name, Id:@"".s·2.@"".key, Assert:(@"".D{ 0x0:{ Name:"txn-revno", Value:@"".s·2.@"".txnRevno } }) } }08:33
rogpeppethere's a spurious & in there08:33
dimiternrogpeppe: that seems like the same cl08:33
dimiternrogpeppe: my bad again :(08:33
rogpeppedimitern: the code looks fine though08:33
fwereadedimitern, I kinda want to roll back to before that point08:35
fwereadedimitern, I don't know wtf tim/ian/gustavo were doing committing their changes without running the test suite08:36
dimiternfwereade: and after that we selectively reapply each CL to see were it failed?08:36
fwereadedimitern, after that it's up to RUN THE TESTS and then maybe resumbit their code08:37
fwereadedimitern, I am not exclusively grumpy with you, I am grumpy with everyone who committed to a broken trunk without reverting it08:38
dimiternfwereade: fair enough, although I don't think it's fair for other people to suffer if i'm the one to blame (probably)08:39
fwereadedimitern, you're the ultimate cause of the failures, but they're responsible for running the tests as well -- if something like this slips through again (which it will, someone will make some series-specific assumption) it should be the detector's responsibility to unbreak, notify the perpetrator, and submit on top of a *clean* trunk08:40
dimiternfwereade: yes, you're right - they should've run the tests before landing after it was broken08:41
dimiternfwereade: it might be even a good thing to put in the channel topic: RUN juju-core/$ go test ./... BEFORE EVEN PROPOSING A CHANGE :)08:42
dimiternfwereade: hmm, it seems maybe I'm not the only one to blame, because reverting the setcharm CL and running the tests they failed in state/watcher/08:49
rogpeppefwereade: FWIW proposing does a merge, so really you should merge trunk, *then* test everything08:49
fwereaderogpeppe, what, people aren't already doing this?08:49
fwereaderogpeppe, I guess not08:50
rogpeppefwereade: not necessarily before very propose. the problem is it can muddy the diffs08:50
rogpeppes/very/every08:50
fwereaderogpeppe, if the diffs are muddied it's because the change to trunk has actually muddied the proposal08:50
dimiternfwereade: I merge trunk before proposing ever since I had issues with MPs in LP with MAAS08:50
fwereadedimitern, +108:51
rogpeppefwereade: i always merge before submitting, but not always before every re-propose08:51
rogpeppefwereade: otherwise you see big diffs between the different revisions in codereview, so people can't easily see what you've changed in response to their review08:52
fwereaderogpeppe, first propose and final sumbit are the points at which I think there's no excuse08:52
dimiternafter reverting 943 I have this failure:08:52
dimiternFAIL: watcher_test.go:285: WatcherSuite.TestDoubleUpdate08:53
dimiternwatcher_test.go:295:08:53
dimitern    assertNoChange(c, s.ch)08:53
dimiternwatcher_test.go:82:08:53
dimitern    c.Fatalf("watch reported %v, want nothing", got)08:53
dimitern... Error: watch reported {test a 4}, want nothing08:53
fwereaderogpeppe, being a bit casual about midstream proposes is probably ok :)08:53
dimiternall others pass08:53
fwereadedimitern, would you have a quick look in the juju-core bugs? I suspect that is known but intermittent and rare enough that we haven't managed to track it down yet08:54
dimiternfwereade: looking08:54
dimiternfwereade: I cannot find anything similar, I'll file a bug08:55
fwereadeTheMue, https://bugs.launchpad.net/juju-core/+bug/113544208:58
_mup_Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 >08:58
dimiternthere it is bug 113544408:59
_mup_Bug #1135444: state/watcher intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135444 >08:59
fwereadeTheRealMue, https://bugs.launchpad.net/juju-core/+bug/113544209:00
_mup_Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 >09:00
fwereadedimitern, rogpeppe, TheRealMue: I'm about to submit https://codereview.appspot.com/742204409:01
rogpeppefwereade: how much history does it unwind?09:01
dimiternfwereade: go for it09:01
fwereaderogpeppe, about 5 revs09:01
rogpeppefwereade: i was wondering if it might be better just to unwind dimiter's change09:02
fwereaderogpeppe, tim, gustavo and ian *all* committed with broken code09:02
rogpeppefwereade: but was it their code that was broken, or just the one merge that they committed on top of?09:02
fwereaderogpeppe, if trunk is broken and you commit to it, you broke trunk too09:03
rogpeppefwereade: i guess so09:04
dimiternthere is the other rpc bug 113545209:04
_mup_Bug #1135452: rpc: intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135452 >09:04
fwereade_rogpeppe, am I insane? I know I am pissed off but I *think* my judgment is clear here09:06
fwereade_rogpeppe, if the tests don't pass, it's not ok to commit09:07
rogpeppefwereade_: i'd probably just unwind the commit that causes the problem, but i know that's more hassle09:07
fwereade_rogpeppe, if someone else broke it, you don't get to say "meh, not my problem" and compound the issue09:07
dimiternfwereade_: +109:07
* fwereade_ submits09:09
=== fwereade_ is now known as fwereade
dimiternnow on to making things right again :)09:18
fwereadedimitern, cheers :)09:20
=== TheRealMue is now known as TheMue
TheMuefwereade: Oh, thx, will investigate. Have missed your notification.09:26
fwereadeTheMue, I think you just need to let the system pick the port for each test09:27
TheMuefwereade: Yep, no constant value.09:27
TheMuefwereade: To avoid the current troubles which rev shall I take? 942?09:29
fwereadeTheMue, I've reverted everything since r942 so yu should be good to go with tip09:29
TheMuefwereade: OK, will do so.09:29
fwereaderogpeppe, a thought re running live tests09:33
fwereaderogpeppe, we do at least have tests for the userdata we send up with a new instance, right?09:33
rogpeppefwereade: well, some basic sanity checking, yeah.09:33
rogpeppefwereade: but it doesn't actually run anything09:34
fwereaderogpeppe, if those checks are not sufficient to guarantee that the userdata still works, I don't think that's enough09:34
fwereaderogpeppe, I understand we don't want to run things09:34
fwereaderogpeppe, but is it not possible to figure out which bits can change (and how) and which bits can't?09:35
rogpeppefwereade: in the end, how can you test it properly without actually running it on the target machine?09:35
fwereaderogpeppe, well, how much actually changes in the userdata from one machine to another?09:36
fwereaderogpeppe, AIUI the bulk of it is identical; the bits that change surely do so in a predictable way, right?09:36
rogpeppefwereade: it's not the user data, it's the environment that the user data runs in. the *combination* needs to be tested, no?09:36
rogpeppefwereade: i'm not quite sure where you're going here09:37
fwereaderogpeppe, I'm saying that if the userdata changes in a way we don't have good reason to believe to be sane, tests should fail09:38
rogpeppefwereade: i'm not quite sure what kind of check you're thinking of here.09:39
rogpeppefwereade: and if it such a check would actually have caught any of the actual failures we've seen in the past09:39
fwereaderogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/09:42
fwereaderogpeppe, do you consider this to be adequate?09:43
fwereaderogpeppe, if yu said anything, I didn't see it09:51
rogpeppefwereade: i didn't - sorry, i didn't see your reply earlier.09:52
rogpeppefwereade: those tests should certainly be better09:52
fwereaderogpeppe, I haven't seen anything since:09:52
fwereade <fwereade> rogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/09:52
fwereade rogpeppe, do you consider this to be adequate?09:52
rogpeppefwereade: i haven't said anything since then09:52
fwereaderogpeppe, ok, cool, just wondered if stuff got stuck09:53
fwereaderogpeppe, o you see my point, though? that we could do *much* better here09:53
fwereaderogpeppe, and that the local tests ought if anything to be an over-sensitive canary for the live tests09:54
rogpeppefwereade: i'm sure that's true. however, would better tests there have caught any of the problems we've actually seen?09:54
fwereaderogpeppe, they should fail so people know to run the live tests for verification09:54
fwereaderogpeppe, are yu telling me that you have never written code which passes the local test suite but doesn't work in reality?09:54
rogpeppefwereade: i'm saying that the reason it failed would not have been caught by a simple script test.09:55
rogpeppefwereade: the important script tests are in cloudinit, which *does* check the scripts in detail.09:55
rogpeppefwereade: the idea of the tests in the individual providers is that they check that the right params were passed to cloudinit. they should definitely do better in that respect09:56
fwereaderogpeppe, so you've written code that broke juju without changing the scripts... but have never written code that changed the scripts that didn't break juju?09:57
fwereaderogpeppe, even if that is the case I don't think we can assume that everyone has so complete an internal ubuntu simulator09:57
rogpeppefwereade: when i wrote code that changed the scripts, the only way to tell if it will break juju is by running them live.09:57
fwereaderogpeppe, how do you know when you write code that changed the scripts?09:58
rogpeppefwereade: when changing the actual scripts generation in cloudinit09:58
fwereaderogpeppe, that's not the only time09:58
rogpeppefwereade: the other way is by changing the parameters in MachineConfig09:59
fwereaderogpeppe, or changing config.Config09:59
fwereaderogpeppe, or changing upstart, or cloudinit, or agent, or...09:59
rogpeppefwereade: all of those are tested by the environs/cloudinit tests, no?10:00
fwereaderogpeppe, some of them may be10:00
rogpeppefwereade: which should test for the range of possible MachineConfig configurations10:00
fwereaderogpeppe, is it not the case that individual providers construct their own MachineConfigs from scratch?10:01
fwereaderogpeppe, and that any one of the could, say, forget to strip secrets?10:01
rogpeppefwereade: yup. i think perhaps the check in the provider should be check(userData, Equals, expectedMachineConfig.Render())10:03
fwereaderogpeppe, that sounds reasonable, I think, it closes the loop quite neatly10:03
rogpeppefwereade: that *still* won't find out real world problems though. we'd still need to run live tests before submitting, really.10:04
TheMuefwereade: Got my fix done, but I've got 3 fails testing all. See http://paste.ubuntu.com/5572965/.10:05
fwereaderogpeppe, although I think it would probably be even better if you did a MachineConfig-style output check on the stuff passed up to the instance though10:05
fwereaderogpeppe, that way the test that fails will be at least close to the tests you need to run for verification10:05
rogpeppefwereade: you mean have the scripts literally in each provider?10:06
fwereadeTheMue, would you please: (1) verify they're intermittent (2) add bugs, mark them high (3) assign to likely people?10:06
fwereadeTheMue, I can take the filter test10:06
TheMuefwereade: Will do so, yep.10:07
fwereadeTheMue, I suspect ian is a good candidate for TestPersistence in openstack10:07
TheMuefwereade: OK10:07
fwereaderogpeppe, is OpPutFile is your stuff?10:07
rogpeppefwereade: it was originally, though it's changed a bit since i last touched it i think.10:08
* TheMue has to do a short break, bringing daughter to work. BIAB10:08
fwereaderogpeppe, yeah, I think so10:08
rogpeppefwereade: it's enough of a pain changing the literal scripts inside cloudinit that i'm not sure doing it in many other places is a great idea.10:08
fwereaderogpeppe, surely it is dwarfed by the effort of running each set of live tests?10:09
rogpeppefwereade: i'm not sure how it helps particularly. rather than check(userData, Equals, expectedMachineConfig.Render()), we've got check(userData Equals, someLiteralStringWhichWeNeedToChangeEveryTimeCloudinitChanges)10:10
rogpeppefwereade: if there's a bug in the generated scripts, it's in environs/cloudinit, not the providers themselves.10:11
fwereaderogpeppe, nonsense10:12
rogpeppefwereade: assuming that the correct args are passed into MachineConfig10:12
fwereaderogpeppe, the environs create the input data10:12
rogpeppefwereade: (which is checked by the suggested userdata test)10:12
rogpeppefwereade: surely it's cloudinit's job to turn the MachineConfig spec into an actual script? the important thing in each provider is not the exact form of the script but the spec that's passed to cloudinit AFAICS.10:13
rogpeppefwereade: if we find that cloudinit is generating the wrong script given some set of input params, we should add that set of input params to the cloudinit script tests.10:15
fwereaderogpeppe, we should, yes; but we should also have some reason to believe that those scripts will run live10:16
fwereaderogpeppe, the number of things that change the cloudinit output is potentially high10:16
fwereaderogpeppe, if someone causes a change there, they should be running those actual changes live10:17
fwereaderogpeppe, ...shouldn't they?10:17
rogpeppefwereade: any time the cloudinit tests need adjusting, we should run all live tests. in fact, anytime *anything* changes, we should run all live tests. the scripts are a very minor part of it.10:19
fwereaderogpeppe, I agree that live tests should run regularly, but I don't think it's sane to impose that requirement in all cases... how long do the live tests take?10:23
rogpeppefwereade: about 17 minutes currently10:24
rogpeppefwereade: i do kinda see the point though - having the literal string as a "if it's different from this, you need to run the live tests".10:24
fwereaderogpeppe, ok, could have sworn it was longer :)10:24
rogpeppefwereade: we could even use a hash of the output10:24
rogpeppefwereade: it feels like it takes forever :-)10:25
fwereaderogpeppe, I think we need to be a bit smarter -- eg server certs/keys will change each time -- but in that case I'd check validity wrt the CA cert and leave it at that10:25
rogpeppefwereade: it would mean that noone could submit any branch that changed the cloudinit output without it first being checked live against all providers10:25
rogpeppefwereade: it's not that easy10:26
fwereaderogpeppe, hmm, go on?10:26
fwereaderogpeppe, my position is predicated on the idea that the few bits of the scripts that do change do so in predictable and checkable ways10:27
rogpeppefwereade: if you want to check cloudinit output *without* the certs, you have to break up the cloudinit in exactly the same way that environs/cloudinit does. that's a frikking pain10:27
fwereaderogpeppe, nobody said good testing was easy10:27
rogpeppefwereade: it's not just a pain, it's an *ongoing* pain.10:28
rogpeppefwereade: because you need to search out the right bits to change every time the cloudinit output changes.10:28
fwereaderogpeppe, I think that's better than an ongoing situation in which "go test ./..." doesn't take a position on whether or not the providers actually work10:29
rogpeppefwereade: this wouldn't either.10:29
fwereaderogpeppe, ISTM that it would fail any time there's a risk of the live tests failing10:30
rogpeppefwereade: there's always a risk of the live tests failing10:30
fwereaderogpeppe, ...and it being a direct result of changes just made10:30
rogpeppefwereade: can you give an example of a live test failure that this would have caught?10:31
yolandahi, i'm having a problem creating juju instances in openstack, i have to run /var/lib/cloud/instance/scripts/runcmd on each machine to make it work10:32
rogpeppefwereade: if we made the testing certs unchangable, things would be easier perhaps.10:33
fwereaderogpeppe, let me turn that around: if secrets are in the environ config, a test should fail. if the state server certs does not match the key, or cannot be verified by the ca cert, a test should fail. if the machine agent is not invoked with the correct machine id, a test should fail10:33
fwereaderogpeppe, the fact that we happen not to have broken any of these yet, as far as I am aware, does not impact the fact that they should actually be tested10:34
rogpeppefwereade: all those things sound like tests on the MachineConfig input itself rather than than on the generated script.10:35
rogpeppefwereade: perhaps there's a case for intercepting the render step to see what actually gets passed to cloudinit rather than trying the reverse-engineer the output10:36
fwereaderogpeppe, if use of cloudinit is optional in the providers -- which it is -- I think we must resign ourselves to checking what the providers actually produce10:39
rogpeppefwereade: surely each provider can decide how best to check its user data? this is very much a provider-specific test.10:40
mgzoptional in what sense?10:41
fwereademgz, in the sense that we don't necessarily have cloudinit available10:41
mgzthat's... not the case?10:41
fwereademgz, maybe it's working in lxc now? it certainly wasn't a while ago10:42
mgznothing functions at all unless cloudinit is present and runs10:42
mgzah, lxc is special, and doesn't exist for go yet10:42
rogpeppemgz: it will soon :-)10:43
fwereademgz, anyway, rogpeppe just blocked a change of mine on the basis that cloudinit wasn't special10:44
mgzjust using cloudinit for lxc too is probably simpliest10:44
fwereademgz, he's right about this, I think10:44
rogpeppemgz: at some point in the future we'll probably want juju to work under other systems without cloudinit (windows, for example)10:45
fwereademgz, it would be a bit weird to explicitly pass cloudinit-specific stuff into an environ when launching an instance10:45
mgzI'm not sure about that.10:45
mgzI have two thoughts: we have too much junk in the cloudconfig that shouldn't really be there right now10:45
fwereademgz, +1 on that, I think10:46
mgzbut the generic stuff we'd just end up duplicating in something that looked very much like cloudinit if we didn't use it in a provider10:46
rogpeppemgz: +1 too (i'd be interested to know which bits you're thinking of particularly though)10:46
fwereademgz, this is why I'm so pissed off by MachineConfig in the first place10:47
fwereademgz, it takes all the totally generic scripts-we-must-run stuff and smooshes it into a cloudinit-specific form10:48
rogpeppefwereade: those scripts are generic enough to run under Windows? :-)10:48
mgzwell, what do we mean by windows?10:49
fwereaderogpeppe, at the moment we can't run the version of ubuntu we wanr10:49
mgzwe're a long, long way away from being able to use windows as a machine type in juju10:49
mgzbut that's not what we're talkinga about with azure10:49
rogpeppemgz: i though people were talking about "juju deploy activedirectory" as a possibility at some point10:49
mgzfor azure, we basically don't control boot, but can get our ubuntu machine, then access it and do stuff, which can still be cloudinit10:50
rogpeppes/though/thought/10:50
mgzI think "some point" should be clarified to not worrying about with detail design like this right now, it would entail changing... a great deal more than just this10:51
mgzfwereade: what's your branch, so I can catch up on the earlier discussion in the mp?10:52
fwereademgz, it's just a sketch, up at https://codereview.appspot.com/7396055/10:53
fwereademgz, sadly the discussion happened live10:53
mgzlive here, or live hangout? :)10:53
fwereademgz, hangout, I'm afraid10:53
mgzah well, add to the list for next week :)10:53
fwereademgz, as someone who came to the environs package cold, though, I would be very interested on your thoughts on that change10:55
rogpeppefwereade: i don't think that was the CL i had an issue with10:55
mgzhm, "error: old chunk mismatch"10:56
fwereaderogpeppe, crap, you're right10:56
fwereademgz, sorry, I have too many recent branches :/10:56
* fwereade goes digging10:56
rogpeppemgz: yeah, that happens. you can see the diffs though.10:56
rogpeppemgz: it'll be fixed if fwereade re-proposes10:56
mgzlaunchpad will save me10:56
fwereademgz, https://codereview.appspot.com/7394048/ -- and it does have some discussion10:57
rogpeppemgz: https://codereview.appspot.com/7396055/patch/1/610:57
fwereademgz, it is just a sketch, only proposed -wip10:57
mgzta10:58
rogpeppemgz: the thrust of my argument AFAIR was that factoring out this stuff was a good idea, but i think it would be better to take place under the umbrella of Bootstrap, rather than adding lots of cloudinit-related stuff to the environs.Environ interface.11:00
* rogpeppe goes back to trying to find that compiler bug11:01
davecheneyrogpeppe: is this in 1.0.3 or tip ?11:02
rogpeppedavecheney: tip11:02
davecheneyrogpeppe: already reported11:02
rogpeppedavecheney: have you narrowed it down?11:02
davecheneyhttps://code.google.com/p/go/issues/detail?id=493211:02
davecheneyhttps://code.google.com/p/go/source/detail?r=e73800eb2b0011:02
davecheneystay below this revision for the moment11:02
davecheneyor use hg revert11:03
davecheneyi'm setting up a jenkins build against tip to ensure we catch this faster11:03
davecheneysorry, hg undo11:03
rogpeppedavecheney: ah, cool. i was trying to reproduce by trial and error.11:03
rogpeppedavecheney: i'd found this:11:04
rogpeppefunc (@"".s·2 *@"".Settings "esc:0x0") @"".assertUnchangedOp () (? @"labix.org/v2/mgo/txn".Op) { return &@"labix.org/v2/mgo/txn".Op{ C:@"".s·2.@"".st.@"".settings.Name, Id:@"".s·2.@"".key, Assert:(@"".D{ 0x0:{ Name:"txn-revno", Value:@"".s·2.@"".txnRevno } }) } }11:04
rogpeppedavecheney: but couldn't reliably reproduce it in a small program11:04
davecheneyrogpeppe: ironically, the fix was for an issue which was almost identical https://code.google.com/p/go/issues/detail?id=487911:04
davecheneyrogpeppe: nah, we use almost every conceivable style and permutation allowed by the language11:05
rogpeppedavecheney: i narrowed it down quite a bit11:05
davecheneytry https://codereview.appspot.com/743704311:05
davecheneyok, jenkins biuld is setup11:07
davecheneybut is currently passing because r943 was rolled back11:07
rogpeppedavecheney: trying that CL11:08
rogpeppedavecheney: it sounds like they'd still benefit from a small test case11:08
davecheneyyeah, i agree, have a look at the 487911:09
davecheneythe test case for that might be some of the way there11:09
rogpeppedavecheney: that CL fixed the problem11:10
davecheneyrogpeppe: a test case would be useful11:13
davecheneyDmorsing was saying that the way composite literals work, stretches the meaning of work11:13
rogpeppedavecheney: how so?11:13
davecheney20:21 < DMorsing> davecheney, the biggest problem is that the compiler does a lot of work on the ast11:14
davecheney20:21 -!- fzzbt [~jahman@melkinpaasi.cs.helsinki.fi] has quit [Client Quit]11:14
davecheney20:22 -!- AnybodyElse [uid10067@gateway/web/irccloud.com/x-yvlsbbaerwtfivkb] has joined #go-nuts11:14
davecheney20:22 -!- fzzy [~jahman@melkinpaasi.cs.helsinki.fi] has joined #go-nuts11:14
davecheney20:22 -!- gsamat [~gsamat@broadband-188-32-17-124.nationalcablenetworks.ru] has quit [Quit: Computer has gone to sleep.]11:14
davecheney20:22 < DMorsing> and that either messes up later passes, or it messes up inlining because there isn't a proper representation of the post-processing AST11:14
fwereadedavecheney, tyvm11:17
davecheneyno worries11:17
davecheneyi've got a build setup now that watches juju tip and go tip for breakages11:18
davecheneynote: i am not running the tests (yet), just checking it compiles11:21
jammgz: poke11:32
mgzjam, a, hey11:37
jammgz: care to join us for mmubemboeumob ?11:37
mgztoo many things going on, have fled to the conservatory11:39
wallyworld_ian@wallyworld:~/.hpopenstack$ juju deploy mysql11:53
wallyworld_error: cannot get latest charm revision: charm info errors for "cs:quantal/mysql": entry not found11:53
rogpeppefwereade: have you looked at tim's latest CL? i'm not sure what i think - i'm interested in your reaction. https://codereview.appspot.com/737505312:04
fwereaderogpeppe, looking12:12
dimiternfwereade: done with standup, shall we g+?12:23
fwereadedimitern, ok, would you start one please?12:24
dimiternfwereade: https://plus.google.com/hangouts/_/5fb9c8fa96a6d9bc74de7a5f5cf171a04aeb0a40?authuser=0&hl=en12:24
jammgz, wallyworld_: https://code.launchpad.net/~jameinel/juju-core/only-943/+merge/15100512:52
wallyworld_jam: my rev's changes look like they're all there. thanks for doing that12:56
jamwallyworld_: np, if you can merge it and run the test suite quickly, it would help12:56
wallyworld_jam: hmmm. a failure, haven't looked yet.... PANIC: local_test.go:132: localServerSuite.SetUpTest13:01
jamwallyworld_: is it related to not enough bytes ?13:01
wallyworld_not sure, looking now13:01
=== gary_pos` is now known as gary_poster
jamwallyworld_: if you get a chance to paste the full traceback, please do so.13:02
wallyworld_jam: https://pastebin.canonical.com/85834/13:03
jamwallyworld_: that is the failure I'm working on in goose13:03
jaminteresting we've only seen it a couple times recently13:03
wallyworld_ah ok13:03
jamwe must be using a lot more random data.13:03
wallyworld_i'll rerun13:03
wallyworld_jam: all good this time13:05
fwereadejam, tyvm for reapplying those changes, if it's all passing it LGTM13:06
jamfwereade: thanks13:06
jamI've confirmed they pass here and for wallyworld_13:07
fwereadejam, <313:07
fwereadejam, btw, I have a vague recollection mramm was going to talk to you about tarmac for juju-core at one stage, but I never followed up on it13:07
jamfwereade: I actually have it set up as lp:~goose-bot/juju-core/trunk, but I wasn't sure how we wanted to actually coordinate the deployment.13:08
jamI wasn't going to push for it until I updated 'lbox submit --tarmac'13:08
jam(And it would currently be out of date)13:09
dimiternwallyworld_: I think such intermittent failures deserve a bug report13:10
fwereadedimitern, +113:10
jamdimitern: I have a patch submitted that you've reviewed for it, which is waiting for roger to approve13:10
jamso yes, we could have a bug, but we do have a fix13:10
dimiternjam: ah, that's your fix? ok13:10
dimiternjam: I though it's a new random thing13:10
jamwallyworld_: https://codereview.appspot.com/7375059/ is the one where fwereade is removing instanceid from being stored.13:11
jamdimitern: the panic is because random isn't giving enough data, and we end up with a nil somewhere.13:11
jamthe fix should prevent that.13:11
fwereadejam, what are your current priorities? is there anything we can downgrade in favour of getting reliable builds set up?13:11
wallyworld_jam: that's great. i'll look tomorrow13:12
jamfwereade: well next week is sprinting :).13:12
jamAnd it depends if you want to require lbox submit --tarmac, if you can live with the manual steps we do for goose, I can get it set up quite quickly.13:12
jamThe only remaining stuff is policy stuff13:12
jamdo we want trunk to be only accessible by the bot13:12
jamor should the bot just be in the group that can commit to it.13:13
fwereadejam, I'm pretty comfortable declaring anything with a pulse to be untrustworthy13:15
fwereadejam, it'd be a shame not to have submit --tarmac, but I guess the answer depends more on how many manual steps there are and how onerous they are13:16
jamfwereade: you need to copy the description in Launchpad to the commit message, and then mark the proposal approved.13:17
jam(tarmac uses Commit Message rather than description)13:17
fwereadejam, that feels like it could be pretty easily scriptable, right? so even if there's trouble getting it into lbox, we should still be able to reap the benefits13:18
fwereadejam, the other big thing IMO is that with tarmac, we could actually get away with running likley subsets of the tests13:18
fwereadejam, and *that* then means we could put the deps in the source tree and get repeatable builds13:20
fwereadejam, (nobody's thought of an alternative route to get that without dropping the go tools, right?)13:22
* rogpeppe goes for some lunch13:22
* fwereade pops out for 5 mins in the sun, then over to dimitern's place for state talks; see you all soon13:23
TheMuecu13:23
benji___There appears to be a sort-order test bug on trunk (http://paste.ubuntu.com/5573328/); is that something you guys want a bug filed for?13:35
=== benji___ is now known as benji
* benji snipps off his tail.13:35
dimiternbenji: can you file a quick bug report about it please?13:36
benjidimitern: will do13:37
dimiternbenji: today everything breaks it seems13:37
benji:)13:37
benjidimitern: https://bugs.launchpad.net/juju-core/+bug/113575713:40
_mup_Bug #1135757: List order test bug in launchpad.net/juju-core/environs/openstack <juju-core:New> < https://launchpad.net/bugs/1135757 >13:40
dimiternbenji: cheers!13:40
dimiternbenji: yeah, it seems that's related to ian's list prefix change13:42
dimiternbenji: strange, I'm not getting it on tip - are you sure you've updated goose before?13:47
dimiternfwereade is here now13:48
benjidimitern: nope, I have not, let me try that real quick13:49
jamdimitern: did you manage to countersign your objectives? HR is asking me to do the final signoff.14:20
jamdimitern: https://allhands.canonical.com/hra-space/portal/root/employee14:21
dimiternjam: oh, you wrote here - yes I did14:21
jamI know you did the submission, there is a countersign step that has to happen after mine.14:22
jamI'm guessing you did it, but I want to make sure before I tell them.14:22
jamdimitern: ^14:22
dimiternjam: I double checked - there's no more to do on that page, tell me if I missed something. I just selected I agree + submit14:25
dimiternbenji: did you manage to get the test pass?\14:25
jamif there aren't any tasks, then I don't see anything to do either.14:25
benjidimitern: let me check the test run...14:27
dimiternjam: yeah, i had to go to the archives page to see the countersign task14:27
benjiit worked!  I guess that's something I need to internaize.14:27
* benji writes "go get -u when you see test failures" 100 times on the blackboard14:27
benjiIt would be really nice if there were dependency management in place so a human didn't have to do that sort of thing.14:28
dimiternbenji: cheers! please update the bug14:28
benjidimitern: done14:30
* rogpeppe is back14:41
TheMuerogpeppe: Do you know if we meet in 10 minutes? Or only this evening? I have to step out now to fetch my daughter. Today I'm the driver. ;)14:51
rogpeppeTheMue: i'm not sure. i *presume* only this evening. mramm?14:52
niemeyerYo all!14:52
niemeyermthaddon: ping14:52
rogpeppeniemeyer: hiya!14:52
TheMueniemeyer: Hi.14:52
mthaddonniemeyer: pings with content save time :)14:52
niemeyermthaddon: https://portal.admin.canonical.com/5971214:53
mthaddonniemeyer: cool, thx, we'll get it done soon - is there a particular deadline for it, or just "sooner the better"?14:53
niemeyermthaddon: I generally like to say "Hi, how's life been since we last deployed it?", but alright :)14:53
mthaddonheh14:53
* TheMue is AFK, BIAB14:53
niemeyermthaddon: There's no deadline, but sooner the better indeed14:54
niemeyermthaddon: There's a new stats feature14:54
niemeyermthaddon: Can't see that data while it doesn't land14:54
mthaddonniemeyer: ok, thx14:54
niemeyerrogpeppe, TheMue: Yos14:54
mrammrogpeppe: TheMue: yea, just the evening meeting is fine14:55
mthaddonniemeyer: the RT mentions revno 945 - is 949 okay (our scripts pull tip by default)?14:58
niemeyermthaddon: Yeah, it's okay14:58
mthaddonthx14:58
mthaddonniemeyer: done14:59
=== wedgwood_away is now known as wedgwood
niemeyermthaddon: Sweet! Let me test it15:00
niemeyermthaddon: WORKS!15:00
mthaddongood good15:01
niemeyermthaddon: Thanks much15:01
mthaddonnp15:01
fwereademramm, TheMue, rogpeppe: kanban?15:04
mrammfwereade: we decided to only do the one this evening15:04
fwereademramm, ah!15:04
fwereademramm, good point15:05
fwereademramm, ok then :)15:05
fwereadeknocking off now, we've got the call later16:52
niemeyerfss: ping17:59
bachi rogpeppe, would you time to do a second review for me?18:32
rogpeppebac: sure18:32
rogpeppebac: link?18:32
baccool, i hope you're not EOD18:32
bacrogpeppe: https://codereview.appspot.com/7369058/18:32
rogpeppebac: normally yes, but today i'm working later18:32
rogpeppebac: reviewed18:42
=== deryck is now known as deryck[lunch]
bacrogpeppe: thank.  looking at it now18:53
niemeyerfss: pingous?20:09
=== deryck[lunch] is now known as deryck
=== _thumper_ is now known as thumper
fssniemeyer: hi21:02
niemeyerfss: Heya.. you've got reviews21:02
niemeyerfss: Great stuff.. just trivial comments21:02
fssniemeyer: I'm lbox proposing group changes right now :-)21:03
niemeyerfss: Sweet21:03
fssniemeyer: regarding the message returned by amazon, that's the message21:03
fssniemeyer: should I use %q anyway?21:04
rogpepperight, i'm off for the night. see y'all tomorrow.21:06
niemeyerfss: Does it include quotes around the name or not?21:21
=== thumper is now known as thumper-afk
jcastromramm: around?23:04
=== wedgwood is now known as wedgwood_away
=== wedgwood_away is now known as wedgwood
mrammjcastro: I am now23:12
jcastrogot time for a quick G+?23:16
jcastro2 minutes, I promise!23:16
jcastromramm: https://plus.google.com/hangouts/_/097d689c217f97e00665bff91bac17fd9b78e439?authuser=0&hl=en23:16
=== wedgwood is now known as wedgwood_away
mrammjcastro, sorry I missed you...23:55
jcastrono worries23:58
jcastronext time23:58

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