[00:05] davecheney: bug 1134959 [00:05] <_mup_> Bug #1134959: worker/uniter: multiple test failures < https://launchpad.net/bugs/1134959 > [00:16] davecheney: aroun? [00:16] around, that is :-) [00:24] arosales: two secs [00:24] still on the phone [00:24] thumper: thanks [00:25] davecheney: thanks [00:30] davecheney: when you are free I am using a the following for hpcloud in the environments.yaml file: http://pastebin.ubuntu.com/5572190/ [00:31] and I am getting the error error: secret-key: expected nothing, got "" === wedgwood is now known as wedgwood_away [00:38] davecheney: I have tried variations of adding in "tenant-name" and "region" with no sucess [00:38] *success, that is. [00:39] I did get AWS to bootstrap though and deploy wordpress/mysql [00:41] arosales: just finishing up [00:44] arosales: tip: remove secret key [00:44] it isn't used in our juju [00:44] i think it was optional in 0.6 [00:45] access key too? [00:45] arosales: I usually let those flow through from sourceing .novarc [00:45] davecheney: I am not sourcing a novarc file [00:46] so I think I need them somewhere [00:48] davecheney: 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] its just hpcloud environments.yaml file that is giving me guff. [00:49] arosales: ok, you have my complete attention :) [00:49] :-) [00:50] tldr I can't get hpcloud environment.yaml to work with go-juju [00:50] i've only tested against canonistack, and I let the valyes flow throught from sourceing my .novarc [00:50] my env.yaml for hpcloud is @ http://pastebin.ubuntu.com/5572190/ [00:50] lets see what I am missing [00:50] arosales: if you have the latest go juju you can run "juju generate-config" and it will give you a boilerplate file [00:50] wallyworld_: thanks, I also tried using that template [00:51] ^ what wallyworld said [00:51] but no go [00:51] you should just havve needed to change the auth url [00:51] worked for me anyway [00:51] wallyworld_: and add in my credentials [00:51] what version of juj you running? [00:51] wallyworld_: I agree, but alas no bootstrap [00:51] arosales: i just source a nova rc for that so they come from env vars [00:52] wallyworld_: 1.9.9-2~923~quantal1 [00:52] ok, latest version then [00:52] wallyworld_: davecheney: so it is a requiment to source a novarc then? [00:52] and if not get breakage? [00:53] no, but if not, you need to have env vars set or edit the yaml [00:53] arosales: sorry, you've probably done this already, can you paste the output when you do [00:53] juju bootstrap --debug -e '$YOURENV' [00:53] wallyworld_: I got those creds in the yaml directly [00:53] ok [00:53] you can use paste.canonical.com for more private stuff [00:53] incl region and tenant etc? [00:54] let me sanitize the output real quick [00:55] davecheney: [00:55] $ juju --debug bootstrap -e hpcloud [00:55] 2013/02/27 18:53:59 JUJU environs/openstack: opening environment "hpcloud" [00:55] 2013/02/27 18:53:59 JUJU juju bootstrap command failed: secret-key: expected nothing, got "" [00:55] error: secret-key: expected nothing, got "" [00:56] remove the secret-key line from your enviornment.yaml [00:56] you may have to remove others [00:56] arosales: can you pastebin your yaml - it seems out of date [00:56] did generate-config generate this config ? [00:56] or is this an old one that used to work with 0.6 [00:56] davecheney: if I remove the secret key how do I authenticate? [00:56] secret-key is a noop in our juju [00:56] wallyworld_: http://pastebin.ubuntu.com/5572190/ is my latest env.yaml I made from the boilerplate [00:57] arosales: you sure? [00:57] davecheney: I tried my config from juju-py and it didn't work so I tried with the boilerplate [00:57] wallyworld_: yes :-) [00:57] ah ok, did you replace the admin-secrect with redacted? [00:57] wallyworld_: I am crazy most the time, but I just did this ;-) [00:58] it should have been a random nmber of sorts [00:58] wallyworld_: correct, I don't want to post my keys in the public ;-) [00:58] wallyworld_: I did get aws bootstraped, just hp giving me issues. [00:58] auth mode should be userpass i think [00:58] arosales: go juju does not use the secret-key configuration item [00:59] you have to remove it [00:59] wallyworld_: for authmod = keypass ? [00:59] arosales: i don't thikn goose supports that either [00:59] the only methods it supports is legacy and userpadd [00:59] userpass [00:59] arosales: what i meant before was that i think an earlier version of the boilerplate did have "redacted" in it [00:59] davecheney: so this is a bug then [00:59] davecheney: 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.yaml [01:00] arosales: authmode should be userpass [01:00] correct? [01:00] keypair is not supported yet [01:00] for openstack [01:00] really? [01:00] :-( [01:00] not a bug, just not supported [01:00] most folks use keys [01:00] bug for 13.04 by default [01:00] at lest in my opinion [01:00] arosales: I will raise a bug [01:00] you are correct [01:00] the way the configuration works is [01:01] most items in ~/.juju/environments.yaml [01:01] davecheney: I can open the bug, I just wan't sure if it was pilot error [01:01] arosales: its just that we have not ad the resources to get to it yet [01:01] will take values from ENV values if they are missing from the yaml file [01:01] wallyworld_: understood, I just wanted to ask more folks to use go-juju and ran into this [01:02] should be noted in the release notes. [01:02] under known bugs [01:02] arosales: I will make sure it is noted in the next release notes [01:02] userpass works ok with hpcloud :-) [01:02] wallyworld_: ok, I"ll give that a try later tonight [01:02] wallyworld_: davecheney thanks for the help [01:02] davecheney: would you like me to open the bug [01:02] hence we needed to get other stuff working first :-) [01:03] arosales: yes please [01:03] davecheney: will do [01:03] I'll get that logged later tonight. [01:03] * arosales needs to attend to some daddy duty [01:03] 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 sorted [01:03] ah, ok [01:03] * davecheney thinks he knows what that one is :) [01:04] wallyworld_: could you give me a ping when that lands in the ppa? [01:04] or even to the juju list would be better [01:04] arosales: sorry :-( still a work in progress, trying to get it done asap [01:04] arosales: sure, no problem. aiming for next release hopefully [01:04] arosales: there is a juju-core-daily ppa [01:04] wallyworld_: thanks [01:04] which you can use if you're super keen [01:04] arosales: thanks for your patience also, and sorry for the issues [01:04] davecheney: I may have to use that to get the fix [01:05] wallyworld_: no worries part of trying out bleeding edge :-) [01:05] thats part of the fun right? [01:05] oh yes, very bleeding right now [01:05] * arosales has to run [01:05] later fellas [01:05] be back online later tonight though [01:05] thanks again [01:05] ok, see ya === arosales is now known as arosales-afk [01:05] arosales: thanks for being a beta tester, i'll buy you a chocolate or a teddy bear in Altanta as a boobie prize [01:06] davecheney: so about that mp.... [01:06] wallyworld_: sorry, a lot has scrolled off the screen [01:06] yeah :-) np [01:07] [09:53:17] davecheney: hi, a quick clarification on your concern about returning an unexported error [01:07] [09:53:38] i coped the pattern used already in the state package for notFoundError [01:07] [09:54:25] i guess the original author didn't want people to access anything other than Error() ? [01:07] [09:55:24] 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] ahh,yes [01:07] sorry [01:07] np [01:07] ok, as I understand it [01:07] if you return a private type, with a public Error method [01:07] that satisfied the error interface [01:08] but callers may not be able to use a type asserting to tell what kind of error it is [01:08] davecheney: there's a helper mthod for that [01:08] IsNotFound() [01:08] IsUNauthorised() [01:08] having said that, it looks like the method was doing the wrong thing [01:08] in 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 information [01:09] maybe in return you could replace the text with a hint to pass the error to IsNotFound(err) [01:09] that was all I ways saying in that comment [01:09] returning unexported errors is something that gets on peoples' goat in the stdlibrary [01:09] for example, errClosing [01:10] 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 notFounfError [01:10] so i was going for consistency [01:11] ok, lemmie review again, if you've already got 2 LGTM, then don't wait for me [01:11] 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 before [01:12] i assumed that it was done the right way previously for notFound [01:12] ok, bio break, then review [01:12] davecheney: ok, i have to run an errand, back in a bit and will look [02:17] wallyworld_: re your CL [02:17] the previous type, ErrUnauthorized was exported [02:18] i'll put my comments in the review [02:46] davecheney: it was, but only because it was a var. the other error commonly used in state package, notFoundError, was not exported. [02:46] the implementation has changed from a var to a type, and there's a helper method used to discriminate the error type [02:47] there already is a helper method in the MP too - IsUnauthorised() [02:48] so, i'll add the comment as requested. thanks for looking [02:49] wallyworld_: SGTM, either of those choices is fine [02:49] ok, np. thanks. i just wanted to be 100% sure you were happy [02:49] no, thakn you [02:50] this isn't the end of the world [02:50] but its nice to go the extra mile [02:50] there's a fair bit of inconsistency in places [02:50] and then it gets cargo culted [02:50] do you want to raise an issue for the worst offenders [02:50] otherwise i fear they may never be addressed [02:51] * davecheney appologises for sounding like a issue whoring broken record [02:51] i used to work for an issue tracker company [02:51] i have no real concrete examples - but as i find them again i should keep a list [02:51] it's just a general perception [02:51] and it was beaten into me that if there was no issue, it didn't happen [02:51] yeah agreed [02:51] i'd like it if you kept that list in an issue [02:51] or at a minimum google docs [02:51] sure. [02:51] on your own workstation isn't helpful [02:52] some of it could be contentious eg error handling [02:52] i have a philosophical difference in opinion with a few others i think [02:53] even more reason to flush it out into the open [02:53] a list also would determine if my perceptions are real [02:53] perhaps there's not much to it [02:55] * davecheney shrugs [02:55] i dunno how much there is [02:55] but setting a precident now is important [03:09] thumper: excellent proposal [03:09] i was going to propose something like that myself [03:09] davechen1y: I was just about to ping you about it :) [03:09] just a little editing and the help one is following [03:14] thumper https://bugs.launchpad.net/juju-core/+bug/1134959 [03:14] <_mup_> Bug #1134959: worker/uniter: multiple test failures < https://launchpad.net/bugs/1134959 > [03:15] how come I didn't get a notification about this one ? [03:15] i'm listed as the bugmaster on this project [03:15] or, to put it another way [03:15] how can I change things so I get all notificatoins for all bugs on juju-core [03:15] I'm not sure... [03:15] you should have [03:15] sure you don't have some weird ass email rules? [03:15] i have no email rules [03:15] i hate thunderbird so much [03:16] i'm not going to give it the satisfactoin of asking it to take on more responsibility [03:17] ok, think I fixed it [03:17] i was sure the entire gophers team was subscribed [04:40] thumper: do you have a copy of juju tools for precise compiled from tip you can share with me? [04:42] actually, never mind, found some i think [05:19] wallyworld_: question for you if you are free [05:19] sure [05:26] wallyworld_: are there any other package requirements for running go-juju other than juju-core? [05:27] I retract that question I was able to get AWS deployed, so I think I have the requirements meet [05:27] \o/ [05:27] hp still giving me some issues [05:27] yeah, i found problems with jujud and other things, working on fixing now. sadly, hp cloud runs a different version to canonistack = problems [05:29] wallyworld_: any idea what this error means [05:29] 2013/02/27 23:29:06 JUJU juju bootstrap command failed: cannot find tools: no compatible tools found [05:30] arosales: you need to specify --upload-tools when using bootstrap as there is no well defined public bucket yet like for ec2 [05:30] so for now, when testing, we just upload our own copy [05:31] there will ultimately need to be a public place where the tools tarball lives which everyone shares [05:32] wallyworld_: is there a test bucket I can use? [05:33] I am thinking I need to state something to the effect "juju --upload-tools bootstrap -e hpcloud" [05:33] not that has been setup. if you use --upload-tools, it just puts a copy in your control bucket, around 2Mb i think [05:33] just "juju bootstrap --upload-tools -e hpcloud" [05:34] if you specify a public bucket url in your yaml, it will use that [05:34] but that implies the tools have been pre-uploaded separately [05:34] which we will do at some point [05:34] and publicise the public bucket url, like for ec2 [05:35] but for now, the above bootstrap command does the job [05:35] bear in mind, bootstrap will fail for other reasons, currently being fixed [05:35] gotcha [05:35] interesting how this didn't parse [05:36] $ juju --debug --upload-tools bootstrap -e hpcloud [05:36] error: flag provided but not defined: --upload-tools [05:36] but you way did [05:36] maybe that neds to go at the end [05:36] ? [05:36] yup, worked when I did it your way, odd it parsed it correctly when at the end [05:36] yeah, odd i agree [05:36] so it looks like I need have Go in my path? [05:36] error: cannot upload tools: build command "go" failed: exec: "go": executable file not found in $PATH; [05:37] 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 bucket [05:38] you running precise or qantal? [05:38] quantal [05:38] http://juju-dist.s3.amazonaws.com/tools/juju-1.9.9-precise-amd64.tgz [05:38] sorry, subst quantal in there [05:39] upload the tarball to a tools dir in your control bucket [05:39] in the gophers ppa I see "golang-stable" and "cobzr" do I need those? [05:41] cobzr is for if you are doing devel work [05:41] golang is Go itself [05:47] * arosales looking for hp cloudcontrol bucket . . . [05:48] arosales: i think i had to create mine manually, using the yaml control bucket vaue as the name [05:48] if you tried bootstrap once, it may have made it for you already though [05:49] wallyworld_: I should see that in the object store for region 1, correct? [05:49] depends on the region in your yaml but yes [05:50] it is for me [05:50] ah yes, given I am trying to work in region 1 [05:51] I don't see one there so sounds like I need to make one with the name in my env.yaml [05:51] arosales: fyi, my control bucket is juju-e802cb1c2e3ab47e3e4a1071cef25a9c [05:51] you may be able to see that one [05:53] depending on your credentials [05:55] * arosales uploading . . . [05:59] hrm, still getting the cannot upload tools error [05:59] http://pastebin.ubuntu.com/5572611/ [06:01] * wallyworld_ looks [06:02] arosales: unless you have the dev stuff installed locally, you need to upload manually the tarball and bootstrap without the upload tools flag [06:02] upload-tools is more of a dev option [06:03] ok, I uploaded manually so I'll drop the upload-tools option [06:05] wallyworld_: closer, but still not finding the tools [06:05] http://pastebin.ubuntu.com/5572619/ [06:06] arosales: you uploaded quantal tools right? check you yaml and see if there is a default-series value in there [06:06] if it says precise, you need to comment it out [06:07] you also need to change the image id to a quantal one [06:07] and 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 it [06:07] 75839 from memory [06:07] oh, so you have uploaded a precise tarball? [06:07] i thought you were running quantal? [06:07] I do have default-series: precise in my env.yaml but my client is quantal [06:07] do they need to match [06:07] no [06:08] as long as default-series = tools tarball = image type you should be ok [06:08] correct I uploaded the precise tar file when I noticed my yaml had the default series for precise [06:09] hmmm. not sure why it is complaining. did you upload tarbal to a tools container in the bucket? [06:10] ah I don't have it under a tools dir [06:10] that would do it [06:13] wallyworld_: nice catch on the missing tools dir, my bad. That does get me closer [06:13] http://pastebin.ubuntu.com/5572624/ [06:13] looks like it has m1.small [06:14] I think for HP that needs to be standard.small, right? [06:14] arosales: yeah, that has been changed, but may have missed the 1.9.9 release [06:14] you now specify the flavour in the yaml [06:15] using default-instance-type [06:15] via default-instance-type: standard.small [06:15] ok [06:15] but it may not be in the 1.9.9 release [06:15] that is deprecated btw, until we get constrainst further progressed [06:16] seem it didn't like that yaml parameter [06:16] http://pastebin.ubuntu.com/5572629/ [06:16] I can untar the precise yaml and correct [06:17] arosales: the code to process it may not have made the 1.9.9 release [06:17] so you might be out of luck until the next drop [06:17] ah there is just an executable in that tar file [06:18] yes, jujud [06:18] ya looks to be that way [06:18] :-( [06:18] sorry [06:18] so close but yet so far [06:18] go juju works for ec2 [06:18] we wanted to try some scale testing on HP [06:18] close for openstack, but we only *just* finished the core code and are sorting out the final bits and oieces [06:19] i'm really hopeful we'll be there for next release [06:21] Looks like 1.9.10 is expected on march 9 if all goes well [06:22] wallyworld_: 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 ready [06:23] wallyworld_: would you suggest I use the daily ppa? [06:24] 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 right [06:24] s/i/it [06:24] you still won't be able to get a system fully working though [06:24] still some more things to sort out [06:25] ok, perhaps it is best to wait for 1.9.10 then [06:25] btw, do you have a pointer to the daily? [06:25] not handy but i can find it [06:29] arosales: https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily [06:29] from there you can grab the one you want [06:31] wallyworld_: thanks for link, and thanks again for your time to help me step through the openstack setup for HP. Much appreciated [06:31] no problem at all, please to help. [06:31] hopefully next time we talk thiings will be working :-) [06:32] wallyworld_: do you want me to open up a bug on the control file needing updated to have standard.small? [06:32] arosales: no, already fixed :-) [06:32] just not in the release yet [06:32] ok [06:33] gotcha, enjoy the rest of your day. [06:34] you too, almost wine o'clock here :-D [06:39] nice [06:45] I 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 . . . [07:02] correct [07:03] but you can get one from ec2 [07:03] no [07:03] i don't think we upload the daily tarballs [07:50] yup, I didn't see one on ec2 with the urls I tried. have a good evening wallyworld_ ttyl [08:11] morning gents [08:12] I am reverting to r942, because r943 and all following were committed with failing tests [08:12] fwereade: morning [08:13] dimitern, heyhey [08:13] dimitern, I has a grumpy: please run the full test suite before you submit [08:13] fwereade: I saw that bug report about failing uniter tests [08:13] fwereade: I *did* several times! [08:13] dimitern, frankly, please run it before yu even propose [08:13] dimitern, hm, that is odd then [08:13] fwereade: I always do [08:14] really odd [08:14] dimitern, 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 wrong [08:15] fwereade: ok, I'll investigate what went wrong [08:15] mornin' all [08:15] rogpeppe: hiya [08:15] fwereade: yeah, i get a compilation failure in trunk [08:16] rogpeppe, a *compilation* failure? goose maybe? [08:16] rogpeppe: where? [08:16] fwereade, dimitern: it's pretty weird actually: [08:16] state/assign_test.go:5: cannot use &txn.Op literal (type *txn.Op) as type txn.Op in return argument [08:17] but that's on an import statement [08:17] rogpeppe: hmm [08:17] i'll blow away $GOPATH/pkg and see if it still happens [08:17] rogpeppe, huh, I didn't see that myself :/ [08:17] rogpeppe: what did you run? [08:17] dimitern: go test ./... [08:17] dimitern: in juju-core root [08:17] dimitern, rogpeppe: for form's sake, can I get a quick check of https://codereview.appspot.com/7422044 [08:18] fwereade: I run go test -i ./... && go test ./... in worker/uniter several times when I was changing the uniter tests (to compare timings) - all was fine [08:18] fwereade: I'm on it [08:19] dimitern, you didn't change the uniter tests in r943 -- that was the SetCharm branch [08:19] fwereade: hmm [08:20] fwereade: 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 fine [08:21] dimitern, IMO we should *always* be running the full test suite before we commit (really, before we propose) [08:21] fwereade: +1 [08:22] fwereade: go test ./... in juju-core/ you mean? [08:22] dimitern, we changed behavior in state -- anything that uses state *might* have been depending on something we changed [08:22] dimitern, yeah [08:22] fwereade: we should probably be running the live tests actually. [08:22] fwereade: ok, sorry, I promise I'll do that from now on [08:22] dimitern, thanks :) [08:23] rogpeppe, hmm, what's the point of the double then? [08:23] fwereade: i guess all my changes before were isolated enough so running the tests for what I changed was good enough [08:23] rogpeppe, if the double can't tell us when we've broken things I question its value [08:23] fwereade: it means that you get *some* confidence. but it doesn't run all the agents. [08:23] dimitern, it's a tempting idea, but it has a tendency to bite one in the ass ;) [08:24] rogpeppe: I have this failure in rpc: http://paste.ubuntu.com/5572797/ [08:24] dimitern: can you reproduce it (it works ok for me) [08:24] ? [08:25] rogpeppe: I just ran all tests (still running) [08:25] fwereade: that compilation failure only happens against go tip. something weird's up. [08:26] fwereade: i suspect a inlining bug [08:26]