| thumper | wallyworld_: ping | 00:53 |
|---|---|---|
| wallyworld_ | otp, sec | 00:54 |
| wallyworld_ | thumper: hi | 01:01 |
| thumper | wallyworld_: hey | 01:01 |
| thumper | wallyworld_: how are things with you today? | 01:01 |
| wallyworld_ | not too bad. doing some refactoring as per code review comments. but main issue is a failing test i have no farking idea what's wrontg | 01:01 |
| thumper | wallyworld_: want to hangout? or are you focused? | 01:04 |
| wallyworld_ | i can do a call | 01:04 |
| wallyworld_ | you have a url handy?\ | 01:04 |
| thumper | nope, will start one | 01:06 |
| thumper | https://plus.google.com/hangouts/_/871ae6be4b5cd1f19de181069ba7255665b21443?hl=en | 01:06 |
| wallyworld_ | thumper: https://codereview.appspot.com/9886045 | 01:28 |
| * fwereade__ is up way past his bedtime, and has just proposed a reasonably monstrous pipeline, and would be ever so happy if he woke up tomorrow to some reviews from thumper and/or wallyworld_ | 02:16 | |
| * fwereade__ will probably be late in tomorrow | 02:16 | |
| thumper | fwereade__: hi there | 02:16 |
| wallyworld_ | fwereade__: sure | 02:16 |
| thumper | fwereade__: saw them incomming | 02:16 |
| fwereade__ | cheers | 02:16 |
| fwereade__ | gn :) | 02:16 |
| thumper | night | 02:16 |
| wallyworld_ | fwereade__: i'll ping you tomorrow if i can't get my stupid test to pass | 02:17 |
| wallyworld_ | talk later | 02:17 |
| fwereade__ | wallyworld_, sorry, never got round to that -- definitely let me know tomorrow | 02:17 |
| wallyworld_ | will do. good night | 02:17 |
| wallyworld_ | thumper: found why the two tests were giving different results - stupid typo. now to fix the failure | 02:38 |
| thumper | haha | 02:38 |
| wallyworld_ | fo | 02:39 |
| thumper | wallyworld_: I have something for you | 02:48 |
| wallyworld_ | yeees? | 02:48 |
| thumper | wallyworld_: what does a container instance of a *state.Machine give for the result of a Tag() call ? | 02:48 |
| thumper | does it special case anything? | 02:48 |
| wallyworld_ | not that i have implemented | 02:49 |
| thumper | wallyworld_: you'll need to tweak it | 02:49 |
| wallyworld_ | i haven't changed the Tag() method | 02:49 |
| thumper | wallyworld_: as the result of Tag() should be something that works for a filename | 02:49 |
| thumper | machine-0/lxc/1 isn't good | 02:49 |
| thumper | replace('/', '-' | 02:49 |
| wallyworld_ | i had ":" as the separator | 02:49 |
| thumper | yeah, I know | 02:49 |
| thumper | we can blame fwereade__ for that | 02:49 |
| wallyworld_ | ok, will tweak the Tag() method, thanks for letting me know | 02:50 |
| thumper | wallyworld_: can I count on you fixing that for me? | 02:50 |
| thumper | np | 02:50 |
| wallyworld_ | yep | 02:50 |
| thumper | wallyworld_: I'm getting my head around all this cloudinit stuff | 02:50 |
| thumper | now that I realise that the user-data is the yaml file, things are easier | 02:50 |
| thumper | I was trying to find the missing step | 02:50 |
| wallyworld_ | yeah | 02:50 |
| wallyworld_ | i knew that much not not too much extra | 02:51 |
| wallyworld_ | but not | 02:51 |
| * thumper nods | 02:51 | |
| thumper | I'm starting to feel more comfortable about implementing this lxc-broker now | 02:51 |
| thumper | I feel I know more about WTF is going on | 02:52 |
| wallyworld_ | cool | 02:52 |
| thumper | wallyworld_: do you know how to use the api? | 03:31 |
| thumper | wallyworld_: I want to start using that instead of *state.State | 03:31 |
| thumper | if possible | 03:31 |
| thumper | we should have something that returns me a *state.Machine right? | 03:32 |
| wallyworld_ | thumper: not really. i've not written code that uses it. perhaps look at the tests to see what is done? | 03:32 |
| thumper | or should I not bother yet | 03:32 |
| thumper | I have too many other things to worry about just now | 03:32 |
| thumper | will leave a TODO for now | 03:32 |
| wallyworld_ | sure. let's make sure we fix that one soon though | 03:32 |
| thumper | wallyworld_: yes, agreed | 03:40 |
| === tasdomas_afk is now known as tasdomas | ||
| * thumper stops hacking to do some reviews for fwereade__ | 04:48 | |
| thumper | fwereade__: left the last two as an exercise for some europeans :) | 05:23 |
| * thumper is done for today | 05:23 | |
| === danilos_ is now known as danilos | ||
| jam | morning danilos | 07:57 |
| danilos | jam: morning | 07:57 |
| rogpeppe1 | mornin' all | 08:07 |
| TheRealMue | morning | 08:08 |
| TheRealMue | somehow my provider dislikes me this morning *hmpf* | 08:08 |
| === TheRealMue is now known as TheMue | ||
| TheMue | fwereade__: ping | 08:57 |
| jam | danilos: do you have a hardware switch on your mic | 08:59 |
| danilos | jam: no | 08:59 |
| danilos | jam: it just died | 08:59 |
| TheMue | fwereade__: oh, technician rings at the door, bbiab | 08:59 |
| danilos | jam: it's not showing in the "vumeter" | 08:59 |
| fwereade__ | TheMue, heyhey | 08:59 |
| danilos | jam: it seems something got messed up in the USB stack, my mouse stopped working now | 09:01 |
| jam | danilos: uh-oh, sounds like reboot is in order | 09:02 |
| danilos | jam: yeah :/ brb | 09:02 |
| jam | I'll grab a snack, be back in a sec | 09:03 |
| jam | danilos: welcome back | 09:09 |
| fwereade__ | rogpeppe1, jam, TheMue: https://codereview.appspot.com/10083047/ and https://codereview.appspot.com/10166044/ are sizeable but important | 09:10 |
| TheMue | fwereade__: so, back again, will take a look | 09:10 |
| TheMue | fwereade__: thx for your review | 09:10 |
| fwereade__ | TheMue, and what can I do for you? you pinged :) | 09:11 |
| TheMue | fwereade__: yes, the first note "Should just be a straight rename of JobServeAPI to JobManageState." is not clear for me in that context. | 09:11 |
| fwereade__ | TheMue, jobs are somewhat fluid and casual groupings of tasks; in the current intended model, the ManageState tasks include API-serving and txn-resuming (by necessity) and cleaning (by convenience/similarity of use case) | 09:14 |
| TheMue | fwereade__: ah, so only JobManageState shall exisit in future and start all the according tasks. am i right? | 09:18 |
| fwereade__ | TheMue, JobManageState should just be a direct replacement of JobServeAPI at this point | 09:19 |
| TheMue | fwereade__: ok | 09:19 |
| fwereade__ | TheMue, fwiw if you were to fix the watcher and just repropose the worker, I would be happy -- integration (and thus the jobs change) doesn't have to come in in this CL | 09:20 |
| fwereade__ | TheMue, smaller, simpler, quicker to review, I think | 09:20 |
| fwereade__ | TheMue, (and I'm sorry for dropping the ball on the watcher impl review) | 09:20 |
| TheMue | fwereade__: it's ok. i had it this way earlier but changed it after a hint of dimiter. will now change it back again. | 09:21 |
| mattyw | fwereade__, is it worth me raising a bug about $HOME not being set when hooks get run, or is it fair to say it's not there for a reason? | 09:25 |
| TheMue | fwereade__: "Clients are expected to parse their own damn data ..." *hehe* | 09:25 |
| fwereade__ | mattyw, I would *prefer* to only guarantee the existence of the env vars we produce ourselves | 09:26 |
| fwereade__ | mattyw, let me just poke in and see if I can see what happened to it, though, just a sec | 09:27 |
| mattyw | fwereade__, it's possible it might not have ever been there, It looked to me like it wasn't set in pyjuju either | 09:28 |
| fwereade__ | mattyw, ok, it looks like it never was there | 09:30 |
| mattyw | fwereade__, ok thanks | 09:31 |
| fwereade__ | mattyw, I *might* be conviced that we should pass the whole shell environment down rather than constructing it from scratch (apart from $PATH, which we do copy down (with additions)), but I'd need a reasonably significant use case | 09:32 |
| fwereade__ | mattyw, feels somewhat nicer to run in as controlled an environment as possible though | 09:33 |
| fwereade__ | Makyo, ping -- I would appreciate your eyes on https://codereview.appspot.com/10166044/ -- it includes the stuff we discussed yesterday | 09:35 |
| rogpeppe1 | fwereade__: i think we should pass the whole shell environment down | 09:37 |
| === tasdomas is now known as tasdomas_afk | ||
| danilos | jam, all: heya, how do I run the live tests? I had it written down somewhere, but can't find it now | 10:12 |
| jam | danilos: you go to each provider, cd environs/openstack; go test -live; cd environs/ec2; go test -amazon | 10:13 |
| jam | you need to source your credentials into the environment first | 10:13 |
| danilos | jam: it's fine to keep it in ~/.juju/environments.yaml or do I really need to put them into environment variables? | 10:13 |
| jam | danilos: I don't think the test suite looks at environments.yaml | 10:13 |
| danilos | jam: ack, thanks | 10:14 |
| === tasdomas_afk is now known as tasdomas | ||
| * TheMue is at lunch | 10:31 | |
| danilos | jam: I am trying with ec2 first, but "go test -amazon" doesn't work (it seems AWS_SECRET_ACCESS_KEY is being unset somewhere where it shouldn't be, since setting both through EC2 envvars makes it go past that point, but then tests fail which expect access keys to be wrong) | 10:33 |
| danilos | jam: fwiw, this is what I had: http://pastebin.ubuntu.com/5754428/ | 10:35 |
| jam | danilos: if you are running the ec2 tests, I know you'll need to also do '-test.timeout=7200' or something like that, as the test suite is quite slow. | 10:35 |
| jam | that isn't your specific problem | 10:36 |
| jam | but you'll run into that in 5 min | 10:36 |
| jam | (the default timeout for the test suite) | 10:36 |
| danilos | jam: right | 10:36 |
| jam | danilos: so I just sourced my ec2creds which only sets "AWS_ACCESS_KEY_ID" and "AWS_SECRET_ACCESS_KEY" and go test is happy | 10:37 |
| jam | danilos: you might want to check the spelling of your env variables, as the above ones aren't very obvious for me. | 10:40 |
| rogpeppe | laptop just crashed for the 4th time in two days | 10:40 |
| rogpeppe | and lost another couple of hours' work dammit | 10:40 |
| danilos | jam: I did, I'd hope copy-pasting from goamz/aws/aws.go should do it as a check :) | 10:42 |
| jam | right | 10:42 |
| jam | rogpeppe: just in your editor buffer? wouldn't it at least be on disk? | 10:42 |
| rogpeppe | jam: i hadn't saved, stupidly | 10:43 |
| * rogpeppe goes to change the editor so that this doesn't happen again | 10:43 | |
| jam | danilos: I can confirm your bootstrap-verify branch (as when we started) is passing the test suite. "BootstrapAndDeploy" takes 421s to complete, though. | 10:43 |
| danilos | rogpeppe, hey, emacs auto-saves stuff for you | 10:43 |
| mgz_ | eheh, stop trying to convert people to your religion | 10:44 |
| danilos | jam: I am having the same problem with trunk | 10:44 |
| danilos | mgz_, just sayin' :P | 10:44 |
| jam | mgz_: /wave | 10:44 |
| rogpeppe | danilos: yeah. this should too - there's a Dump function that saves the current working state, but it's not called automatically | 10:44 |
| jam | danilos: well, I do a pretty heavy cycle of running the test suite, which requires saving often | 10:44 |
| danilos | jam: me too, I even commit with each new test/function added ;) | 10:45 |
| jam | danilos: yeah, I'm often the same | 10:46 |
| danilos | jam: any ideas if I am doing something blatantly wrong: http://pastebin.ubuntu.com/5754461/? | 10:47 |
| jam | danilos: my goamz was a bit older, I just updated and will see if that breaks my stuff | 10:49 |
| danilos | jam: thanks | 10:49 |
| danilos | nooo, the drilling on the floor up returns | 10:50 |
| jam | danilos: I get a lot of failures just running 'go test ./...' in goamz, does it pass for you? | 10:50 |
| jam | TestMultiComplete fails for me. | 10:50 |
| jam | a lot of "SpecifiedBucketDoesNotExist" log messages. | 10:51 |
| danilos | jam: yeah, for me as well with r37: http://pastebin.ubuntu.com/5754474/ | 10:51 |
| jam | danilos: on the plus side, it has been failing for a while :) | 10:59 |
| jam | r35 also fails for me | 10:59 |
| jam | danilos: I see the same failure you had until I source my credentials. | 11:01 |
| jam | Are you sure you exported them correctyl? | 11:01 |
| jam | danilos: when I source my creds again, it starts passing, even if goamz doesn't work. | 11:09 |
| danilos | jam: http://pastebin.ubuntu.com/5754519/ | 11:13 |
| danilos | jam: I am not sharing my keys with you, but even echoing $... does show them | 11:13 |
| jam | danilos: sure 'set' sees it, but are they exported? | 11:13 |
| jam | I don't know if you are using bash | 11:14 |
| jam | but you can do: | 11:14 |
| jam | FOO=xxyy | 11:14 |
| jam | but you need to do | 11:14 |
| jam | export FOO | 11:14 |
| jam | for child processes to see it | 11:14 |
| danilos | jam: that was it :/ ta | 11:16 |
| jam | danilos: I'm glad it helped | 11:16 |
| danilos | jam: I thought I tried with passing them right before the "go test", when it's passed down | 11:16 |
| jam | danilos: AWS_XXX=YYYY go test ? | 11:17 |
| jam | I think that should wok | 11:17 |
| jam | work | 11:17 |
| danilos | jam: it was confusing that it actually failed on ACCESS_SECRET_KEY, but not on ACCESS_KEY_ID which was checked for first | 11:17 |
| danilos | jam: yeah, I know | 11:17 |
| jam | danilos: hangout time? | 11:30 |
| jam | you can at least join to listen in | 11:30 |
| wallyworld__ | jam: | 11:54 |
| wallyworld__ | state_test.go:1107: | 11:54 |
| wallyworld__ | c.Errorf("mgo.Dial only paused for %v, expected at least %v", t1, 3*retryDelay) | 11:54 |
| wallyworld__ | ... Error: mgo.Dial only paused for 500.800787ms, expected at least 1.5s | 11:54 |
| mgz_ | hm, environs/azure seems to break the build? | 11:59 |
| mgz_ | fwereade__: ^am I missing something or should this get pulled out for now? | 11:59 |
| danilos | one question about the live tests: if I interrupt the test run with C-c, does that mean I might have instances that keep on running? | 12:00 |
| jam | mramm: are you awake yet? :) | 12:01 |
| mgz_ | danilos: potentially, tests should be capable of not leaking resources, but do you trust them to be robust like that? :) | 12:01 |
| jam | mgz_, fwereade__: I'm pretty sure we need to roll back the azure change because it breaks 'go build' | 12:01 |
| danilos | mgz_, tbh, no :) | 12:01 |
| mgz_ | you'll want the eucatools stuff or similar to inspect left over instances/secgroups etc | 12:02 |
| mramm | jam: yep, I'm here | 12:02 |
| jam | wallyworld__: I should probably have posted to the mailing list when I updated for the newer mgo, I had run into it the other way (updated mgo, the *other* tests were failing) | 12:02 |
| jam | mramm: I'm here: https://plus.google.com/hangouts/_/e6b23e6c7391c8641a3b6660495f8fe7055e1884 | 12:02 |
| jam | danilos: yes, and in fact, I've seen unclean shutdowns without killing the test suite. | 12:02 |
| jam | So generally, check if you have instances running | 12:03 |
| wallyworld__ | jam: no problem. i wonder why the version (v2) stayed the same even though the changes were not backwards compatible semantically | 12:03 |
| jam | wallyworld__: technically the APIs are stable, it just added a Sleep internally | 12:03 |
| jam | tests that depend on time.Now are a bit broken anyway | 12:03 |
| jam | IMO | 12:04 |
| wallyworld__ | but the behaviour changed | 12:04 |
| danilos | jam: ok, the tests pass with canonistack as well; now, I wonder if anybody knows how to choose lcy02 for https://dashboard.canonistack.canonical.com/ | 12:13 |
| jam | mgz_: ^^ ? | 12:13 |
| mgz_ | people use dashboard? :) | 12:14 |
| fwereade__ | mgz_, huh, was that not a change in response to an mgo change? are you definitely up to date there? | 12:16 |
| mgz_ | danilos: so, no, not sure, you can ask in the internal support channel, or use python-novaclient commandline tools which pay attention to the env variables you set | 12:16 |
| fwereade__ | jam, mgz_: grar, I did specifically lgtm it with a "make sure it builds" | 12:17 |
| danilos | mgz_, heh, I was taking a look and noticed that none of my instances showed up in there | 12:17 |
| mgz_ | there may be another endpoint for lcy02 | 12:17 |
| jam | fwereade__: yep, I saw that | 12:18 |
| jam | and I was surprised | 12:18 |
| fwereade__ | jam, if no more tan I have seen has happened, yes, please revert it | 12:18 |
| mgz_ | fwereade__: sorry, probably crossing converstions here | 12:18 |
| mgz_ | fwereade__: ian's test failure was a mgo thing, trunk not building is the azure stub | 12:19 |
| fwereade__ | mgz_, ok, we should indeed revert the azure stub if it doesn't build | 12:19 |
| danilos | mgz_, the wiki page talks about choosing a different region in the drop down when logging in, a shame there is no such dropdown :) | 12:21 |
| mgz_ | :D | 12:21 |
| rogpeppe | fwereade__: all reviewed i think | 12:21 |
| danilos | mgz_, ah, there's also a "lcy01 is the only available region in the dashboard" | 12:21 |
| rogpeppe | now back to try and remember the code i wrote this morning :-( | 12:21 |
| fwereade__ | rogpeppe, lovely, ty | 12:22 |
| danilos | rogpeppe, nothing more joyous than having to rewrite the code from memory (it is still fast, but very annoying) | 12:22 |
| fwereade__ | mgz_, jam, has anyone proposed a revert? | 12:22 |
| mgz_ | fwereade__: proposed | 12:23 |
| rogpeppe | danilos: yeah. it's the comments in particular i find annoying, when you've spent a while thinking of a good turn of phrase and it's all gone | 12:23 |
| fwereade__ | mgz_, approved on trust that it does what you say it does ;p | 12:23 |
| mgz_ | https://codereview.appspot.com/9714046/ | 12:24 |
| rogpeppe | mgz_: LGTM trivial | 12:27 |
| jam | mgz_: just make sure you poke jtv so he knows its happened | 12:28 |
| jtv | Argh. I forgot to compile before landing. And now I can't propose a fix because something else is broken. | 12:29 |
| fwereade__ | rogpeppe, sorry, but you seem to have reviewed all the things that already had 2 LGTMs and skipped the one's that didn't | 12:29 |
| jtv | I thought I'd built it, and I didn't. *bash* *bash* | 12:29 |
| fwereade__ | rogpeppe, good comments, appreciated very much | 12:29 |
| rogpeppe | fwereade__: orly? i thought i'd gone through all the ones in activereviews | 12:30 |
| rogpeppe | fwereade__: which ones have i missed? | 12:30 |
| rogpeppe | fwereade__: (it's really not easy to work forward through reviews in a consistent way - i should have kept notes about which ones i'd done) | 12:31 |
| jtv | Does anybody know what the logger.Logf errors are about? | 12:31 |
| fwereade__ | rogpeppe, https://codereview.appspot.com/10083047/ and https://codereview.appspot.com/10166044/ | 12:31 |
| fwereade__ | rogpeppe, it is not impossible that you were looking at the "approved" section ;p | 12:31 |
| fwereade__ | jtv, update launchpad.net/loggo | 12:31 |
| rogpeppe | fwereade__: ah, i was indeed | 12:31 |
| rogpeppe | fwereade__: doh | 12:32 |
| jtv | argh thanks | 12:32 |
| rogpeppe | fwereade__: and one of them i'd even started and had a pending comment for | 12:32 |
| rogpeppe | fwereade__: i started on that one and then realised i needed to go through the rest of the pipeline to get context | 12:33 |
| jtv | Will have a build fix up shortly. | 12:37 |
| gary_poster | mramm, are you ready for a random GUI person to descend upon the juju core daily yet, or should we wait another day? | 12:38 |
| mramm | sure | 12:39 |
| gary_poster | thanks | 12:39 |
| fwereade__ | rogpeppe, no worries | 12:44 |
| jtv | Review needed for build fix: https://codereview.appspot.com/10184043 | 12:47 |
| jtv | Anybody available? | 12:47 |
| TheMue | fwereade__: while changing test just one question. by coalescing events you mean multiple cleanups transaction lead to only one event? | 12:49 |
| === teknico1 is now known as tekNico | ||
| === wedgwood_away is now known as wedgwood | ||
| fwereade__ | TheMue, yes I do, sorry | 13:39 |
| TheMue | fwereade__: hmm, so outlined loop (I already used it before that way) does not coalescing events. | 13:41 |
| TheMue | fwereade__: it simply fires each time. | 13:42 |
| TheMue | fwereade__: e.g. I have two destroys w/o cleanup. here I get two events. | 13:45 |
| fwereade__ | TheMue, that's fine if the first event was notified before the second occurred | 13:47 |
| fwereade__ | TheMue, but if two events happen and then the client is notified, he should not be notified again | 13:47 |
| fwereade__ | TheMue, I think the structure I showed you is pretty common among the watchers, isn't it? | 13:47 |
| fwereade__ | TheMue, and apart from anything else | 13:48 |
| TheMue | fwereade__: yes, that's why I used it first too. | 13:48 |
| TheMue | fwereade__: but there is more effort e.g. when collecting and merging document ids | 13:48 |
| fwereade__ | TheMue, if you don't read from channels you register with state/watcher, you block *all* watchers | 13:48 |
| fwereade__ | TheMue, except that there is no effort in this case | 13:49 |
| fwereade__ | TheMue, any change, flip the send bit on; any send, flip it off | 13:49 |
| TheMue | fwereade__: dunno if I got you right.but let me propose the newest version so i can show you where i'm stumbling. | 13:51 |
| fwereade__ | TheMue, sure, sgtm | 13:52 |
| TheMue | fwereade__: https://codereview.appspot.com/10148045 is in, i removed the job integration too | 13:56 |
| === teknico1 is now known as tekNico | ||
| TheMue | fwereade__: in state_test.go line 1342ff I do the two Destroy() and then get two change events. | 13:57 |
| TheMue | fwereade__, rogpeppe, mramm : hangout? | 14:02 |
| Makyo | fwereade__, ack, looking. | 14:02 |
| fwereade__ | TheMue, I don't think you can depend on getting exactly 2 events there; a correct implementation in combination with suitably pathological scheduling decisions could lead to the watcher read only completing once both the add and the remove are processed | 14:37 |
| TheMue | fwereade__: hmm, could you please rephrase | 14:38 |
| fwereade__ | TheMue, there are really 2 events happening, it is true | 14:41 |
| fwereade__ | TheMue, and almost always, because they are somewhat separated in time and the machine is probably not working too hard on these tests, the watcher's client will have the opportunity to read those 2 events independently | 14:42 |
| fwereade__ | TheMue, hmm, a thought | 14:42 |
| fwereade__ | TheMue, how many do you get if you Sync first, rather than StartSync? | 14:43 |
| TheMue | fwereade__: i'm listening ... | 14:43 |
| TheMue | fwereade__: will test, one sec | 14:43 |
| TheMue | fwereade__: yep, then it's only one | 14:46 |
| fwereade__ | TheMue, ok, and that *could* happen with StartSync, it's just less likely | 14:46 |
| TheMue | fwereade__: ah, now I understand, thanks. now I only have to see how to improve the testing for it. | 14:48 |
| fwereade__ | TheMue, put a couple of notes on https://codereview.appspot.com/10148045/ | 14:52 |
| TheMue | fwereade__: thank you | 14:52 |
| === tasdomas is now known as tasdomas_afk | ||
| fwereade__ | gaah, errors.NotFoundf appends " not found" to its message | 15:27 |
| fwereade__ | this is not consistent with actual usage in general | 15:28 |
| fwereade__ | NotFoundNamef("unit %q", unit) -> `unit "foo/2" not found` | 15:30 |
| fwereade__ | NotFoundf("ping pong %q blah", unit) -> `ping pong "foo/2" blah` | 15:30 |
| fwereade__ | would both be used | 15:31 |
| fwereade__ | rogpeppe, do those names seem ok to you? | 15:31 |
| fwereade__ | rogpeppe, errors.NounPhraseNotFoundf | 15:32 |
| fwereade__ | ;p | 15:32 |
| rogpeppe | fwereade__: i'd just have the latter. the " not found" suffix was only ever a convenience and i think it's no longer so convenient. | 15:32 |
| fwereade__ | rogpeppe, an awful lot of places include that explicitly | 15:32 |
| fwereade__ | rogpeppe, and they're either not tested properly or the tests are dumb because they're not catching "foo not found not found" | 15:33 |
| fwereade__ | rogpeppe, actually that all collapses to "not tested properly" doesn't it | 15:33 |
| fwereade__ | TheMue, mgz_, jam, danilos: any opinions on the above? | 15:34 |
| rogpeppe | fwereade__: i see only three places that use NotFoundf("xxx not found") | 15:34 |
| rogpeppe | fwereade__: and they all look like copypasta of the same code | 15:34 |
| rogpeppe | fwereade__: i suspect i was probably responsible originally :-) | 15:35 |
| fwereade__ | rogpeppe, heh, I saw 3 in the first dozen I looked at | 15:35 |
| fwereade__ | rogpeppe, clearly my data set was too small :) | 15:35 |
| rogpeppe | fwereade__: http://paste.ubuntu.com/5755219/ | 15:36 |
| fwereade__ | rogpeppe, the other aspect is charm.NotFoundError | 15:36 |
| fwereade__ | rogpeppe, they have custom messages that are quite nice | 15:36 |
| fwereade__ | rogpeppe, and I'd quite like to keep them | 15:36 |
| fwereade__ | rogpeppe, but the current NotFoundf seems like a good common case so it can should probably keep its name | 15:37 |
| fwereade__ | rogpeppe, errors.NotFoundMessagef()? | 15:37 |
| fwereade__ | rogpeppe, for the custom cases? | 15:37 |
| rogpeppe | fwereade__: errors.NotFoundError{msg} ? | 15:38 |
| fwereade__ | rogpeppe, the f is useful there too | 15:38 |
| fwereade__ | rogpeppe, ah sorry mistook you | 15:38 |
| rogpeppe | fwereade__: BTW there's an error field in NotFoundError which is never used | 15:38 |
| fwereade__ | rogpeppe, ha | 15:39 |
| fwereade__ | rogpeppe, best drop it then | 15:39 |
| rogpeppe | fwereade__: same with unauthorized error | 15:39 |
| rogpeppe | fwereade__: i think it's a hangover from its goose origins | 15:39 |
| fwereade__ | rogpeppe, ok, I'll strip those too then, thanks | 15:39 |
| rogpeppe | fwereade__: perhaps: have only one NotFoundf helper, same as current. but if you want to create a "not found" error with a custom message, do so. | 15:40 |
| fwereade__ | rogpeppe, seems reasonable | 15:41 |
| rogpeppe | fwereade__: some time i'll have some more time to work up my new errors package. it was going in quite a nice direction, i think. | 15:41 |
| rogpeppe | fwereade__: i found that rather than error codes, a useful concept was a "diagnosis" | 15:42 |
| fwereade__ | rogpeppe, sounds interesting | 15:42 |
| fwereade__ | rogpeppe, there's definitely a lot of room for advancement in that whole field :) | 15:42 |
| rogpeppe | fwereade__: so an error could change but its diagnosis might remain the same. and in particular, a diagnosis could be an error itself. so to find out if something's a not-found error, you might do errors.Diagnosis(err) == somepkg.ErrNotFound | 15:43 |
| fwereade__ | rogpeppe, or indeed somepkg.ErrorHasSomeObscureProperty(errors.Diagnosis(err)) | 16:00 |
| fwereade__ | rogpeppe, ofc the really hard part will be resisting the temptation to s/err/murder/ | 16:00 |
| fwereade__ | rogpeppe, btw, another thing is really bugging me here | 16:01 |
| fwereade__ | rogpeppe, NotFound vs Unauthorized | 16:01 |
| fwereade__ | rogpeppe, can you think of any major consequences to s/Unauthorized/NotAuthorized/? | 16:02 |
| fwereade__ | rogpeppe1, hey, UnauthorizedError *does* use the error field, but not in a very sane way | 16:08 |
| rogpeppe1 | fwereade__: ah, i didn't notice | 16:09 |
| fwereade__ | rogpeppe1, it's in state/open.go | 16:09 |
| fwereade__ | rogpeppe1, ISTM that the first usage is clear gibberish | 16:09 |
| fwereade__ | rogpeppe1, and the second one has no reason to keep the error lying around | 16:09 |
| rogpeppe1 | fwereade__: yeah, they both look dodgy to me | 16:11 |
| fwereade__ | rogpeppe1, ok, it's used so little I'm going to make it consistent, if you have no objection to "not authorized" supplanting "unauthorized" | 16:12 |
| fwereade__ | rogpeppe1, the second one looks like it has a purpose tbh | 16:12 |
| rogpeppe1 | fwereade__: yeah, i was just thinking that | 16:12 |
| rogpeppe1 | fwereade__: but perhaps it should be: "cannot log in to juju database: not authorized: %v" | 16:13 |
| fwereade__ | rogpeppe1, NotAuthorizedf("foo %q", "bar") -> `foo "bar" not authorized` | 16:13 |
| fwereade__ | rogpeppe1, maybeUnauthorized(err error, action string) | 16:13 |
| fwereade__ | rogpeppe1, NotAuthorizedf(action) | 16:13 |
| rogpeppe1 | fwereade__: we should use either Unauthorized or NotAuthorized consistently at least | 16:13 |
| fwereade__ | rogpeppe1, Errorf("%s failed: %v", action, err) | 16:14 |
| fwereade__ | rogpeppe1, sure, that was just a thinko | 16:14 |
| rogpeppe1 | fwereade__: i *think* i prefer Unauthorized, for the function names at least | 16:14 |
| rogpeppe1 | fwereade__: in a sentence, i'm happy to use "not authorized" when it reads better | 16:14 |
| fwereade__ | rogpeppe1, even considering that Unfound would be an abomination unto the lord? | 16:14 |
| rogpeppe1 | fwereade__: sure | 16:15 |
| rogpeppe1 | fwereade__: they don't have to be the same | 16:15 |
| fwereade__ | rogpeppe1, no, but there's definitely some degree of value in consistency too | 16:15 |
| rogpeppe1 | fwereade__: i'm not sure there's any particular virtue in that particular consistency. the moment i find myself typing "NotAuthorizedError" by accident, i'll concede though :-) | 16:16 |
| fwereade__ | rogpeppe1, "<noun> not found", "<action> not authorized" both seem to read just fine to me | 16:16 |
| fwereade__ | rogpeppe1, that's a matter of personal habit alone, surely | 16:17 |
| fwereade__ | rogpeppe1, consistency is in itself a virtue | 16:17 |
| rogpeppe1 | fwereade__: "not authorized" doesn't work so well as an adjective tho | 16:17 |
| rogpeppe1 | fwereade__: although it's unavoidable with "not found" | 16:18 |
| fwereade__ | rogpeppe1, it's just harder to appreciate the value of imposing consistency when it's code you already know | 16:18 |
| rogpeppe1 | fwereade__: if you feel strongly about NotAuthorizedError, go for it | 16:18 |
| fwereade__ | rogpeppe1, strongly enough, yeah -- thanks :) | 16:19 |
| rogpeppe1 | fwereade__: though while you're about it, errors.NotAuthorized might be better when errors.NotAuthorizedError | 16:19 |
| rogpeppe1 | s/when/than | 16:19 |
| fwereade__ | rogpeppe1, then NotAuthorizedf and NotFoundf echo one another | 16:19 |
| fwereade__ | rogpeppe1, foo not bar | 16:19 |
| fwereade__ | rogpeppe1, oh and finally: errors.NotAuthorizedError vs errors.NotAuthorized; errors.IsNotAuthorizedError vs errors.IsNotAuthorized | 16:37 |
| fwereade__ | rogpeppe1, any point keeping the stuttering? | 16:37 |
| rogpeppe1 | fwereade__: i don't think so | 16:37 |
| fwereade__ | rogpeppe1, cool | 16:38 |
| rogpeppe1 | fwereade__: i thought about mentioning it but i didn't want to add yet more negativity... | 16:38 |
| fwereade__ | rogpeppe1, funny how a liitle "this isn't quite consistent, let's just fix that one bit" can balloon | 16:38 |
| rogpeppe1 | fwereade__: oh yes | 16:39 |
| * TheMue is not happy about the cleaner test yet. it needs about 6 seconds. | 16:49 | |
| jtv | Anyone up for a second review of my branch? It's just some forgotten imports added to the azure skeleton, and some unqualified class names qualified with their package name: https://codereview.appspot.com/10184043/ | 17:18 |
| mgz_ | jtv, it would seem resaonable to carry over one of the earlier +1s and submit | 17:20 |
| jtv | Can I do that? | 17:20 |
| mgz_ | or get fwereade__ to rubberstamp | 17:21 |
| jtv | Just the sort of thing I was hoping to accomplish here, really. :) | 17:21 |
| jtv | Oh never mind. I'll just submit as-is then. | 17:23 |
| jtv | I wonder what this error output from lbox means... | 17:28 |
| jtv | error: use of closed network connection | 17:28 |
| jtv | Rietveld: https://codereview.appspot.com/10184043 | 17:28 |
| jtv | The lbox command still returns success (i.e. zero), but I think it just always does that, regardless. | 17:28 |
| rogpeppe1 | g'night all | 17:30 |
| TheMue | rogpeppe1: n8 | 17:30 |
| TheMue | fwereade__: still available? | 17:31 |
| jtv | nn robbiew | 17:32 |
| jtv | I mean, rogpeppe1 | 17:32 |
| jtv | Damn over-eager tab completion... | 17:32 |
| robbiew | ;-) | 17:32 |
| jtv | Sorry! :) | 17:32 |
| robbiew | np | 17:33 |
| mgz_ | jtv: not seen that error before myself | 17:33 |
| jtv | I've noticed that relatively often, given how rarely I've used lbox: weird errors, different every time, and if you keep retrying it succeeds eventually — but you can't ever really tell because it doesn't report errors properly. | 17:34 |
| jtv | FWIW it does look as if lbox failed there, it just doesn't seem to have checked for the error condition. When I retried, it succeeded. | 17:45 |
| jam | jtv: Are you using precise? That looks like the error I used to get when compiling with go 1.0 (updating to go 1.0.3 from ppa:gophers/go | 17:58 |
| jam | fixed it) | 17:58 |
| jtv | jam: no, I'm on Raring. | 18:00 |
| jtv | Go version is go1.0.2. | 18:00 |
| jtv | Do I need to update to 1.0.3? | 18:00 |
| jam | jtv: I think danilos is using your same configuration successfully, but I'm not sure | 18:16 |
| andreas__ | hi guys, has anyone seen this error before? It's from the bootstrap node: http://pastebin.ubuntu.com/5755877/ | 19:02 |
| andreas__ | on aws, using juju-core trunk | 19:02 |
| andreas__ | juju bootstrap worked, one instance running, then I did a bunch of deploys | 19:03 |
| andreas__ | juju status says they are all pending, but ec2-describe-instances still only sees the bootstrap instance, no word on the others | 19:03 |
| andreas__ | I didn't bootstrap with --upload-tools, I wonder if that oculd be it | 19:03 |
| fwereade__ | andreas__, I suspect you're using trunk but not running --upload-tools | 19:23 |
| fwereade__ | andreas__, ha, yes | 19:23 |
| andreas__ | ok, I destroyed the env and bootstrapped again with --upload-tools, it's working now | 19:24 |
| === makyo_ is now known as Makyo | ||
| thumper | morning | 20:55 |
| thumper | fwereade__: I have some questions around the provisioner change | 21:46 |
| thumper | fwereade__: what *should* we do on bad config? | 21:47 |
| * fwereade__ has a brief flashback | 21:48 | |
| fwereade__ | thumper, I think the plan was to keep the original environment around and to continue to use it | 21:49 |
| thumper | the tests asserted that the old environment bits were saved | 21:49 |
| thumper | fwereade__: and regarding failure... | 21:49 |
| thumper | fwereade__: when there was invalid config, the "get state addresses" failed | 21:50 |
| fwereade__ | thumper, ok; so, failure to provision should be communicated back via SetStatus (for now) and SetInstanceError(soon) | 21:50 |
| thumper | hence the magic bits | 21:50 |
| fwereade__ | thumper, huh, why is the bad environ causing that? I thought we got the addresses from state now | 21:50 |
| thumper | um... | 21:51 |
| thumper | not sure why | 21:51 |
| thumper | but it did | 21:51 |
| * fwereade__ has a suspicious | 21:51 | |
| thumper | I didn't really think too hard | 21:51 |
| thumper | probably should have | 21:51 |
| fwereade__ | might be worth another look, yeah | 21:51 |
| thumper | but assumed it was expected | 21:51 |
| fwereade__ | I think we still have issues around that though | 21:51 |
| fwereade__ | provisioning failure is fine as above | 21:52 |
| * thumper nods | 21:52 | |
| thumper | I'm going to focus on lxc for a bit, perhaps back to the provisioner work when I need a break | 21:52 |
| fwereade__ | unprovisioning failure should be logged and ignored, we'll try again next time we hit processMachines | 21:53 |
| fwereade__ | instance-listing failure though is most unhelpful and the best course of action is most unclear | 21:53 |
| thumper | fwereade__: so if I set an error on the machine saying "couldn't provision", does it come back in the next watcher list? | 21:54 |
| thumper | fwereade__: also, another Q | 21:54 |
| fwereade__ | at the moment it's handled in the provisioner by checking status itself | 21:54 |
| fwereade__ | the status path is overloaded | 21:54 |
| thumper | fwereade__: if I was to write a small app to test my lxc stuff on machine 0 of my bootstrapped ec2 | 21:54 |
| thumper | fwereade__: what is the quickest way to get state bits? | 21:55 |
| fwereade__ | thumper, to get access to a state.State in code? | 21:55 |
| fwereade__ | thumper, for now, snarf machine 0's state credentials by making an environs/agent.Conf with sane dataDir and tag and reading from there | 21:56 |
| fwereade__ | thumper, then state.Open() and you're away | 21:57 |
| thumper | hmm... | 21:57 |
| thumper | there is obviously already an agent.conf file | 21:57 |
| thumper | in /var/lib/juju/agents | 21:57 |
| thumper | but thanks, will poke a little | 21:57 |
| fwereade__ | thumper, the Conf type is a bit odd imo | 21:58 |
| thumper | ok | 21:58 |
| thumper | wallyworld__: ping | 22:19 |
| wallyworld__ | thumper: hi | 22:20 |
| thumper | wallyworld__: how close are you to landing the "make a container in state" work? | 22:20 |
| thumper | I'd love to be able to poke it | 22:20 |
| wallyworld__ | already done | 22:20 |
| wallyworld__ | just doing a trivial followup for the Tag() change | 22:21 |
| thumper | wallyworld__: awesome | 22:22 |
| thumper | wallyworld__: I'm writing some code to create a test app to create a container based on that work | 22:22 |
| wallyworld__ | thumper: i hate mongo | 22:22 |
| * thumper isn't a fan either | 22:22 | |
| wallyworld__ | why the f*ck we have to work around it's tranaction limitations is beyind me | 22:22 |
| thumper | the thing is, we are storing structured data | 22:23 |
| thumper | highly relational structured data | 22:23 |
| thumper | why we are shoving that into mongo and trying to do transactions on it is beyond me | 22:23 |
| * wallyworld__ sighs | 22:23 | |
| wallyworld__ | stupid design decision | 22:23 |
| wallyworld__ | oh look, mongo is new and shiny, let's use that | 22:24 |
| thumper | it is good for rapidly evolving structures | 22:24 |
| * thumper shrugs and goes back to wokr | 22:24 | |
| wallyworld__ | that can be done with rwlational dbs too | 22:24 |
| wallyworld__ | i know, i've done it | 22:24 |
| thumper | wallyworld__: does state.Machine have a getParent? | 22:25 |
| thumper | or parent machine id getter? | 22:26 |
| wallyworld__ | thumper: not yet. it has a Containers(). will add Parent() now | 22:26 |
| wallyworld__ | there is a Id() | 22:26 |
| thumper | wallyworld__: cool, because I need it | 22:26 |
| thumper | I'm ok with parent returning the machineId | 22:26 |
| wallyworld__ | thumper: while you are waiting https://codereview.appspot.com/10019049 - very trivial | 22:26 |
| * thumper looks | 22:27 | |
| thumper | trivial, one ack is good enough | 22:28 |
| thumper | wallyworld__: so the other bit has landed? | 22:29 |
| thumper | wallyworld__: and I can use it now? | 22:29 |
| wallyworld__ | yes | 22:29 |
| thumper | \o/ | 22:29 |
| wallyworld__ | i did it 90 mins ago | 22:29 |
| wallyworld__ | Parent() won't take long | 22:29 |
| wallyworld__ | thumper: https://codereview.appspot.com/10203043 | 22:42 |
| wallyworld | thumper: fwereade__: oh joy. our "unit" tests connect to the real charm store :-( | 22:55 |
| thumper | haha | 22:56 |
| wallyworld | not hahaha. very sad :-( | 22:56 |
| wallyworld | i noticed because my connection dropped out when runnign the tests | 22:56 |
| wallyworld | the tests seem to be taking a looooong time of late | 22:56 |
| fwereade__ | wallyworld, yeah, I just noticed some of those myself | 22:59 |
| * wallyworld sighs again | 22:59 | |
| fwereade__ | wallyworld, the config-7 branch does at least add a MockCharmStore that should be useful in such situations | 22:59 |
| wallyworld | \o/ | 22:59 |
| wallyworld | thumper: there are ~50 calls to Machine.st.Machine() , so any move to use the API will need to address those. adding a new call site shouldn't matter for the Parent() call | 23:01 |
| thumper | wallyworld: fair enough | 23:02 |
| wallyworld | thumper: i don't follow the other comment though | 23:02 |
| thumper | that is the only comment | 23:02 |
| wallyworld | btw, there is a parentId(), but it is unexported | 23:02 |
| wallyworld | i can export it i guess | 23:02 |
| thumper | hmm... | 23:02 |
| wallyworld | thumper: | 23:02 |
| wallyworld | Unfortunately this is making an assumption that doesn't always hold. | 23:02 |
| wallyworld | If I am the provisioner, and I have a state.Machine instance, I won't | 23:02 |
| wallyworld | necessarily have access to state. | 23:02 |
| wallyworld | </quote> | 23:03 |
| thumper | right, from the api, it won't | 23:03 |
| thumper | what happens now if someone gets a machine from the api? | 23:03 |
| wallyworld | NFI. I think the machine client from the api is different to state/machine - the client just delegates stuff through to the backend | 23:04 |
| wallyworld | so maybe I need to add Parent() to the api client as well | 23:04 |
| wallyworld | i've not used the api stuff at all yet | 23:05 |
| thumper | me neither | 23:05 |
| wallyworld | thumper: do you need Parent() exposed via the api yet? | 23:05 |
| thumper | fwereade__: Q regarding agent passwords | 23:05 |
| wallyworld | thumper: i can add it, but can we wait till it's needed? | 23:06 |
| thumper | fwereade__: agent.Conf.OpenState returns a new password | 23:06 |
| * fwereade__ sighs | 23:06 | |
| thumper | fwereade__: if I'm just writing a noddy app to poke stuff, do I need to care? | 23:06 |
| wallyworld | thumper: i'd rather not bloat the current Machine client with methods we don't need | 23:06 |
| thumper | wallyworld: ack | 23:06 |
| wallyworld | thumper: so if you agree, maybe you want to +1 ? | 23:06 |
| thumper | wallyworld: ok | 23:07 |
| wallyworld | thumper: so now you have all the goodies you want to experient i think | 23:07 |
| fwereade__ | thumper, bleh, it's all done pretty early on | 23:07 |
| thumper | fwereade__: yes, the OpenState connects with the old password, generates a new random one, and passes that back | 23:07 |
| fwereade__ | thumper, maybe best to wait until the machine agent has set itself to started though | 23:08 |
| thumper | fwereade__: I'm assuming I can happily ignore the new password? | 23:08 |
| thumper | fwereade__: this is my test app | 23:08 |
| thumper | not anything that is likely to survive | 23:08 |
| fwereade__ | thumper, yeah, if it gives you one you should be safe to ignore it | 23:08 |
| thumper | fwereade__: effectively I'm writing a small app to call into my container work to see the impact on the bootstrap node | 23:08 |
| wallyworld | thumper: the Parent() stuff is trivial also - want me to land so you can use it? | 23:08 |
| fwereade__ | thumper, and if you start the app again later it'll pick up the fresh value written by the other one | 23:09 |
| thumper | wallyworld: funnily, I don't need it quite yet, but I will do for the provisioner work | 23:09 |
| wallyworld | ok | 23:09 |
| thumper | wallyworld: but I'm still at the container bits | 23:09 |
| thumper | fwereade__: can you look at wallyworld's machine parent branch? | 23:10 |
| wallyworld | it's way past his bedtime | 23:10 |
| thumper | hmm... | 23:10 |
| thumper | ec2 still hasn't bootstrapped my node | 23:10 |
| fwereade__ | I'll see if I remember in 5 mins | 23:10 |
| wallyworld | thumper: i think i'll do some work to make juju status output container info | 23:10 |
| thumper | wallyworld: sounds good | 23:11 |
| fwereade__ | thumper, upload-tools? | 23:11 |
| thumper | fwereade__: no i forgot... | 23:11 |
| thumper | oops | 23:11 |
| * wallyworld thinks upload-tools should always happen for dev versions of juju | 23:12 | |
| fwereade__ | thumper, that said... we have actually broken compatibility, haven't we | 23:12 |
| thumper | have we? | 23:12 |
| fwereade__ | thumper, we can no longer bootstrap 1.10 | 23:13 |
| fwereade__ | (except with 1.10 client, that is) | 23:13 |
| thumper | fwereade__: what have we done to cause that? | 23:13 |
| fwereade__ | thumper, added a field to the environment config | 23:14 |
| thumper | which field? | 23:14 |
| fwereade__ | thumper, state-port and api-port I think | 23:15 |
| thumper | ah... | 23:15 |
| fwereade__ | thumper, I'm hearing that siren song of "go on, hardcode it" and I want to slap myself | 23:15 |
| thumper | :) | 23:16 |
| wallyworld | wouldn't there have been defaults used, so if the configs were missing, stuff would work? | 23:16 |
| thumper | fwereade__: will panic cause defers to run? | 23:16 |
| fwereade__ | thumper, but if the values are *present* in older code | 23:17 |
| fwereade__ | thumper, yes | 23:17 |
| fwereade__ | wallyworld, but if the values are present in older code, eg the machine agent running 1.10, it will barf | 23:17 |
| wallyworld | ah, bollocks, right | 23:17 |
| fwereade__ | wallyworld, for that matter, an environments.yaml valid for 1.11 is not necessarily so for 1.10 | 23:20 |
| wallyworld | cause we barf on unknown config items | 23:20 |
| wallyworld | maybe we sould be more tolerant of such data | 23:21 |
| fwereade__ | wallyworld, yeah, we should just drop that madness | 23:21 |
| fwereade__ | wallyworld, log unknown settings and move on | 23:21 |
| wallyworld | toleranrt reads, strict writes | 23:21 |
| thumper | +1 | 23:21 |
| wallyworld | yep | 23:21 |
| thumper | make it so | 23:21 |
| * wallyworld wonders why we didn't do that | 23:21 | |
| fwereade__ | thumper, doesn't fix today's problem though, that 1.10 is already out doing its badness in the wild | 23:22 |
| thumper | wallyworld: TODO: add more help for "add-machine" | 23:22 |
| * thumper nods | 23:22 | |
| wallyworld | thumper: i didn't see an obvious example to cargo cult of how to add extensive help | 23:22 |
| thumper | wallyworld: how do I add a new container to machine 0? | 23:23 |
| thumper | wallyworld: in the description | 23:23 |
| thumper | just some examples would be good | 23:23 |
| wallyworld | juju add-machine 0/lxc | 23:23 |
| wallyworld | will do it as a driveby | 23:23 |
| wallyworld | thumper: let me know if above ^^^^ doesn't work for you | 23:24 |
| thumper | about to try | 23:24 |
| * wallyworld runs away | 23:24 | |
| wallyworld | lalalalalala | 23:24 |
| thumper | wallyworld: how will I know if it succeeds? | 23:25 |
| wallyworld | thumper: juju status in a day's time :-P | 23:26 |
| wallyworld | actually, if it exists without error | 23:26 |
| wallyworld | it will have updated the state | 23:26 |
| wallyworld | but nothing acts on it yet | 23:26 |
| wallyworld | actually, juju status should show it | 23:27 |
| wallyworld | since containers are machines | 23:27 |
| wallyworld | but the nesting etc will not be there yet | 23:27 |
| wallyworld | make sense? | 23:27 |
| wallyworld | thumper: how'd you go? | 23:31 |
| thumper | wallyworld: sorry, doggy call of nature | 23:37 |
| thumper | $ juju add-machine 0/lxc | 23:37 |
| thumper | error: cannot add a new container: transaction aborted | 23:37 |
| wallyworld | i guessed :-) | 23:37 |
| wallyworld | hmmm. | 23:37 |
| thumper | running with debug | 23:37 |
| wallyworld | machine 0 exists? | 23:37 |
| thumper | nah, that's all I get | 23:37 |
| thumper | 0 is the bootstrap node | 23:37 |
| wallyworld | sure. you've bootstrapped i guess | 23:38 |
| thumper | yep, 0 exists | 23:38 |
| thumper | wallyworld: have you actually tried this? | 23:38 |
| wallyworld | tests yes | 23:38 |
| wallyworld | let me check the tests | 23:38 |
| wallyworld | thumper: see TestAddContainerToExistingMachine in addmachine_test.go - that's what you're trying | 23:40 |
| wallyworld | the test adds to machine 1 though | 23:40 |
| thumper | right | 23:41 |
| wallyworld | maybe the bootstrap node state document is missong something due to how it was created | 23:41 |
| wallyworld | that test would still pass even with machine 0 since AddMachine() does the right thing | 23:42 |
| thumper | wallyworld: but machine 0 hasn't been bootstrapped in the tests | 23:42 |
| * thumper tries with just /lxc | 23:42 | |
| wallyworld | thumper: it wouldn;t be that - what i mean is that the container ref record may not have been created | 23:42 |
| fwereade__ | wallyworld, https://codereview.appspot.com/10203043/ reviewed | 23:43 |
| wallyworld | thumper: you could also try add-machine and then add-machine <id>/lxc | 23:43 |
| wallyworld | fwereade__: thanks | 23:43 |
| thumper | addmachine.go:92 created "lxc" container on machine 1/lxc/0 | 23:44 |
| thumper | wallyworld: that is from 'add-machine /lxc' | 23:44 |
| wallyworld | that's as expected | 23:44 |
| wallyworld | fwereade__: what if nil is a legitimate result though? | 23:45 |
| thumper | $ juju add-machine 1/lxc --debug | 23:45 |
| thumper | running | 23:45 |
| thumper | 1/lxc/1 there too now | 23:45 |
| thumper | wallyworld: so it looks like a bootstrap issue | 23:45 |
| thumper | wallyworld: care to fix? | 23:45 |
| * thumper works with machine 1 | 23:45 | |
| wallyworld | thumper: cool, so perhaps the bootstrap machine state entry is created via a different api | 23:45 |
| fwereade__ | wallyworld, by convention you would handle the specific error that encodes the information that would otherwise be encoded in the nil return | 23:46 |
| wallyworld | an api that doesn;t update the container ref record properly | 23:46 |
| thumper | fwereade__: I see that 'juju scp ' needs more descriptive help too | 23:46 |
| thumper | fwereade__: how do I copy something from local machine to machine 1? | 23:46 |
| wallyworld | fwereade__: but it's not an error condition - it just means the machine's parent is legitimatey nil | 23:46 |
| thumper | wallyworld: probably | 23:46 |
| wallyworld | nil can be a valid value for things | 23:46 |
| fwereade__ | wallyworld, oh, hell, I thought InjectMachine used all the same code paths | 23:46 |
| fwereade__ | wallyworld, think of it on a pure code level | 23:46 |
| fwereade__ | wallyworld, it's a useful convention because, if it's followed, you don't need to have context on Machine to know that code using Machine.Parent will be valid | 23:47 |
| fwereade__ | wallyworld, and I think all of us to a greater or lesser extent have that pattern somewhat embedded | 23:48 |
| wallyworld | fwereade__: so you would prefer Machine.Parent() to return an err if there is not parent? | 23:48 |
| fwereade__ | wallyworld, I'd be less bothered if it wasn't exported | 23:48 |
| fwereade__ | wallyworld, yeah, for convention's sake if nothing else | 23:49 |
| thumper | wallyworld: I'd be happy just to have ParentId exported | 23:49 |
| thumper | wallyworld: with "" meaning no parent | 23:49 |
| fwereade__ | wallyworld, that said ParentId() (string, bool) seems perfect to me | 23:49 |
| wallyworld | fwereade__: i'll change it, but i think special casing nil ike this is wrong | 23:49 |
| thumper | wallyworld, fwereade__: why bool? | 23:49 |
| thumper | if empty, then obviously not there | 23:49 |
| fwereade__ | thumper, same logic as the err case really -- having a guarantee of validity on a separate channel is a good convention | 23:50 |
| thumper | hmm... whatever | 23:50 |
| thumper | not sure I agree | 23:50 |
| thumper | but I'll go with it | 23:50 |
| thumper | if it is current convention | 23:50 |
| fwereade__ | thumper, wallyworld: it's debatable, but conventional | 23:50 |
| thumper | fwereade__: so, back to 'juju scp' | 23:51 |
| thumper | fwereade__: from local to machine 1 | 23:51 |
| thumper | no examples in the built in help | 23:51 |
| * wallyworld changes it to ParentId and goes to the corner to sulk | 23:51 | |
| thumper | hmm... suppose I could just read the source | 23:51 |
| fwereade__ | thumper, er, try `juju scp /path/to/file 0:/target/path` or something? | 23:51 |
| thumper | trying $ juju scp ~/go/bin/test-lxc 1:~ | 23:52 |
| thumper | well, it is doing something | 23:52 |
| fwereade__ | jolly good :) | 23:53 |
| thumper | fwereade__: unfortunately I can't create a container on the bootstrap node right now | 23:53 |
| thumper | fwereade__: wallyworld will work out why :) | 23:53 |
| wallyworld | thumper: yes i will. might include a fix as a driveby in the parent id branch | 23:54 |
| thumper | wallyworld: sure, if it is small, if bigger, perhaps a separate branch would be better | 23:54 |
| fwereade__ | thumper, haha | 23:54 |
| wallyworld | thumper: yep | 23:55 |
| * thumper sighs | 23:56 | |
| thumper | wrong arg | 23:56 |
| thumper | now wait a minute while I upload my new test app | 23:56 |
| thumper | seems my upload starts fast and gets slower | 23:57 |
| thumper | NFI way | 23:57 |
| thumper | hmm... it is doing something | 23:59 |
| thumper | probably downloading the ubuntu-cloud template | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!