| thumper | davecheney: bug 1134959 | 00:05 |
|---|---|---|
| _mup_ | Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 > | 00:05 |
| arosales | davecheney: aroun? | 00:16 |
| arosales | around, that is :-) | 00:16 |
| davecheney | arosales: two secs | 00:24 |
| davecheney | still on the phone | 00:24 |
| davecheney | thumper: thanks | 00:24 |
| arosales | davecheney: thanks | 00:25 |
| arosales | davecheney: when you are free I am using a the following for hpcloud in the environments.yaml file: http://pastebin.ubuntu.com/5572190/ | 00:30 |
| arosales | and I am getting the error error: secret-key: expected nothing, got "<redacted>" | 00:31 |
| === wedgwood is now known as wedgwood_away | ||
| arosales | davecheney: I have tried variations of adding in "tenant-name" and "region" with no sucess | 00:38 |
| arosales | *success, that is. | 00:38 |
| arosales | I did get AWS to bootstrap though and deploy wordpress/mysql | 00:39 |
| davecheney | arosales: just finishing up | 00:41 |
| davecheney | arosales: tip: remove secret key | 00:44 |
| davecheney | it isn't used in our juju | 00:44 |
| davecheney | i think it was optional in 0.6 | 00:44 |
| arosales | access key too? | 00:45 |
| davecheney | arosales: I usually let those flow through from sourceing .novarc | 00:45 |
| arosales | davecheney: I am not sourcing a novarc file | 00:45 |
| arosales | so I think I need them somewhere | 00:46 |
| arosales | 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 |
| arosales | its just hpcloud environments.yaml file that is giving me guff. | 00:48 |
| davecheney | arosales: ok, you have my complete attention :) | 00:49 |
| arosales | :-) | 00:49 |
| arosales | tldr I can't get hpcloud environment.yaml to work with go-juju | 00:50 |
| davecheney | i've only tested against canonistack, and I let the valyes flow throught from sourceing my .novarc | 00:50 |
| arosales | my env.yaml for hpcloud is @ http://pastebin.ubuntu.com/5572190/ | 00:50 |
| davecheney | lets see what I am missing | 00:50 |
| wallyworld_ | arosales: if you have the latest go juju you can run "juju generate-config" and it will give you a boilerplate file | 00:50 |
| arosales | wallyworld_: thanks, I also tried using that template | 00:50 |
| davecheney | ^ what wallyworld said | 00:51 |
| arosales | but no go | 00:51 |
| wallyworld_ | you should just havve needed to change the auth url | 00:51 |
| wallyworld_ | worked for me anyway | 00:51 |
| arosales | wallyworld_: and add in my credentials | 00:51 |
| wallyworld_ | what version of juj you running? | 00:51 |
| arosales | wallyworld_: I agree, but alas no bootstrap | 00:51 |
| wallyworld_ | arosales: i just source a nova rc for that so they come from env vars | 00:51 |
| arosales | wallyworld_: 1.9.9-2~923~quantal1 | 00:52 |
| wallyworld_ | ok, latest version then | 00:52 |
| arosales | wallyworld_: davecheney: so it is a requiment to source a novarc then? | 00:52 |
| arosales | and if not get breakage? | 00:52 |
| wallyworld_ | no, but if not, you need to have env vars set or edit the yaml | 00:53 |
| davecheney | arosales: sorry, you've probably done this already, can you paste the output when you do | 00:53 |
| davecheney | juju bootstrap --debug -e '$YOURENV' | 00:53 |
| arosales | wallyworld_: I got those creds in the yaml directly | 00:53 |
| wallyworld_ | ok | 00:53 |
| davecheney | you can use paste.canonical.com for more private stuff | 00:53 |
| wallyworld_ | incl region and tenant etc? | 00:53 |
| arosales | let me sanitize the output real quick | 00:54 |
| arosales | davecheney: | 00:55 |
| arosales | $ juju --debug bootstrap -e hpcloud | 00:55 |
| arosales | 2013/02/27 18:53:59 JUJU environs/openstack: opening environment "hpcloud" | 00:55 |
| arosales | 2013/02/27 18:53:59 JUJU juju bootstrap command failed: secret-key: expected nothing, got "<redacted>" | 00:55 |
| arosales | error: secret-key: expected nothing, got "<redacted>" | 00:55 |
| davecheney | remove the secret-key line from your enviornment.yaml | 00:56 |
| davecheney | you may have to remove others | 00:56 |
| wallyworld_ | arosales: can you pastebin your yaml - it seems out of date | 00:56 |
| davecheney | did generate-config generate this config ? | 00:56 |
| davecheney | or is this an old one that used to work with 0.6 | 00:56 |
| arosales | davecheney: if I remove the secret key how do I authenticate? | 00:56 |
| davecheney | secret-key is a noop in our juju | 00:56 |
| arosales | wallyworld_: http://pastebin.ubuntu.com/5572190/ is my latest env.yaml I made from the boilerplate | 00:56 |
| wallyworld_ | arosales: you sure? | 00:57 |
| arosales | davecheney: I tried my config from juju-py and it didn't work so I tried with the boilerplate | 00:57 |
| arosales | wallyworld_: yes :-) | 00:57 |
| wallyworld_ | ah ok, did you replace the admin-secrect with redacted? | 00:57 |
| arosales | wallyworld_: I am crazy most the time, but I just did this ;-) | 00:57 |
| wallyworld_ | it should have been a random nmber of sorts | 00:58 |
| arosales | wallyworld_: correct, I don't want to post my keys in the public ;-) | 00:58 |
| arosales | wallyworld_: I did get aws bootstraped, just hp giving me issues. | 00:58 |
| wallyworld_ | auth mode should be userpass i think | 00:58 |
| davecheney | arosales: go juju does not use the secret-key configuration item | 00:58 |
| davecheney | you have to remove it | 00:59 |
| arosales | wallyworld_: for authmod = keypass ? | 00:59 |
| davecheney | arosales: i don't thikn goose supports that either | 00:59 |
| davecheney | the only methods it supports is legacy and userpadd | 00:59 |
| davecheney | userpass | 00:59 |
| wallyworld_ | arosales: what i meant before was that i think an earlier version of the boilerplate did have "redacted" in it | 00:59 |
| arosales | davecheney: so this is a bug then | 00:59 |
| arosales | 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 | 00:59 |
| wallyworld_ | arosales: authmode should be userpass | 01:00 |
| arosales | correct? | 01:00 |
| wallyworld_ | keypair is not supported yet | 01:00 |
| wallyworld_ | for openstack | 01:00 |
| arosales | really? | 01:00 |
| arosales | :-( | 01:00 |
| wallyworld_ | not a bug, just not supported | 01:00 |
| arosales | most folks use keys | 01:00 |
| arosales | bug for 13.04 by default | 01:00 |
| arosales | at lest in my opinion | 01:00 |
| davecheney | arosales: I will raise a bug | 01:00 |
| davecheney | you are correct | 01:00 |
| davecheney | the way the configuration works is | 01:00 |
| davecheney | most items in ~/.juju/environments.yaml | 01:01 |
| arosales | davecheney: I can open the bug, I just wan't sure if it was pilot error | 01:01 |
| wallyworld_ | arosales: its just that we have not ad the resources to get to it yet | 01:01 |
| davecheney | will take values from ENV values if they are missing from the yaml file | 01:01 |
| arosales | wallyworld_: understood, I just wanted to ask more folks to use go-juju and ran into this | 01:01 |
| arosales | should be noted in the release notes. | 01:02 |
| arosales | under known bugs | 01:02 |
| davecheney | arosales: I will make sure it is noted in the next release notes | 01:02 |
| wallyworld_ | userpass works ok with hpcloud :-) | 01:02 |
| arosales | wallyworld_: ok, I"ll give that a try later tonight | 01:02 |
| arosales | wallyworld_: davecheney thanks for the help | 01:02 |
| arosales | davecheney: would you like me to open the bug | 01:02 |
| wallyworld_ | hence we needed to get other stuff working first :-) | 01:02 |
| davecheney | arosales: yes please | 01:03 |
| arosales | davecheney: will do | 01:03 |
| arosales | I'll get that logged later tonight. | 01:03 |
| * arosales needs to attend to some daddy duty | 01: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 sorted | 01:03 |
| arosales | ah, ok | 01:03 |
| * davecheney thinks he knows what that one is :) | 01:03 | |
| arosales | wallyworld_: could you give me a ping when that lands in the ppa? | 01:04 |
| arosales | or even to the juju list would be better | 01:04 |
| wallyworld_ | arosales: sorry :-( still a work in progress, trying to get it done asap | 01:04 |
| wallyworld_ | arosales: sure, no problem. aiming for next release hopefully | 01:04 |
| davecheney | arosales: there is a juju-core-daily ppa | 01:04 |
| arosales | wallyworld_: thanks | 01:04 |
| davecheney | which you can use if you're super keen | 01:04 |
| wallyworld_ | arosales: thanks for your patience also, and sorry for the issues | 01:04 |
| arosales | davecheney: I may have to use that to get the fix | 01:04 |
| arosales | wallyworld_: no worries part of trying out bleeding edge :-) | 01:05 |
| arosales | thats part of the fun right? | 01:05 |
| wallyworld_ | oh yes, very bleeding right now | 01:05 |
| * arosales has to run | 01:05 | |
| arosales | later fellas | 01:05 |
| arosales | be back online later tonight though | 01:05 |
| arosales | thanks again | 01:05 |
| wallyworld_ | ok, see ya | 01:05 |
| === arosales is now known as arosales-afk | ||
| davecheney | arosales: thanks for being a beta tester, i'll buy you a chocolate or a teddy bear in Altanta as a boobie prize | 01:05 |
| wallyworld_ | davecheney: so about that mp.... | 01:06 |
| davecheney | wallyworld_: sorry, a lot has scrolled off the screen | 01:06 |
| wallyworld_ | yeah :-) np | 01:06 |
| wallyworld_ | [09:53:17] <wallyworld_> davecheney: hi, a quick clarification on your concern about returning an unexported error | 01:07 |
| wallyworld_ | [09:53:38] <wallyworld_> i coped the pattern used already in the state package for notFoundError | 01: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 |
| davecheney | ahh,yes | 01:07 |
| davecheney | sorry | 01:07 |
| wallyworld_ | np | 01:07 |
| davecheney | ok, as I understand it | 01:07 |
| davecheney | if you return a private type, with a public Error method | 01:07 |
| davecheney | that satisfied the error interface | 01:07 |
| davecheney | but callers may not be able to use a type asserting to tell what kind of error it is | 01:08 |
| wallyworld_ | davecheney: there's a helper mthod for that | 01:08 |
| wallyworld_ | IsNotFound() | 01:08 |
| wallyworld_ | IsUNauthorised() | 01:08 |
| davecheney | having said that, it looks like the method was doing the wrong thing | 01:08 |
| davecheney | 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:08 |
| davecheney | maybe in return you could replace the text with a hint to pass the error to IsNotFound(err) | 01:09 |
| davecheney | that was all I ways saying in that comment | 01:09 |
| davecheney | returning unexported errors is something that gets on peoples' goat in the stdlibrary | 01:09 |
| davecheney | for example, errClosing | 01: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 notFounfError | 01:10 |
| wallyworld_ | so i was going for consistency | 01:10 |
| davecheney | ok, lemmie review again, if you've already got 2 LGTM, then don't wait for me | 01: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 before | 01:11 |
| wallyworld_ | i assumed that it was done the right way previously for notFound | 01:12 |
| davecheney | ok, bio break, then review | 01:12 |
| wallyworld_ | davecheney: ok, i have to run an errand, back in a bit and will look | 01:12 |
| davecheney | wallyworld_: re your CL | 02:17 |
| davecheney | the previous type, ErrUnauthorized was exported | 02:17 |
| davecheney | i'll put my comments in the review | 02: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 type | 02: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 looking | 02:48 |
| davecheney | wallyworld_: SGTM, either of those choices is fine | 02:49 |
| wallyworld_ | ok, np. thanks. i just wanted to be 100% sure you were happy | 02:49 |
| davecheney | no, thakn you | 02:49 |
| davecheney | this isn't the end of the world | 02:50 |
| davecheney | but its nice to go the extra mile | 02:50 |
| wallyworld_ | there's a fair bit of inconsistency in places | 02:50 |
| wallyworld_ | and then it gets cargo culted | 02:50 |
| davecheney | do you want to raise an issue for the worst offenders | 02:50 |
| davecheney | otherwise i fear they may never be addressed | 02:50 |
| * davecheney appologises for sounding like a issue whoring broken record | 02:51 | |
| davecheney | i used to work for an issue tracker company | 02:51 |
| wallyworld_ | i have no real concrete examples - but as i find them again i should keep a list | 02:51 |
| wallyworld_ | it's just a general perception | 02:51 |
| davecheney | and it was beaten into me that if there was no issue, it didn't happen | 02:51 |
| wallyworld_ | yeah agreed | 02:51 |
| davecheney | i'd like it if you kept that list in an issue | 02:51 |
| davecheney | or at a minimum google docs | 02:51 |
| wallyworld_ | sure. | 02:51 |
| davecheney | on your own workstation isn't helpful | 02:51 |
| wallyworld_ | some of it could be contentious eg error handling | 02:52 |
| wallyworld_ | i have a philosophical difference in opinion with a few others i think | 02:52 |
| davecheney | even more reason to flush it out into the open | 02:53 |
| wallyworld_ | a list also would determine if my perceptions are real | 02:53 |
| wallyworld_ | perhaps there's not much to it | 02:53 |
| * davecheney shrugs | 02:55 | |
| davecheney | i dunno how much there is | 02:55 |
| davecheney | but setting a precident now is important | 02:55 |
| davechen1y | thumper: excellent proposal | 03:09 |
| davechen1y | i was going to propose something like that myself | 03:09 |
| thumper | davechen1y: I was just about to ping you about it :) | 03:09 |
| thumper | just a little editing and the help one is following | 03:09 |
| davechen1y | thumper https://bugs.launchpad.net/juju-core/+bug/1134959 | 03:14 |
| _mup_ | Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 > | 03:14 |
| davechen1y | how come I didn't get a notification about this one ? | 03:15 |
| davechen1y | i'm listed as the bugmaster on this project | 03:15 |
| davechen1y | or, to put it another way | 03:15 |
| davechen1y | how can I change things so I get all notificatoins for all bugs on juju-core | 03:15 |
| thumper | I'm not sure... | 03:15 |
| thumper | you should have | 03:15 |
| thumper | sure you don't have some weird ass email rules? | 03:15 |
| davechen1y | i have no email rules | 03:15 |
| davechen1y | i hate thunderbird so much | 03:15 |
| davechen1y | i'm not going to give it the satisfactoin of asking it to take on more responsibility | 03:16 |
| davechen1y | ok, think I fixed it | 03:17 |
| davechen1y | i was sure the entire gophers team was subscribed | 03: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 think | 04:42 |
| arosales | wallyworld_: question for you if you are free | 05:19 |
| wallyworld_ | sure | 05:19 |
| arosales | wallyworld_: are there any other package requirements for running go-juju other than juju-core? | 05:26 |
| arosales | I retract that question I was able to get AWS deployed, so I think I have the requirements meet | 05:27 |
| wallyworld_ | \o/ | 05:27 |
| arosales | hp still giving me some issues | 05:27 |
| wallyworld_ | yeah, i found problems with jujud and other things, working on fixing now. sadly, hp cloud runs a different version to canonistack = problems | 05:27 |
| arosales | wallyworld_: any idea what this error means | 05:29 |
| arosales | 2013/02/27 23:29:06 JUJU juju bootstrap command failed: cannot find tools: no compatible tools found | 05:29 |
| wallyworld_ | arosales: you need to specify --upload-tools when using bootstrap as there is no well defined public bucket yet like for ec2 | 05:30 |
| wallyworld_ | so for now, when testing, we just upload our own copy | 05:30 |
| wallyworld_ | there will ultimately need to be a public place where the tools tarball lives which everyone shares | 05:31 |
| arosales | wallyworld_: is there a test bucket I can use? | 05:32 |
| arosales | I 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 think | 05: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 that | 05:34 |
| wallyworld_ | but that implies the tools have been pre-uploaded separately | 05:34 |
| wallyworld_ | which we will do at some point | 05:34 |
| wallyworld_ | and publicise the public bucket url, like for ec2 | 05:34 |
| wallyworld_ | but for now, the above bootstrap command does the job | 05:35 |
| wallyworld_ | bear in mind, bootstrap will fail for other reasons, currently being fixed | 05:35 |
| arosales | gotcha | 05:35 |
| arosales | interesting how this didn't parse | 05:35 |
| arosales | $ juju --debug --upload-tools bootstrap -e hpcloud | 05:36 |
| arosales | error: flag provided but not defined: --upload-tools | 05:36 |
| arosales | but you way did | 05:36 |
| wallyworld_ | maybe that neds to go at the end | 05:36 |
| wallyworld_ | ? | 05:36 |
| arosales | yup, worked when I did it your way, odd it parsed it correctly when at the end | 05:36 |
| wallyworld_ | yeah, odd i agree | 05:36 |
| arosales | so it looks like I need have Go in my path? | 05:36 |
| arosales | error: 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 bucket | 05:37 |
| wallyworld_ | you running precise or qantal? | 05:38 |
| arosales | quantal | 05:38 |
| wallyworld_ | http://juju-dist.s3.amazonaws.com/tools/juju-1.9.9-precise-amd64.tgz | 05:38 |
| wallyworld_ | sorry, subst quantal in there | 05:38 |
| wallyworld_ | upload the tarball to a tools dir in your control bucket | 05:39 |
| arosales | in the gophers ppa I see "golang-stable" and "cobzr" do I need those? | 05:39 |
| wallyworld_ | cobzr is for if you are doing devel work | 05:41 |
| wallyworld_ | golang is Go itself | 05: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 name | 05:48 |
| wallyworld_ | if you tried bootstrap once, it may have made it for you already though | 05:48 |
| arosales | wallyworld_: I should see that in the object store for region 1, correct? | 05:49 |
| wallyworld_ | depends on the region in your yaml but yes | 05:49 |
| wallyworld_ | it is for me | 05:50 |
| arosales | ah yes, given I am trying to work in region 1 | 05:50 |
| arosales | I don't see one there so sounds like I need to make one with the name in my env.yaml | 05:51 |
| wallyworld_ | arosales: fyi, my control bucket is juju-e802cb1c2e3ab47e3e4a1071cef25a9c | 05:51 |
| wallyworld_ | you may be able to see that one | 05:51 |
| wallyworld_ | depending on your credentials | 05:53 |
| * arosales uploading . . . | 05:55 | |
| arosales | hrm, still getting the cannot upload tools error | 05:59 |
| arosales | http://pastebin.ubuntu.com/5572611/ | 05:59 |
| * wallyworld_ looks | 06:01 | |
| wallyworld_ | 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 |
| wallyworld_ | upload-tools is more of a dev option | 06:02 |
| arosales | ok, I uploaded manually so I'll drop the upload-tools option | 06:03 |
| arosales | wallyworld_: closer, but still not finding the tools | 06:05 |
| arosales | http://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 there | 06:06 |
| wallyworld_ | if it says precise, you need to comment it out | 06:06 |
| wallyworld_ | you also need to change the image id to a quantal one | 06:07 |
| arosales | 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 |
| wallyworld_ | 75839 from memory | 06:07 |
| wallyworld_ | oh, so you have uploaded a precise tarball? | 06:07 |
| wallyworld_ | i thought you were running quantal? | 06:07 |
| arosales | I do have default-series: precise in my env.yaml but my client is quantal | 06:07 |
| arosales | do they need to match | 06:07 |
| wallyworld_ | no | 06:07 |
| wallyworld_ | as long as default-series = tools tarball = image type you should be ok | 06:08 |
| arosales | correct I uploaded the precise tar file when I noticed my yaml had the default series for precise | 06:08 |
| wallyworld_ | hmmm. not sure why it is complaining. did you upload tarbal to a tools container in the bucket? | 06:09 |
| arosales | ah I don't have it under a tools dir | 06:10 |
| wallyworld_ | that would do it | 06:10 |
| arosales | wallyworld_: nice catch on the missing tools dir, my bad. That does get me closer | 06:13 |
| arosales | http://pastebin.ubuntu.com/5572624/ | 06:13 |
| arosales | looks like it has m1.small | 06:13 |
| arosales | I 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 release | 06:14 |
| wallyworld_ | you now specify the flavour in the yaml | 06:14 |
| wallyworld_ | using default-instance-type | 06:15 |
| arosales | via default-instance-type: standard.small | 06:15 |
| arosales | ok | 06:15 |
| wallyworld_ | but it may not be in the 1.9.9 release | 06:15 |
| wallyworld_ | that is deprecated btw, until we get constrainst further progressed | 06:15 |
| arosales | seem it didn't like that yaml parameter | 06:16 |
| arosales | http://pastebin.ubuntu.com/5572629/ | 06:16 |
| arosales | I can untar the precise yaml and correct | 06:16 |
| wallyworld_ | arosales: the code to process it may not have made the 1.9.9 release | 06:17 |
| wallyworld_ | so you might be out of luck until the next drop | 06:17 |
| arosales | ah there is just an executable in that tar file | 06:17 |
| wallyworld_ | yes, jujud | 06:18 |
| arosales | ya looks to be that way | 06:18 |
| arosales | :-( | 06:18 |
| wallyworld_ | sorry | 06:18 |
| arosales | so close but yet so far | 06:18 |
| wallyworld_ | go juju works for ec2 | 06:18 |
| arosales | we wanted to try some scale testing on HP | 06:18 |
| wallyworld_ | close for openstack, but we only *just* finished the core code and are sorting out the final bits and oieces | 06:18 |
| wallyworld_ | i'm really hopeful we'll be there for next release | 06:19 |
| arosales | Looks like 1.9.10 is expected on march 9 if all goes well | 06:21 |
| arosales | 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:22 |
| arosales | wallyworld_: 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 right | 06:24 |
| wallyworld_ | s/i/it | 06:24 |
| wallyworld_ | you still won't be able to get a system fully working though | 06:24 |
| wallyworld_ | still some more things to sort out | 06:24 |
| arosales | ok, perhaps it is best to wait for 1.9.10 then | 06:25 |
| arosales | btw, do you have a pointer to the daily? | 06:25 |
| wallyworld_ | not handy but i can find it | 06:25 |
| wallyworld_ | arosales: https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily | 06:29 |
| wallyworld_ | from there you can grab the one you want | 06:29 |
| arosales | wallyworld_: thanks for link, and thanks again for your time to help me step through the openstack setup for HP. Much appreciated | 06:31 |
| wallyworld_ | no problem at all, please to help. | 06:31 |
| wallyworld_ | hopefully next time we talk thiings will be working :-) | 06:31 |
| arosales | wallyworld_: 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 yet | 06:32 |
| arosales | ok | 06:32 |
| arosales | gotcha, enjoy the rest of your day. | 06:33 |
| wallyworld_ | you too, almost wine o'clock here :-D | 06:34 |
| arosales | nice | 06:39 |
| arosales | 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 . . . | 06:45 |
| wallyworld_ | correct | 07:02 |
| wallyworld_ | but you can get one from ec2 | 07:03 |
| wallyworld_ | no | 07:03 |
| wallyworld_ | i don't think we upload the daily tarballs | 07:03 |
| arosales | yup, I didn't see one on ec2 with the urls I tried. have a good evening wallyworld_ ttyl | 07:50 |
| fwereade | morning gents | 08:11 |
| fwereade | I am reverting to r942, because r943 and all following were committed with failing tests | 08:12 |
| dimitern | fwereade: morning | 08:12 |
| fwereade | dimitern, heyhey | 08:13 |
| fwereade | dimitern, I has a grumpy: please run the full test suite before you submit | 08:13 |
| dimitern | fwereade: I saw that bug report about failing uniter tests | 08:13 |
| dimitern | fwereade: I *did* several times! | 08:13 |
| fwereade | dimitern, frankly, please run it before yu even propose | 08:13 |
| fwereade | dimitern, hm, that is odd then | 08:13 |
| dimitern | fwereade: I always do | 08:13 |
| dimitern | really odd | 08:14 |
| fwereade | 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:14 |
| dimitern | fwereade: ok, I'll investigate what went wrong | 08:15 |
| rogpeppe | mornin' all | 08:15 |
| dimitern | rogpeppe: hiya | 08:15 |
| rogpeppe | fwereade: yeah, i get a compilation failure in trunk | 08:15 |
| fwereade | rogpeppe, a *compilation* failure? goose maybe? | 08:16 |
| dimitern | rogpeppe: where? | 08:16 |
| rogpeppe | fwereade, dimitern: it's pretty weird actually: | 08:16 |
| rogpeppe | state/assign_test.go:5: cannot use &txn.Op literal (type *txn.Op) as type txn.Op in return argument | 08:16 |
| rogpeppe | but that's on an import statement | 08:17 |
| dimitern | rogpeppe: hmm | 08:17 |
| rogpeppe | i'll blow away $GOPATH/pkg and see if it still happens | 08:17 |
| fwereade | rogpeppe, huh, I didn't see that myself :/ | 08:17 |
| dimitern | rogpeppe: what did you run? | 08:17 |
| rogpeppe | dimitern: go test ./... | 08:17 |
| rogpeppe | dimitern: in juju-core root | 08:17 |
| fwereade | dimitern, rogpeppe: for form's sake, can I get a quick check of https://codereview.appspot.com/7422044 | 08:17 |
| dimitern | 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 |
| dimitern | fwereade: I'm on it | 08:18 |
| fwereade | dimitern, you didn't change the uniter tests in r943 -- that was the SetCharm branch | 08:19 |
| dimitern | fwereade: hmm | 08:19 |
| dimitern | 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:20 |
| fwereade | dimitern, IMO we should *always* be running the full test suite before we commit (really, before we propose) | 08:21 |
| rogpeppe | fwereade: +1 | 08:21 |
| dimitern | fwereade: go test ./... in juju-core/ you mean? | 08:22 |
| fwereade | dimitern, we changed behavior in state -- anything that uses state *might* have been depending on something we changed | 08:22 |
| fwereade | dimitern, yeah | 08:22 |
| rogpeppe | fwereade: we should probably be running the live tests actually. | 08:22 |
| dimitern | fwereade: ok, sorry, I promise I'll do that from now on | 08:22 |
| fwereade | dimitern, thanks :) | 08:22 |
| fwereade | rogpeppe, hmm, what's the point of the double then? | 08:23 |
| dimitern | fwereade: i guess all my changes before were isolated enough so running the tests for what I changed was good enough | 08:23 |
| fwereade | rogpeppe, if the double can't tell us when we've broken things I question its value | 08:23 |
| rogpeppe | fwereade: it means that you get *some* confidence. but it doesn't run all the agents. | 08:23 |
| fwereade | dimitern, it's a tempting idea, but it has a tendency to bite one in the ass ;) | 08:23 |
| dimitern | rogpeppe: I have this failure in rpc: http://paste.ubuntu.com/5572797/ | 08:24 |
| rogpeppe | dimitern: can you reproduce it (it works ok for me) | 08:24 |
| rogpeppe | ? | 08:24 |
| dimitern | rogpeppe: I just ran all tests (still running) | 08:25 |
| rogpeppe | fwereade: that compilation failure only happens against go tip. something weird's up. | 08:25 |
| rogpeppe | fwereade: i suspect a inlining bug | 08:26 |
| fwereade | rogpeppe, grar | 08:26 |
| rogpeppe | fwereade: i have an idea where it might lurk actually. | 08:26 |
| dimitern | fwereade: instead of reverting everything, can't we just revert my setcharm stuff? | 08:28 |
| dimitern | rogpeppe: running all tests again rpc was a PASS | 08:29 |
| rogpeppe | dimitern: hmm, i'll have a look at it | 08:29 |
| rogpeppe | some days, everything seems broken | 08:29 |
| dimitern | but this time I have a build failure in store | 08:29 |
| dimitern | # launchpad.net/juju-core/store | 08:29 |
| dimitern | store/lpad.go:7: import /home/dimitern/work/go/pkg/linux_amd64/launchpad.net/lpad.a: not a package file | 08:29 |
| rogpeppe | dimitern: that does seem weird | 08:29 |
| rogpeppe | dimitern: it might be because you interrupted a compilation in an odd place, i suppose | 08:30 |
| rogpeppe | dimitern: try blowing away that file and trying again | 08:30 |
| dimitern | rogpeppe: that solved it | 08:32 |
| dimitern | fwereade: before you revert all that, let me just check if reverting the setcharm cl will solve the issues | 08:33 |
| rogpeppe | hmm, 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 |
| rogpeppe | there's a spurious & in there | 08:33 |
| dimitern | rogpeppe: that seems like the same cl | 08:33 |
| dimitern | rogpeppe: my bad again :( | 08:33 |
| rogpeppe | dimitern: the code looks fine though | 08:33 |
| fwereade | dimitern, I kinda want to roll back to before that point | 08:35 |
| fwereade | dimitern, I don't know wtf tim/ian/gustavo were doing committing their changes without running the test suite | 08:36 |
| dimitern | fwereade: and after that we selectively reapply each CL to see were it failed? | 08:36 |
| fwereade | dimitern, after that it's up to RUN THE TESTS and then maybe resumbit their code | 08:37 |
| fwereade | dimitern, I am not exclusively grumpy with you, I am grumpy with everyone who committed to a broken trunk without reverting it | 08:38 |
| dimitern | fwereade: 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 |
| fwereade | dimitern, 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* trunk | 08:40 |
| dimitern | fwereade: yes, you're right - they should've run the tests before landing after it was broken | 08:41 |
| dimitern | fwereade: 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 |
| dimitern | fwereade: 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 |
| rogpeppe | fwereade: FWIW proposing does a merge, so really you should merge trunk, *then* test everything | 08:49 |
| fwereade | rogpeppe, what, people aren't already doing this? | 08:49 |
| fwereade | rogpeppe, I guess not | 08:50 |
| rogpeppe | fwereade: not necessarily before very propose. the problem is it can muddy the diffs | 08:50 |
| rogpeppe | s/very/every | 08:50 |
| fwereade | rogpeppe, if the diffs are muddied it's because the change to trunk has actually muddied the proposal | 08:50 |
| dimitern | fwereade: I merge trunk before proposing ever since I had issues with MPs in LP with MAAS | 08:50 |
| fwereade | dimitern, +1 | 08:51 |
| rogpeppe | fwereade: i always merge before submitting, but not always before every re-propose | 08:51 |
| rogpeppe | fwereade: 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 review | 08:52 |
| fwereade | rogpeppe, first propose and final sumbit are the points at which I think there's no excuse | 08:52 |
| dimitern | after reverting 943 I have this failure: | 08:52 |
| dimitern | FAIL: watcher_test.go:285: WatcherSuite.TestDoubleUpdate | 08:53 |
| dimitern | watcher_test.go:295: | 08:53 |
| dimitern | assertNoChange(c, s.ch) | 08:53 |
| dimitern | watcher_test.go:82: | 08:53 |
| dimitern | c.Fatalf("watch reported %v, want nothing", got) | 08:53 |
| dimitern | ... Error: watch reported {test a 4}, want nothing | 08:53 |
| fwereade | rogpeppe, being a bit casual about midstream proposes is probably ok :) | 08:53 |
| dimitern | all others pass | 08:53 |
| fwereade | dimitern, 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 yet | 08:54 |
| dimitern | fwereade: looking | 08:54 |
| dimitern | fwereade: I cannot find anything similar, I'll file a bug | 08:55 |
| fwereade | TheMue, https://bugs.launchpad.net/juju-core/+bug/1135442 | 08:58 |
| _mup_ | Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 > | 08:58 |
| dimitern | there it is bug 1135444 | 08:59 |
| _mup_ | Bug #1135444: state/watcher intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135444 > | 08:59 |
| fwereade | TheRealMue, https://bugs.launchpad.net/juju-core/+bug/1135442 | 09:00 |
| _mup_ | Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 > | 09:00 |
| fwereade | dimitern, rogpeppe, TheRealMue: I'm about to submit https://codereview.appspot.com/7422044 | 09:01 |
| rogpeppe | fwereade: how much history does it unwind? | 09:01 |
| dimitern | fwereade: go for it | 09:01 |
| fwereade | rogpeppe, about 5 revs | 09:01 |
| rogpeppe | fwereade: i was wondering if it might be better just to unwind dimiter's change | 09:02 |
| fwereade | rogpeppe, tim, gustavo and ian *all* committed with broken code | 09:02 |
| rogpeppe | fwereade: but was it their code that was broken, or just the one merge that they committed on top of? | 09:02 |
| fwereade | rogpeppe, if trunk is broken and you commit to it, you broke trunk too | 09:03 |
| rogpeppe | fwereade: i guess so | 09:04 |
| dimitern | there is the other rpc bug 1135452 | 09: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 here | 09:06 |
| fwereade_ | rogpeppe, if the tests don't pass, it's not ok to commit | 09:07 |
| rogpeppe | fwereade_: i'd probably just unwind the commit that causes the problem, but i know that's more hassle | 09:07 |
| fwereade_ | rogpeppe, if someone else broke it, you don't get to say "meh, not my problem" and compound the issue | 09:07 |
| dimitern | fwereade_: +1 | 09:07 |
| * fwereade_ submits | 09:09 | |
| === fwereade_ is now known as fwereade | ||
| dimitern | now on to making things right again :) | 09:18 |
| fwereade | dimitern, cheers :) | 09:20 |
| === TheRealMue is now known as TheMue | ||
| TheMue | fwereade: Oh, thx, will investigate. Have missed your notification. | 09:26 |
| fwereade | TheMue, I think you just need to let the system pick the port for each test | 09:27 |
| TheMue | fwereade: Yep, no constant value. | 09:27 |
| TheMue | fwereade: To avoid the current troubles which rev shall I take? 942? | 09:29 |
| fwereade | TheMue, I've reverted everything since r942 so yu should be good to go with tip | 09:29 |
| TheMue | fwereade: OK, will do so. | 09:29 |
| fwereade | rogpeppe, a thought re running live tests | 09:33 |
| fwereade | rogpeppe, we do at least have tests for the userdata we send up with a new instance, right? | 09:33 |
| rogpeppe | fwereade: well, some basic sanity checking, yeah. | 09:33 |
| rogpeppe | fwereade: but it doesn't actually run anything | 09:34 |
| fwereade | rogpeppe, if those checks are not sufficient to guarantee that the userdata still works, I don't think that's enough | 09:34 |
| fwereade | rogpeppe, I understand we don't want to run things | 09:34 |
| fwereade | rogpeppe, but is it not possible to figure out which bits can change (and how) and which bits can't? | 09:35 |
| rogpeppe | fwereade: in the end, how can you test it properly without actually running it on the target machine? | 09:35 |
| fwereade | rogpeppe, well, how much actually changes in the userdata from one machine to another? | 09:36 |
| fwereade | rogpeppe, AIUI the bulk of it is identical; the bits that change surely do so in a predictable way, right? | 09:36 |
| rogpeppe | fwereade: 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 |
| rogpeppe | fwereade: i'm not quite sure where you're going here | 09:37 |
| fwereade | rogpeppe, I'm saying that if the userdata changes in a way we don't have good reason to believe to be sane, tests should fail | 09:38 |
| rogpeppe | fwereade: i'm not quite sure what kind of check you're thinking of here. | 09:39 |
| rogpeppe | fwereade: and if it such a check would actually have caught any of the actual failures we've seen in the past | 09:39 |
| fwereade | rogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/ | 09:42 |
| fwereade | rogpeppe, do you consider this to be adequate? | 09:43 |
| fwereade | rogpeppe, if yu said anything, I didn't see it | 09:51 |
| rogpeppe | fwereade: i didn't - sorry, i didn't see your reply earlier. | 09:52 |
| rogpeppe | fwereade: those tests should certainly be better | 09:52 |
| fwereade | rogpeppe, 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 |
| rogpeppe | fwereade: i haven't said anything since then | 09:52 |
| fwereade | rogpeppe, ok, cool, just wondered if stuff got stuck | 09:53 |
| fwereade | rogpeppe, o you see my point, though? that we could do *much* better here | 09:53 |
| fwereade | rogpeppe, and that the local tests ought if anything to be an over-sensitive canary for the live tests | 09:54 |
| rogpeppe | fwereade: i'm sure that's true. however, would better tests there have caught any of the problems we've actually seen? | 09:54 |
| fwereade | rogpeppe, they should fail so people know to run the live tests for verification | 09:54 |
| fwereade | rogpeppe, are yu telling me that you have never written code which passes the local test suite but doesn't work in reality? | 09:54 |
| rogpeppe | fwereade: i'm saying that the reason it failed would not have been caught by a simple script test. | 09:55 |
| rogpeppe | fwereade: the important script tests are in cloudinit, which *does* check the scripts in detail. | 09:55 |
| rogpeppe | fwereade: 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 respect | 09:56 |
| fwereade | rogpeppe, 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 |
| fwereade | rogpeppe, even if that is the case I don't think we can assume that everyone has so complete an internal ubuntu simulator | 09:57 |
| rogpeppe | fwereade: 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 |
| fwereade | rogpeppe, how do you know when you write code that changed the scripts? | 09:58 |
| rogpeppe | fwereade: when changing the actual scripts generation in cloudinit | 09:58 |
| fwereade | rogpeppe, that's not the only time | 09:58 |
| rogpeppe | fwereade: the other way is by changing the parameters in MachineConfig | 09:59 |
| fwereade | rogpeppe, or changing config.Config | 09:59 |
| fwereade | rogpeppe, or changing upstart, or cloudinit, or agent, or... | 09:59 |
| rogpeppe | fwereade: all of those are tested by the environs/cloudinit tests, no? | 10:00 |
| fwereade | rogpeppe, some of them may be | 10:00 |
| rogpeppe | fwereade: which should test for the range of possible MachineConfig configurations | 10:00 |
| fwereade | rogpeppe, is it not the case that individual providers construct their own MachineConfigs from scratch? | 10:01 |
| fwereade | rogpeppe, and that any one of the could, say, forget to strip secrets? | 10:01 |
| rogpeppe | fwereade: yup. i think perhaps the check in the provider should be check(userData, Equals, expectedMachineConfig.Render()) | 10:03 |
| fwereade | rogpeppe, that sounds reasonable, I think, it closes the loop quite neatly | 10:03 |
| rogpeppe | fwereade: that *still* won't find out real world problems though. we'd still need to run live tests before submitting, really. | 10:04 |
| TheMue | fwereade: Got my fix done, but I've got 3 fails testing all. See http://paste.ubuntu.com/5572965/. | 10:05 |
| fwereade | rogpeppe, 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 though | 10:05 |
| fwereade | rogpeppe, that way the test that fails will be at least close to the tests you need to run for verification | 10:05 |
| rogpeppe | fwereade: you mean have the scripts literally in each provider? | 10:06 |
| fwereade | TheMue, would you please: (1) verify they're intermittent (2) add bugs, mark them high (3) assign to likely people? | 10:06 |
| fwereade | TheMue, I can take the filter test | 10:06 |
| TheMue | fwereade: Will do so, yep. | 10:07 |
| fwereade | TheMue, I suspect ian is a good candidate for TestPersistence in openstack | 10:07 |
| TheMue | fwereade: OK | 10:07 |
| fwereade | rogpeppe, is OpPutFile is your stuff? | 10:07 |
| rogpeppe | fwereade: 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. BIAB | 10:08 | |
| fwereade | rogpeppe, yeah, I think so | 10:08 |
| rogpeppe | fwereade: 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 |
| fwereade | rogpeppe, surely it is dwarfed by the effort of running each set of live tests? | 10:09 |
| rogpeppe | fwereade: i'm not sure how it helps particularly. rather than check(userData, Equals, expectedMachineConfig.Render()), we've got check(userData Equals, someLiteralStringWhichWeNeedToChangeEveryTimeCloudinitChanges) | 10:10 |
| rogpeppe | fwereade: if there's a bug in the generated scripts, it's in environs/cloudinit, not the providers themselves. | 10:11 |
| fwereade | rogpeppe, nonsense | 10:12 |
| rogpeppe | fwereade: assuming that the correct args are passed into MachineConfig | 10:12 |
| fwereade | rogpeppe, the environs create the input data | 10:12 |
| rogpeppe | fwereade: (which is checked by the suggested userdata test) | 10:12 |
| rogpeppe | fwereade: 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 |
| rogpeppe | fwereade: 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 |
| fwereade | rogpeppe, we should, yes; but we should also have some reason to believe that those scripts will run live | 10:16 |
| fwereade | rogpeppe, the number of things that change the cloudinit output is potentially high | 10:16 |
| fwereade | rogpeppe, if someone causes a change there, they should be running those actual changes live | 10:17 |
| fwereade | rogpeppe, ...shouldn't they? | 10:17 |
| rogpeppe | fwereade: 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 |
| fwereade | rogpeppe, 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 |
| rogpeppe | fwereade: about 17 minutes currently | 10:24 |
| rogpeppe | fwereade: 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 |
| fwereade | rogpeppe, ok, could have sworn it was longer :) | 10:24 |
| rogpeppe | fwereade: we could even use a hash of the output | 10:24 |
| rogpeppe | fwereade: it feels like it takes forever :-) | 10:25 |
| fwereade | rogpeppe, 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 that | 10:25 |
| rogpeppe | fwereade: it would mean that noone could submit any branch that changed the cloudinit output without it first being checked live against all providers | 10:25 |
| rogpeppe | fwereade: it's not that easy | 10:26 |
| fwereade | rogpeppe, hmm, go on? | 10:26 |
| fwereade | rogpeppe, my position is predicated on the idea that the few bits of the scripts that do change do so in predictable and checkable ways | 10:27 |
| rogpeppe | fwereade: 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 pain | 10:27 |
| fwereade | rogpeppe, nobody said good testing was easy | 10:27 |
| rogpeppe | fwereade: it's not just a pain, it's an *ongoing* pain. | 10:28 |
| rogpeppe | fwereade: because you need to search out the right bits to change every time the cloudinit output changes. | 10:28 |
| fwereade | rogpeppe, 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 work | 10:29 |
| rogpeppe | fwereade: this wouldn't either. | 10:29 |
| fwereade | rogpeppe, ISTM that it would fail any time there's a risk of the live tests failing | 10:30 |
| rogpeppe | fwereade: there's always a risk of the live tests failing | 10:30 |
| fwereade | rogpeppe, ...and it being a direct result of changes just made | 10:30 |
| rogpeppe | fwereade: can you give an example of a live test failure that this would have caught? | 10:31 |
| yolanda | hi, 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 work | 10:32 |
| rogpeppe | fwereade: if we made the testing certs unchangable, things would be easier perhaps. | 10:33 |
| fwereade | rogpeppe, 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 fail | 10:33 |
| fwereade | rogpeppe, 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 tested | 10:34 |
| rogpeppe | fwereade: all those things sound like tests on the MachineConfig input itself rather than than on the generated script. | 10:35 |
| rogpeppe | fwereade: 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 output | 10:36 |
| fwereade | rogpeppe, if use of cloudinit is optional in the providers -- which it is -- I think we must resign ourselves to checking what the providers actually produce | 10:39 |
| rogpeppe | fwereade: surely each provider can decide how best to check its user data? this is very much a provider-specific test. | 10:40 |
| mgz | optional in what sense? | 10:41 |
| fwereade | mgz, in the sense that we don't necessarily have cloudinit available | 10:41 |
| mgz | that's... not the case? | 10:41 |
| fwereade | mgz, maybe it's working in lxc now? it certainly wasn't a while ago | 10:42 |
| mgz | nothing functions at all unless cloudinit is present and runs | 10:42 |
| mgz | ah, lxc is special, and doesn't exist for go yet | 10:42 |
| rogpeppe | mgz: it will soon :-) | 10:43 |
| fwereade | mgz, anyway, rogpeppe just blocked a change of mine on the basis that cloudinit wasn't special | 10:44 |
| mgz | just using cloudinit for lxc too is probably simpliest | 10:44 |
| fwereade | mgz, he's right about this, I think | 10:44 |
| rogpeppe | mgz: at some point in the future we'll probably want juju to work under other systems without cloudinit (windows, for example) | 10:45 |
| fwereade | mgz, it would be a bit weird to explicitly pass cloudinit-specific stuff into an environ when launching an instance | 10:45 |
| mgz | I'm not sure about that. | 10:45 |
| mgz | I have two thoughts: we have too much junk in the cloudconfig that shouldn't really be there right now | 10:45 |
| fwereade | mgz, +1 on that, I think | 10:46 |
| mgz | but 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 provider | 10:46 |
| rogpeppe | mgz: +1 too (i'd be interested to know which bits you're thinking of particularly though) | 10:46 |
| fwereade | mgz, this is why I'm so pissed off by MachineConfig in the first place | 10:47 |
| fwereade | mgz, it takes all the totally generic scripts-we-must-run stuff and smooshes it into a cloudinit-specific form | 10:48 |
| rogpeppe | fwereade: those scripts are generic enough to run under Windows? :-) | 10:48 |
| mgz | well, what do we mean by windows? | 10:49 |
| fwereade | rogpeppe, at the moment we can't run the version of ubuntu we wanr | 10:49 |
| mgz | we're a long, long way away from being able to use windows as a machine type in juju | 10:49 |
| mgz | but that's not what we're talkinga about with azure | 10:49 |
| rogpeppe | mgz: i though people were talking about "juju deploy activedirectory" as a possibility at some point | 10:49 |
| mgz | for azure, we basically don't control boot, but can get our ubuntu machine, then access it and do stuff, which can still be cloudinit | 10:50 |
| rogpeppe | s/though/thought/ | 10:50 |
| mgz | I 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 this | 10:51 |
| mgz | fwereade: what's your branch, so I can catch up on the earlier discussion in the mp? | 10:52 |
| fwereade | mgz, it's just a sketch, up at https://codereview.appspot.com/7396055/ | 10:53 |
| fwereade | mgz, sadly the discussion happened live | 10:53 |
| mgz | live here, or live hangout? :) | 10:53 |
| fwereade | mgz, hangout, I'm afraid | 10:53 |
| mgz | ah well, add to the list for next week :) | 10:53 |
| fwereade | mgz, as someone who came to the environs package cold, though, I would be very interested on your thoughts on that change | 10:55 |
| rogpeppe | fwereade: i don't think that was the CL i had an issue with | 10:55 |
| mgz | hm, "error: old chunk mismatch" | 10:56 |
| fwereade | rogpeppe, crap, you're right | 10:56 |
| fwereade | mgz, sorry, I have too many recent branches :/ | 10:56 |
| * fwereade goes digging | 10:56 | |
| rogpeppe | mgz: yeah, that happens. you can see the diffs though. | 10:56 |
| rogpeppe | mgz: it'll be fixed if fwereade re-proposes | 10:56 |
| mgz | launchpad will save me | 10:56 |
| fwereade | mgz, https://codereview.appspot.com/7394048/ -- and it does have some discussion | 10:57 |
| rogpeppe | mgz: https://codereview.appspot.com/7396055/patch/1/6 | 10:57 |
| fwereade | mgz, it is just a sketch, only proposed -wip | 10:57 |
| mgz | ta | 10:58 |
| rogpeppe | mgz: 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 bug | 11:01 | |
| davecheney | rogpeppe: is this in 1.0.3 or tip ? | 11:02 |
| rogpeppe | davecheney: tip | 11:02 |
| davecheney | rogpeppe: already reported | 11:02 |
| rogpeppe | davecheney: have you narrowed it down? | 11:02 |
| davecheney | https://code.google.com/p/go/issues/detail?id=4932 | 11:02 |
| davecheney | https://code.google.com/p/go/source/detail?r=e73800eb2b00 | 11:02 |
| davecheney | stay below this revision for the moment | 11:02 |
| davecheney | or use hg revert | 11:03 |
| davecheney | i'm setting up a jenkins build against tip to ensure we catch this faster | 11:03 |
| davecheney | sorry, hg undo | 11:03 |
| rogpeppe | davecheney: ah, cool. i was trying to reproduce by trial and error. | 11:03 |
| rogpeppe | davecheney: i'd found this: | 11:04 |
| rogpeppe | 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 } }) } } | 11:04 |
| rogpeppe | davecheney: but couldn't reliably reproduce it in a small program | 11:04 |
| davecheney | rogpeppe: ironically, the fix was for an issue which was almost identical https://code.google.com/p/go/issues/detail?id=4879 | 11:04 |
| davecheney | rogpeppe: nah, we use almost every conceivable style and permutation allowed by the language | 11:05 |
| rogpeppe | davecheney: i narrowed it down quite a bit | 11:05 |
| davecheney | try https://codereview.appspot.com/7437043 | 11:05 |
| davecheney | ok, jenkins biuld is setup | 11:07 |
| davecheney | but is currently passing because r943 was rolled back | 11:07 |
| rogpeppe | davecheney: trying that CL | 11:08 |
| rogpeppe | davecheney: it sounds like they'd still benefit from a small test case | 11:08 |
| davecheney | yeah, i agree, have a look at the 4879 | 11:09 |
| davecheney | the test case for that might be some of the way there | 11:09 |
| rogpeppe | davecheney: that CL fixed the problem | 11:10 |
| davecheney | rogpeppe: a test case would be useful | 11:13 |
| davecheney | Dmorsing was saying that the way composite literals work, stretches the meaning of work | 11:13 |
| rogpeppe | davecheney: how so? | 11:13 |
| davecheney | 20:21 < DMorsing> davecheney, the biggest problem is that the compiler does a lot of work on the ast | 11:14 |
| davecheney | 20:21 -!- fzzbt [~jahman@melkinpaasi.cs.helsinki.fi] has quit [Client Quit] | 11:14 |
| davecheney | 20:22 -!- AnybodyElse [uid10067@gateway/web/irccloud.com/x-yvlsbbaerwtfivkb] has joined #go-nuts | 11:14 |
| davecheney | 20:22 -!- fzzy [~jahman@melkinpaasi.cs.helsinki.fi] has joined #go-nuts | 11:14 |
| davecheney | 20:22 -!- gsamat [~gsamat@broadband-188-32-17-124.nationalcablenetworks.ru] has quit [Quit: Computer has gone to sleep.] | 11:14 |
| davecheney | 20: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 AST | 11:14 |
| fwereade | davecheney, tyvm | 11:17 |
| davecheney | no worries | 11:17 |
| davecheney | i've got a build setup now that watches juju tip and go tip for breakages | 11:18 |
| davecheney | note: i am not running the tests (yet), just checking it compiles | 11:21 |
| jam | mgz: poke | 11:32 |
| mgz | jam, a, hey | 11:37 |
| jam | mgz: care to join us for mmubemboeumob ? | 11:37 |
| mgz | too many things going on, have fled to the conservatory | 11:39 |
| wallyworld_ | ian@wallyworld:~/.hpopenstack$ juju deploy mysql | 11:53 |
| wallyworld_ | error: cannot get latest charm revision: charm info errors for "cs:quantal/mysql": entry not found | 11:53 |
| rogpeppe | fwereade: 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/7375053 | 12:04 |
| fwereade | rogpeppe, looking | 12:12 |
| dimitern | fwereade: done with standup, shall we g+? | 12:23 |
| fwereade | dimitern, ok, would you start one please? | 12:24 |
| dimitern | fwereade: https://plus.google.com/hangouts/_/5fb9c8fa96a6d9bc74de7a5f5cf171a04aeb0a40?authuser=0&hl=en | 12:24 |
| jam | mgz, wallyworld_: https://code.launchpad.net/~jameinel/juju-core/only-943/+merge/151005 | 12:52 |
| wallyworld_ | jam: my rev's changes look like they're all there. thanks for doing that | 12:56 |
| jam | wallyworld_: np, if you can merge it and run the test suite quickly, it would help | 12:56 |
| wallyworld_ | jam: hmmm. a failure, haven't looked yet.... PANIC: local_test.go:132: localServerSuite.SetUpTest | 13:01 |
| jam | wallyworld_: is it related to not enough bytes ? | 13:01 |
| wallyworld_ | not sure, looking now | 13:01 |
| === gary_pos` is now known as gary_poster | ||
| jam | wallyworld_: if you get a chance to paste the full traceback, please do so. | 13:02 |
| wallyworld_ | jam: https://pastebin.canonical.com/85834/ | 13:03 |
| jam | wallyworld_: that is the failure I'm working on in goose | 13:03 |
| jam | interesting we've only seen it a couple times recently | 13:03 |
| wallyworld_ | ah ok | 13:03 |
| jam | we must be using a lot more random data. | 13:03 |
| wallyworld_ | i'll rerun | 13:03 |
| wallyworld_ | jam: all good this time | 13:05 |
| fwereade | jam, tyvm for reapplying those changes, if it's all passing it LGTM | 13:06 |
| jam | fwereade: thanks | 13:06 |
| jam | I've confirmed they pass here and for wallyworld_ | 13:07 |
| fwereade | jam, <3 | 13:07 |
| fwereade | jam, 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 it | 13:07 |
| jam | fwereade: 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 |
| jam | I 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 |
| dimitern | wallyworld_: I think such intermittent failures deserve a bug report | 13:10 |
| fwereade | dimitern, +1 | 13:10 |
| jam | dimitern: I have a patch submitted that you've reviewed for it, which is waiting for roger to approve | 13:10 |
| jam | so yes, we could have a bug, but we do have a fix | 13:10 |
| dimitern | jam: ah, that's your fix? ok | 13:10 |
| dimitern | jam: I though it's a new random thing | 13:10 |
| jam | wallyworld_: https://codereview.appspot.com/7375059/ is the one where fwereade is removing instanceid from being stored. | 13:11 |
| jam | dimitern: the panic is because random isn't giving enough data, and we end up with a nil somewhere. | 13:11 |
| jam | the fix should prevent that. | 13:11 |
| fwereade | jam, 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 tomorrow | 13:12 |
| jam | fwereade: well next week is sprinting :). | 13:12 |
| jam | And 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 |
| jam | The only remaining stuff is policy stuff | 13:12 |
| jam | do we want trunk to be only accessible by the bot | 13:12 |
| jam | or should the bot just be in the group that can commit to it. | 13:13 |
| fwereade | jam, I'm pretty comfortable declaring anything with a pulse to be untrustworthy | 13:15 |
| fwereade | jam, 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 are | 13:16 |
| jam | fwereade: 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 |
| fwereade | jam, 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 benefits | 13:18 |
| fwereade | jam, the other big thing IMO is that with tarmac, we could actually get away with running likley subsets of the tests | 13:18 |
| fwereade | jam, and *that* then means we could put the deps in the source tree and get repeatable builds | 13:20 |
| fwereade | jam, (nobody's thought of an alternative route to get that without dropping the go tools, right?) | 13:22 |
| * rogpeppe goes for some lunch | 13:22 | |
| * fwereade pops out for 5 mins in the sun, then over to dimitern's place for state talks; see you all soon | 13:23 | |
| TheMue | cu | 13: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 | |
| dimitern | benji: can you file a quick bug report about it please? | 13:36 |
| benji | dimitern: will do | 13:37 |
| dimitern | benji: today everything breaks it seems | 13:37 |
| benji | :) | 13:37 |
| benji | dimitern: https://bugs.launchpad.net/juju-core/+bug/1135757 | 13: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 |
| dimitern | benji: cheers! | 13:40 |
| dimitern | benji: yeah, it seems that's related to ian's list prefix change | 13:42 |
| dimitern | benji: strange, I'm not getting it on tip - are you sure you've updated goose before? | 13:47 |
| dimitern | fwereade is here now | 13:48 |
| benji | dimitern: nope, I have not, let me try that real quick | 13:49 |
| jam | dimitern: did you manage to countersign your objectives? HR is asking me to do the final signoff. | 14:20 |
| jam | dimitern: https://allhands.canonical.com/hra-space/portal/root/employee | 14:21 |
| dimitern | jam: oh, you wrote here - yes I did | 14:21 |
| jam | I know you did the submission, there is a countersign step that has to happen after mine. | 14:22 |
| jam | I'm guessing you did it, but I want to make sure before I tell them. | 14:22 |
| jam | dimitern: ^ | 14:22 |
| dimitern | jam: I double checked - there's no more to do on that page, tell me if I missed something. I just selected I agree + submit | 14:25 |
| dimitern | benji: did you manage to get the test pass?\ | 14:25 |
| jam | if there aren't any tasks, then I don't see anything to do either. | 14:25 |
| benji | dimitern: let me check the test run... | 14:27 |
| dimitern | jam: yeah, i had to go to the archives page to see the countersign task | 14:27 |
| benji | it 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 blackboard | 14:27 | |
| benji | It 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 |
| dimitern | benji: cheers! please update the bug | 14:28 |
| benji | dimitern: done | 14:30 |
| * rogpeppe is back | 14:41 | |
| TheMue | rogpeppe: 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 |
| rogpeppe | TheMue: i'm not sure. i *presume* only this evening. mramm? | 14:52 |
| niemeyer | Yo all! | 14:52 |
| niemeyer | mthaddon: ping | 14:52 |
| rogpeppe | niemeyer: hiya! | 14:52 |
| TheMue | niemeyer: Hi. | 14:52 |
| mthaddon | niemeyer: pings with content save time :) | 14:52 |
| niemeyer | mthaddon: https://portal.admin.canonical.com/59712 | 14:53 |
| mthaddon | niemeyer: cool, thx, we'll get it done soon - is there a particular deadline for it, or just "sooner the better"? | 14:53 |
| niemeyer | mthaddon: I generally like to say "Hi, how's life been since we last deployed it?", but alright :) | 14:53 |
| mthaddon | heh | 14:53 |
| * TheMue is AFK, BIAB | 14:53 | |
| niemeyer | mthaddon: There's no deadline, but sooner the better indeed | 14:54 |
| niemeyer | mthaddon: There's a new stats feature | 14:54 |
| niemeyer | mthaddon: Can't see that data while it doesn't land | 14:54 |
| mthaddon | niemeyer: ok, thx | 14:54 |
| niemeyer | rogpeppe, TheMue: Yos | 14:54 |
| mramm | rogpeppe: TheMue: yea, just the evening meeting is fine | 14:55 |
| mthaddon | niemeyer: the RT mentions revno 945 - is 949 okay (our scripts pull tip by default)? | 14:58 |
| niemeyer | mthaddon: Yeah, it's okay | 14:58 |
| mthaddon | thx | 14:58 |
| mthaddon | niemeyer: done | 14:59 |
| === wedgwood_away is now known as wedgwood | ||
| niemeyer | mthaddon: Sweet! Let me test it | 15:00 |
| niemeyer | mthaddon: WORKS! | 15:00 |
| mthaddon | good good | 15:01 |
| niemeyer | mthaddon: Thanks much | 15:01 |
| mthaddon | np | 15:01 |
| fwereade | mramm, TheMue, rogpeppe: kanban? | 15:04 |
| mramm | fwereade: we decided to only do the one this evening | 15:04 |
| fwereade | mramm, ah! | 15:04 |
| fwereade | mramm, good point | 15:05 |
| fwereade | mramm, ok then :) | 15:05 |
| fwereade | knocking off now, we've got the call later | 16:52 |
| niemeyer | fss: ping | 17:59 |
| bac | hi rogpeppe, would you time to do a second review for me? | 18:32 |
| rogpeppe | bac: sure | 18:32 |
| rogpeppe | bac: link? | 18:32 |
| bac | cool, i hope you're not EOD | 18:32 |
| bac | rogpeppe: https://codereview.appspot.com/7369058/ | 18:32 |
| rogpeppe | bac: normally yes, but today i'm working later | 18:32 |
| rogpeppe | bac: reviewed | 18:42 |
| === deryck is now known as deryck[lunch] | ||
| bac | rogpeppe: thank. looking at it now | 18:53 |
| niemeyer | fss: pingous? | 20:09 |
| === deryck[lunch] is now known as deryck | ||
| === _thumper_ is now known as thumper | ||
| fss | niemeyer: hi | 21:02 |
| niemeyer | fss: Heya.. you've got reviews | 21:02 |
| niemeyer | fss: Great stuff.. just trivial comments | 21:02 |
| fss | niemeyer: I'm lbox proposing group changes right now :-) | 21:03 |
| niemeyer | fss: Sweet | 21:03 |
| fss | niemeyer: regarding the message returned by amazon, that's the message | 21:03 |
| fss | niemeyer: should I use %q anyway? | 21:04 |
| rogpeppe | right, i'm off for the night. see y'all tomorrow. | 21:06 |
| niemeyer | fss: Does it include quotes around the name or not? | 21:21 |
| === thumper is now known as thumper-afk | ||
| jcastro | mramm: around? | 23:04 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| mramm | jcastro: I am now | 23:12 |
| jcastro | got time for a quick G+? | 23:16 |
| jcastro | 2 minutes, I promise! | 23:16 |
| jcastro | mramm: https://plus.google.com/hangouts/_/097d689c217f97e00665bff91bac17fd9b78e439?authuser=0&hl=en | 23:16 |
| === wedgwood is now known as wedgwood_away | ||
| mramm | jcastro, sorry I missed you... | 23:55 |
| jcastro | no worries | 23:58 |
| jcastro | next time | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!