| davecheney | sinzui: ping | 00:24 |
|---|---|---|
| waigani | thumper: you about? | 00:34 |
| thumper | ya | 00:34 |
| waigani | http://pastebin.ubuntu.com/7187528/ | 00:35 |
| waigani | the test passed for me | 00:35 |
| waigani | just ran it locally, not ppc obviously | 00:35 |
| davecheney | wallyworld_: which gccgo ? | 00:36 |
| waigani | but i thought you said that just using gccgo would cause it to fail | 00:36 |
| davecheney | sorry | 00:36 |
| davecheney | waigani: | 00:36 |
| waigani | davecheney: gcc version 4.9.0 20140330 | 00:36 |
| davecheney | waigani: your ppc details are incoming | 00:36 |
| thumper | waigani: now we need to get you set up on the ppc machine | 00:36 |
| waigani | wallyworld_: I'm stealing your identity ;) | 00:36 |
| thumper | waigani: your login has been setup... | 00:36 |
| wallyworld_ | nothing worth stealing really | 00:36 |
| thumper | waigani: I can add you as an ssh user to my vm | 00:36 |
| davecheney | thumper: waigani got a new vm for waigani | 00:37 |
| thumper | davecheney: already? | 00:37 |
| waigani | thumper: okay. Didn't you say it failed for you on your local machine? | 00:37 |
| thumper | yeah... | 00:37 |
| waigani | davecheney: nice :) | 00:37 |
| thumper | waigani: run the entire package | 00:37 |
| davecheney | waigani: what lp is this again ? | 00:38 |
| waigani | thumper: all pass | 00:38 |
| thumper | hmm... | 00:38 |
| thumper | waigani: definitely need to get you running that on power | 00:38 |
| waigani | davecheney: https://bugs.launchpad.net/juju-core/+bug/1300032 | 00:38 |
| _mup_ | Bug #1300032: charm: gccgo test failure <gccgo> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1300032> | 00:38 |
| thumper | davecheney: what is that line to import ssh keys from lp? | 00:38 |
| davecheney | waigani: yeah that will pass on your local macine | 00:38 |
| davecheney | disconnect from your network | 00:38 |
| waigani | ah | 00:39 |
| davecheney | or export http_proxy="www.microsoft.com" | 00:39 |
| davecheney | or something | 00:39 |
| davecheney | thumper: ssh-copy-id | 00:39 |
| davecheney | ssh-import-id | 00:39 |
| davecheney | i forget | 00:39 |
| davecheney | i think the latter | 00:39 |
| davecheney | ssh-import-id $LAUNCHPAD | 00:39 |
| thumper | kk | 00:39 |
| davecheney | waigani: your machine is winton-09 | 00:40 |
| davecheney | instructions are here -> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit | 00:40 |
| davecheney | 11:40 < davecheney> waigani: your machine is winton-09 | 00:44 |
| davecheney | 11:40 < davecheney> instructions are here -> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit | 00:44 |
| waigani | davecheney: cheers. I've got a screen full of errors now :) yay | 00:44 |
| Valduare | hows this coming https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-arm-service-orchestration | 00:49 |
| Valduare | and could i use devices such as http://www.amazon.com/Rikomagic-Android-Cortex-A9-External-Miracast/dp/B00GPJLVQW | 00:49 |
| davecheney | Valduare: wrong channel made | 00:51 |
| davecheney | mate | 00:51 |
| davecheney | sorry | 00:51 |
| Valduare | this is where the developers of juju are? | 00:52 |
| Valduare | the guys who are implementing juju for arm or is there a #juju-arm channel | 00:52 |
| davecheney | Valduare: we write juju | 00:52 |
| davecheney | we don't know anything about ubuntu on arm | 00:52 |
| davecheney | specfically | 00:52 |
| davecheney | try #server | 00:52 |
| davecheney | or #ubuntu | 00:53 |
| Valduare | ok | 00:53 |
| davecheney | Valduare: sorry, i can't really tell you who to talk to, only that we're not the right people | 00:54 |
| Valduare | someone here has to be interested in testing juju on arm? | 00:55 |
| Valduare | doesnt make sense there wouldnt lol | 00:55 |
| thumper | Valduare: there is... | 00:59 |
| thumper | Valduare: mwhudson looks at arm of some form | 00:59 |
| thumper | Valduare: depends what you are wanting to know | 00:59 |
| thumper | axw: hey, here on time? | 00:59 |
| axw | thumper: yo, I am in fact | 00:59 |
| thumper | cool | 00:59 |
| Valduare | thumper: im interested in some suggestions for arm servers that will be supported well | 01:00 |
| Valduare | i only have experience with mk808 style hdmi stick devices heh | 01:00 |
| waigani | hmm... I'm getting: ssh_exchange_identification: Connection closed by remote host | 01:06 |
| davecheney | waigani: add a -vv on there | 01:15 |
| axw | thumper: sorry, closed wrong tab | 01:20 |
| waigani | davecheney: emailed you output | 01:21 |
| davecheney | waigani: something between you an batuan is blocking port 22 | 01:22 |
| davecheney | waigani: is tim using the internet again | 01:23 |
| waigani | heh | 01:23 |
| davecheney | c.Assert(a, gc.DeepEquals, []string{"amd64"}) | 01:34 |
| davecheney | ... obtained []string = []string{"i386", "amd64"} | 01:34 |
| davecheney | ... expected []string = []string{"amd64"} | 01:34 |
| davecheney | OOPS: 81 passed, 1 FAILED | 01:34 |
| davecheney | --- FAIL: TestMAAS (11.60 seconds) | 01:34 |
| davecheney | FAIL | 01:34 |
| davecheney | FAIL launchpad.net/juju-core/provider/maas 11.699s | 01:34 |
| davecheney | ffs | 01:34 |
| mwhudson | Valduare: there is still (!) no really compelling arm server product | 01:35 |
| davecheney | mwhudson: highbank ? | 01:35 |
| mwhudson | davecheney: calxeda went bust | 01:35 |
| mwhudson | so if you have one, sure | 01:35 |
| mwhudson | but you can't get any more... | 01:35 |
| Valduare | mwhudson: though not a lot of ram ie 2 gigs each, these mk902 devices look pretty neat | 01:35 |
| davecheney | Valduare: when the ubuntu server team look at those arm boards | 01:36 |
| davecheney | the lack of an onboard LOM or IPMI controllre | 01:36 |
| davecheney | pretty much knock them out of contention | 01:36 |
| mwhudson | Valduare: just check that the ethernet isn't some usb2 rubbish | 01:36 |
| mwhudson | yes, and that | 01:36 |
| Valduare | ah | 01:36 |
| Valduare | I was talking to the linux-sunxi guys about a u-boot that could pause and wait for the kernel over network | 01:36 |
| davecheney | Valduare: sure | 01:37 |
| davecheney | but there is a difference between being able to do that in software | 01:37 |
| davecheney | and being able to do it in hardware | 01:37 |
| davecheney | and it's that distinction that is what draws the line between consumer grade and server grade | 01:37 |
| davecheney | at least in my mind | 01:37 |
| Valduare | aye | 01:37 |
| mwhudson | if you want to solder things and play around and have fun, then yes, go for it | 01:38 |
| mwhudson | but it's not something you put in a data centre | 01:38 |
| Valduare | i dream of running my small DC on solar one day lol | 01:38 |
| davecheney | mwhudson: except in our data center :) | 01:38 |
| davecheney | i've heard that is *exactly* how the lp arm builders work :P | 01:38 |
| mwhudson | davecheney: not any more, we have some highbanks now :-) | 01:38 |
| mwhudson | lucky we got them in time | 01:38 |
| * davecheney doffs hat | 01:38 | |
| mwhudson | but yes, we did have panda boards in our dc | 01:38 |
| mwhudson | is _really_ hated them | 01:39 |
| davecheney | mwhudson: yeah | 01:39 |
| davecheney | mwhudson: i love my panda | 01:39 |
| davecheney | i've never had a more reliable builder | 01:39 |
| Valduare | what do you think of panda board vs mk902 type device | 01:39 |
| mwhudson | although probably not as much as some of the strange things we had before | 01:39 |
| davecheney | Valduare: I don't have much experience with mk902s | 01:39 |
| mwhudson | Valduare: panda is better supported for running ubuntu-type distros on i think | 01:39 |
| davecheney | i've used the A20's from cubie | 01:39 |
| davecheney | imx6's | 01:40 |
| davecheney | Ti's | 01:40 |
| davecheney | and the exegons | 01:40 |
| davecheney | whatever | 01:40 |
| davecheney | stupid name | 01:40 |
| davecheney | -1 for marketing a product that nobody can spell | 01:40 |
| Valduare | lol | 01:40 |
| Valduare | then i was looking at these little beasts http://www.ebay.com/itm/FREE-SHIP-Supermicro-A1SAM-2750F-O-Intel-Atom-C2750-DDR3-SATA3-V-4GbE-/191091952279?pt=LH_DefaultDomain_0&hash=item2c7df7ca97 | 01:40 |
| Valduare | 8 core atom - 64 gigs ecc ram | 01:40 |
| Valduare | not enough money in the world hwen your buying for yourself heh | 01:42 |
| Valduare | on your icydocks what kind of drives are you running in them | 01:48 |
| davecheney | Valduare: i appreciate you really want to talk about arm | 01:48 |
| davecheney | but this isn't the channel | 01:48 |
| Valduare | aye - | 01:49 |
| thumper | wallyworld_: hangout? | 02:30 |
| wallyworld_ | sec | 02:30 |
| thumper | wallyworld_: https://plus.google.com/hangouts/_/76cpj3ag8c2517af97k8drl72c?hl=en when you are ready | 02:31 |
| waigani | thumper: I'm back | 02:42 |
| thumper | wallyworld_: https://plus.google.com/hangouts/_/7acpj3620q4qsuh0smb7157iqg?hl=en | 02:46 |
| thumper | nope | 02:46 |
| thumper | waigani: https://plus.google.com/hangouts/_/7acpj3620q4qsuh0smb7157iqg?hl=en | 02:46 |
| thumper | wallyworld_: sorry | 02:46 |
| wallyworld_ | np | 02:46 |
| waigani | thumper: packages are all installed now | 03:03 |
| thumper | waigani: oh, good | 03:03 |
| waigani | davecheney: I'm in! But ... trying to install golang, it has unmet dependencies which can't be installed | 03:12 |
| davecheney | waigani: paste ? | 03:15 |
| waigani | davecheney: http://pastebin.ubuntu.com/7187924/ | 03:15 |
| davecheney | waigani: where did you get those instructions ? | 03:18 |
| davecheney | waigani: instructions are here -> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit | 03:20 |
| davecheney | waigani: thumper mwhudson http://paste.ubuntu.com/7187946/ | 03:25 |
| davecheney | current state on ppc64 | 03:25 |
| * thumper looks | 03:39 | |
| thumper | wow, joyent tests suck | 03:39 |
| davecheney | thumper: is that why they pass ? | 03:41 |
| davecheney | or the whole, 90% chance of timing out | 03:41 |
| thumper | davecheney: I was just looking at the time | 03:41 |
| waigani | davecheney: what am I missing? Can't install go on ppcvm: http://pastebin.ubuntu.com/7188020/ | 03:56 |
| wallyworld_ | thumper: yeah, i never got to fix the tests run time | 03:59 |
| wallyworld_ | didn't look into it | 03:59 |
| waigani | also, testing bug 1300032 locally, gccgo without network, I get a pile of linker errors: http://paste.ubuntu.com/7187960/ | 04:00 |
| _mup_ | Bug #1300032: charm: gccgo test failure <gccgo> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1300032> | 04:00 |
| waigani | I rebuilt pkg, updated and upgraded via apt-get - still get the same errors | 04:01 |
| waigani | thumper: ^ | 04:01 |
| thumper | wallyworld_: ok, we can put it on the TODO list | 04:01 |
| davecheney | waigani: where did you read those instructions ? | 04:02 |
| thumper | waigani: hmm... I don't know | 04:02 |
| davecheney | waigani: lets fix one problem at a time | 04:03 |
| waigani | davecheney: trying to follow yours, go get ..., no go, so trying to install go | 04:03 |
| davecheney | waigani: can you please show me where in the instructions that it it says to do the line that you are having trouble with | 04:03 |
| waigani | $ go get -v launchpad.net/juju-core/… | 04:03 |
| davecheney | waigani: which document | 04:03 |
| waigani | davecheney: the one you sent me: https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit# | 04:04 |
| davecheney | what does the line directly preceeding that one say ? | 04:04 |
| waigani | $ sudo apt-get install gccgo-4.9 gccgo-go bzr git | 04:05 |
| davecheney | did that command work ? | 04:05 |
| waigani | davecheney: nop | 04:06 |
| davecheney | ok, so lets fix that one | 04:06 |
| davecheney | then following commands might work | 04:06 |
| waigani | okay | 04:06 |
| davecheney | waigani: http://pastebin.ubuntu.com/7188020/ | 04:06 |
| davecheney | ^ this paste does not match the command you said you entered | 04:07 |
| davecheney | can you check please | 04:07 |
| waigani | davecheney: that was my attempt to install go | 04:08 |
| waigani | davecheney: http://pastebin.ubuntu.com/7188045/ | 04:08 |
| davecheney | ok, so those are all installed | 04:08 |
| davecheney | apt is complaing because a prevoius installation failed | 04:09 |
| davecheney | what happens if you follow its advice ? | 04:09 |
| davecheney | it'll probably tell you to uninstall something, probably the 'golang' meta package | 04:09 |
| waigani | apt-get -f install.. | 04:09 |
| waigani | yep removed | 04:10 |
| davecheney | you should be good to go | 04:10 |
| waigani | yep, reran install and I've got go. Thanks | 04:12 |
| davecheney | cool | 04:13 |
| davecheney | /usr/bin/go is probably provided by an alternative | 04:14 |
| davecheney | so it won't be present til the post install of gccgo-go runs | 04:14 |
| davecheney | and that doesn't run if there are apt errors | 04:14 |
| * thumper taps fingers waiting for lbox | 04:38 | |
| * davecheney plays a few hands of solitare | 04:40 | |
| thumper | for someone... simple test tweak https://codereview.appspot.com/82940044 | 04:41 |
| davecheney | thumper: you need a defer to close that listenre | 04:43 |
| davecheney | well, need is a bit strong | 04:43 |
| davecheney | maybe should | 04:43 |
| === vladk|offline is now known as vladk | ||
| davecheney | protip: if you've been running juju tests all day, check /tmp | 06:07 |
| === vladk is now known as vladk|offline | ||
| rogpeppe | mornin' all | 07:22 |
| axw | morning rogpeppe | 07:30 |
| rogpeppe | axw: hiya | 07:30 |
| axw | rogpeppe: I have an LGTM from fwereade on the fixes to parallel open, did you want to take a look before I land? | 07:31 |
| rogpeppe | axw: just looking | 07:31 |
| axw | fwereade: no rush, just checking: did you see my email about InstanceDistributor? | 07:33 |
| rogpeppe | axw: TestDialWebsocketStopped looks a little dubious to me | 07:36 |
| rogpeppe | axw: doesn't it run the risk of panicking? | 07:36 |
| axw | rogpeppe: I don't see how, can you please expand? | 07:37 |
| rogpeppe | axw: you're passing websocket.Config into newWebsocketDialler | 07:38 |
| rogpeppe | axw: s/passing/passing a nil/ | 07:38 |
| rogpeppe | axw: istm that you're only lucky that it doesn't get into websocket.DialConfig before it receives the stop notification | 07:39 |
| axw | rogpeppe: no luck involved, it's intentional that it should not use the config if the channel is stopped. but I can pass in a non-nil config if you feel strongly | 07:40 |
| rogpeppe | axw: ah, of course, you close the channel before calling the function. | 07:41 |
| rogpeppe | axw: doh! sorry, ignore me | 07:41 |
| axw | rogpeppe: no worries :) | 07:41 |
| rogpeppe | axw: LGM | 07:42 |
| rogpeppe | axw: LGTM even :-) | 07:42 |
| axw | cheers | 07:42 |
| fwereade | axw, not yet | 07:43 |
| axw | rogpeppe: what's wrong if "else if"? | 07:43 |
| axw | fwereade: okey dokey | 07:43 |
| rogpeppe | axw: it makes me look to see if there's some reason that the if is necessary | 07:44 |
| rogpeppe | axw: s/if is/else is/ | 07:45 |
| rogpeppe | axw: the only reason that i can see that it's necessary here is to save a line, but i don't think that's a great reason | 07:45 |
| axw | rogpeppe: ok. I tend to do it not so much to save lines, but to group related comparisons | 07:46 |
| axw | related tests | 07:46 |
| axw | whatever | 07:46 |
| rogpeppe | axw: yeah, fair enough. i guess whereever i see an else after a break or return, i wonder if there's been a mistake | 07:48 |
| rogpeppe | axw: but if you feel strongly about it, keep it | 07:48 |
| axw | not particularly :) | 07:48 |
| === vladk|offline is now known as vladk | ||
| vladk | good morning | 08:13 |
| axw | morning vladk | 08:16 |
| dimitern | morning all | 08:21 |
| axw | morning dimitern | 08:22 |
| axw | rogpeppe: isn't "HA: agent cache current API addresses" (i.e. with a worker) pointless if we keep provider-state up-to-date in storage? | 08:26 |
| rogpeppe | axw: only if the agent can get access to provider-state | 08:27 |
| rogpeppe | axw: (which it can't currently) | 08:27 |
| axw | ah right | 08:27 |
| mattyw | rogpeppe, fwereade when you both get a moment can you take another look at https://codereview.appspot.com/75600044/. fwereade: It's changed since you LGTMed it | 08:28 |
| rogpeppe | mattyw: will do | 08:28 |
| axw | rogpeppe: https://codereview.appspot.com/83050045 - jujud generates shared secret & calls SetStateServingInfo | 08:30 |
| rogpeppe | axw: brill, looking | 08:31 |
| rogpeppe | axw: voidspace is shortly to propose a CL which adds a SetStateServingInfo to agent config. | 08:33 |
| rogpeppe | axw: (and a StateServingInfo getter too) | 08:33 |
| axw | ah ok | 08:34 |
| rogpeppe | axw: but actually, that should merge ok with your branch | 08:34 |
| rogpeppe | axw: isn't the "between 6 and 1024 chars and base64" stipulation funny? | 08:35 |
| axw | rogpeppe: it is a bit, not sure what the deal is there | 08:37 |
| axw | rogpeppe: it's not clear on whether it's inclusive/exclusive either, but mongo doesn't complain with 1024 at least | 08:38 |
| rogpeppe | axw: good | 08:38 |
| rogpeppe | axw: 1024 seems a bit like overkill though | 08:38 |
| rogpeppe | axw: especially as the randomness won't compress and cloudinit files are limited in size | 08:39 |
| rogpeppe | axw: although... it actually never goes in a cloudinit file, does it? | 08:39 |
| rogpeppe | axw: so it probably makes no odds | 08:39 |
| axw | rogpeppe: right, it doesn't. it only goes to disk and mongo | 08:40 |
| rogpeppe | axw: i'm just looking at MongoUpstartService. I *think* that's never used to generate an upstart conf that goes across the network. does that seem right to you? | 08:41 |
| rogpeppe | axw: in which case filepath would be more appropriate than path, but then again, this is *upstart*, so path will be fine in fact. | 08:42 |
| axw | rogpeppe: MongoUpstartService is used inside environs/cloudinit | 08:42 |
| axw | for how long I don't know | 08:42 |
| rogpeppe | axw: that needs to go away though | 08:42 |
| axw | I assume once this is all done, we'll generate the mongo upstart service in the agent | 08:43 |
| axw | sure | 08:43 |
| rogpeppe | axw: when EnsureMongoService is called by jujud | 08:43 |
| rogpeppe | axw: yeah, there's a long-standing CL that will do that | 08:43 |
| jam1 | axw, thumper: hopefully I requeued the right branches to land. I had to do some bot surgery to get 1.18 available, and I noticed we were out-of-disk-space, which is probably why you were resubmitting them earlier. | 08:44 |
| axw | jam1: thanks, sorry if I was interfering | 08:45 |
| jam1 | axw: I didn't do my normal safety checks to see if it was running anything and grab the fslock, but hopefully I didn't break anything too badly. | 08:46 |
| === axw is now known as axw-afk | ||
| voidspace | morning all | 08:50 |
| foiegras | g'morning | 08:50 |
| rogpeppe | voidspace: hiya | 09:23 |
| === axw-afk is now known as axw | ||
| * fwereade will be a few mins late to the meeting to allow the nearby hoovering to complete | 09:44 | |
| fwereade | don't wait for me | 09:44 |
| mgz | fwereade: it's an hour later | 09:44 |
| fwereade | so much the better then :) | 09:45 |
| rogpeppe | voidspace: https://code.launchpad.net/~axwalk/juju-core/jujud-bootstrap-mongo-sharedsecret/+merge/213610 | 09:46 |
| jam | fwereade: that's a lot of hoovering :0 | 09:50 |
| fwereade | haha | 09:50 |
| voidspace | rogpeppe: I'm not muted | 09:50 |
| voidspace | rogpeppe: I can hear | 09:50 |
| rogpeppe | voidspace: hmm, you just went ultra-quiet | 09:51 |
| jam | wwitzel3: I'm just grabbing a coffee, then I'll be in our 1:1 hangout | 09:58 |
| perrito666 | good morning | 09:59 |
| wwitzel3 | jam: sounds good | 09:59 |
| jam | good morning perrito666 | 10:01 |
| natefinch | morning all | 10:09 |
| wwitzel3 | morning natefinch | 10:11 |
| voidspace | natefinch: morning | 10:14 |
| voidspace | wwitzel3: morning | 10:14 |
| wwitzel3 | voidspace: morning | 10:15 |
| rogpeppe1 | voidspace: environs/cloudinit/cloudinit.go | 10:24 |
| voidspace | rogpeppe1: ~mfoord/juju-core/stateservinginfo | 10:29 |
| voidspace | so running tests is pooing in my tmp directory | 10:39 |
| wallyworld_ | fwereade: will you have a moment after the standup to discuss SetPrivate/PublicAddress? | 10:40 |
| jam | axw: re: https://code.launchpad.net/~axwalk/juju-core/jujud-bootstrap-mongo-sharedsecret/+merge/213610 | 10:40 |
| jam | axw: what happens if you pass --keyFile when we don't use replSet, especially on a Mongo that was initialized differently ? | 10:41 |
| fwereade | wallyworld_, ofc | 10:46 |
| axw | jam: I tested with the local provider, it just worked | 10:58 |
| axw | jam: I created another card to create the keyfile on upgrade | 10:58 |
| jam | axw: thx. I think the idea is that EnsureMongoServer code (that hasn't landed yet) is intended to "make the state consistent" | 10:59 |
| jam | which would be writing that file | 10:59 |
| jam | and rewriting the Upstart file | 10:59 |
| axw | makes sense | 11:00 |
| axw | I will update the card to reflect that | 11:00 |
| natefinch | voidspace: about the tmp directory. That can happen if you kill the tests. In theory it shouldn't ever happen if you don't kill the tests. The problem with killing them is that deferred statements don't happen if the application dies, and that's how we do all our cleanup. | 11:03 |
| natefinch | (note the "in theory" ... we seem to leak stuff in tmp occasionally on the bot, which shouldn't be killing anything) | 11:04 |
| jam | perrito666: I think someone changed canonical admin, because I just got emails for 5 holiday requests from you. Approving them now. | 11:06 |
| perrito666 | jam: sarah did | 11:06 |
| perrito666 | jam: I was under the wrong person | 11:06 |
| voidspace | natefinch: right, thanks | 11:07 |
| hazmat | fwereade, post call.. ran into a strange bug around proper garbage collection of machines in status ... seems to be consistent around the 150 machine point.. https://bugs.launchpad.net/juju-core/+bug/1299584 .. was curious if you might be able to identify src location so i could poke at a bit more. | 11:14 |
| _mup_ | Bug #1299584: dead machines stuck in status <destroy-machine> <juju-core:Triaged> <https://launchpad.net/bugs/1299584> | 11:14 |
| fwereade | hazmat, that sounds like a provisioner bug, but I can't see why it only shows up after a while | 11:16 |
| fwereade | hazmat, the provisioner is responsible for the last step of machine cleanup -- the cleanup actually removes other stuff, and leaves the machines dead for the provisioner | 11:17 |
| hazmat | fwereade, ic, thanks | 11:17 |
| hazmat | rogpeppe1, which tool is that? | 11:19 |
| hazmat | rogpeppe1, re deps and go get | 11:20 |
| rogpeppe1 | hazmat: https://github.com/tools/godep | 11:20 |
| rogpeppe1 | hazmat: but we should go the api stabilisation route too | 11:21 |
| wwitzel3 | rogpeppe1, natefinch: https://codereview.appspot.com/83150043 IsMaster API review | 11:34 |
| rogpeppe1 | wwitzel3: will take a look after the meeting | 11:35 |
| wwitzel3 | rogpeppe1: yep, thanks | 11:35 |
| wallyworld | fwereade: who is the relevant landscape guy? | 11:42 |
| perrito666 | wwitzel3: just a personal opinion, I would like a less pythonic way to mock SeectPeerAddress :) but it its completely personal and with no justification | 11:44 |
| wwitzel3 | perrito666: comment on the review with an example and I'd be happy to consider it | 11:46 |
| rogpeppe1 | voidspace: shall we move into another hangout? | 11:50 |
| voidspace | rogpeppe1: sure | 11:51 |
| voidspace | rogpeppe1: ah, wrapping up | 11:51 |
| rogpeppe1 | voidspace: or... we could stay, yeah | 11:51 |
| perrito666 | wwitzel3: done, I am not sure if mine is better :) It could actually be worse | 11:53 |
| perrito666 | local coffee substitute beverage time, brb | 11:57 |
| rogpeppe1 | wwitzel3: you have a review | 12:00 |
| rogpeppe1 | perrito666: i made an alternative suggestion | 12:00 |
| perrito666 | rogpeppe1: I dont fully understand your suggestion (although I sense is better than mine) | 12:12 |
| === psivaa is now known as psivaa-lunch | ||
| voidspace | rogpeppe1: I'm going on lunch - if you produce a branch that fixes the config flow, or some test code to generate config files, can you email me the details please | 12:28 |
| bodie_ | epic - http://0value.com/my-Go-centric-Vim-setup | 12:38 |
| rogpeppe1 | bodie_: see also http://blog.gopheracademy.com/vimgo-development-environment | 12:41 |
| perrito666 | rogpeppe1: I definitely need to read that in depth | 12:42 |
| rogpeppe1 | it's not surprising i've got problems with hangouts. my internet speed is currently terrible. (0.74/0.18 Mbps) | 12:44 |
| perrito666 | rogpeppe1: measured how? | 12:45 |
| sinzui | jam, I think you just beat me to make an MP to merge 1.17.7 into 1.18 | 12:46 |
| rogpeppe1 | perrito666: speedtest.net (usually fairly reliable) | 12:46 |
| perrito666 | rogpeppe1: 15/1.2 :| I did not see that coming, being in the internet equivalent to congo | 12:49 |
| rogpeppe1 | perrito666: that's better than i usually get | 12:49 |
| rogpeppe1 | perrito666: but your effective speed will depend on routers out of your country too | 12:50 |
| perrito666 | well I do live in a neighborhood where internet is only used by me during work hours | 12:50 |
| mgz | I'm pretty sure the internet equivalent of the congo is the congo | 12:50 |
| perrito666 | mgz: well, I dont know, our topology is rather shameful :p but you might be right there jaja (the most used example outside is argentina) | 12:51 |
| perrito666 | mgz: the issue here is that I live on the country usually used as bad example | 12:51 |
| perrito666 | sinzui: good morning, dont hate me, did you see my email? :) | 12:52 |
| sinzui | Not yet | 12:52 |
| rogpeppe1 | mgz: lol | 12:52 |
| bodie_ | rogpeppe1, very nice :) I'm still using Sublime mostly because I'm lazy. | 12:56 |
| bodie_ | the gosublime package is pretty handy. a little bloaty, perhaps. | 12:57 |
| rogpeppe1 | bodie_: i'm an outlier when it comes to editor usage :-) | 12:57 |
| bodie_ | it's lonely at the top ;) | 12:58 |
| natefinch | bodie_: yeah, I use sublime because I like having mouse support and rational hotkeys. Gosublime does have a lot of stuff I don't need. | 12:58 |
| rogpeppe1 | bodie_: i did use vi once upon a time though | 12:59 |
| bodie_ | I'm really comfortable with vi; so, "vintage mode" in sublime is great! ;) | 12:59 |
| rogpeppe1 | i wrote a vi-mode command line editor once | 13:00 |
| TheMue | natefinch: I left ST3 now and moved back to the good old vim | 13:00 |
| bodie_ | fun | 13:00 |
| bodie_ | I'm slowly transitioning off my training wheels, but for now it helps to be able to click around and see the filetree at a glance | 13:01 |
| jam | sinzui: :). I'm still sorting out the bot, but it should be good now. | 13:01 |
| jam | I believe Ian wants to get the joyent stuff into a 1.17.8 release. | 13:01 |
| sinzui | thank you jam. I saw that in the log. We will see if I configured the joyent env properly for testing | 13:02 |
| dimitern | mgz, jam, fwereade, https://codereview.appspot.com/83200043 - provisioner starting machines with networks specified | 13:05 |
| dimitern | mgz, poke re status of that getnetworkslist branches? | 13:06 |
| mgz | dimitern: I'll get it landed now-ish I think, and tweak after | 13:09 |
| dimitern | mgz, great, thanks! | 13:09 |
| rogpeppe1 | voidspace: here's a 1.16 agent config: http://paste.ubuntu.com/7189587/ | 13:11 |
| === psivaa-lunch is now known as psivaa | ||
| voidspace | rogpeppe1: awesome | 13:26 |
| voidspace | rogpeppe1: just updating my coffee - thanks | 13:26 |
| mgz | your coffee has revision numbers? | 13:27 |
| mgz | who's branch of coffee are you using? | 13:27 |
| * fwereade collecting laura | 13:28 | |
| fwereade | dimitern, in the provsioner, shouldn't we just accept the error from the provider? StartInstance errors shouldn't take down the task, they should be recorded as machine errors | 13:28 |
| === rogpeppe2 is now known as rogpeppe | ||
| rogpeppe | my internet connection is dodgy currently | 13:28 |
| rogpeppe | my provider's running tests on the line | 13:28 |
| perrito666 | hey, is anyone working on "CLI: Ensure deploy --to and add-unit --to reports an error when the selected machine's provisioned networks match the service's" or can I take it? | 13:36 |
| jam | sinzui: so we have a logical conflict about 1.17.7 in the 1.18 branch. Probably some test that needed to be updated for new 3rd party lib locations. I won't be able to get to it tonight, but will work on it first thing tomorrow. | 13:40 |
| jam | wwitzel3, natefinch, perrito666: to help sinzui get it done, is it possible to look into this: https://code.launchpad.net/~jameinel/juju-core/1.18-merges-1.17.7/+merge/213615 | 13:50 |
| jam | It looks like merging the juju/1.18 branch with my branch causes a problem with a bad import | 13:51 |
| jam | I'm guessing we just moved it to a 3rd party lib. | 13:51 |
| jam | you should be able to reproduce it locally, as it looks like a build failure. | 13:51 |
| natefinch | jam: I'm starting an interview in 5 minutes, or I would look into it. | 13:55 |
| jam | np, it might still work better for you, since I'm EOD | 13:55 |
| jam | but don't pick it up unless nobody else steps up | 13:55 |
| jam | natefinch: ^^ | 13:55 |
| natefinch | jam: sure | 13:55 |
| wwitzel3 | jam, natefinch: I can look as well just want to finish a thought. | 13:56 |
| wwitzel3 | natefinch: we can pair on it? | 13:56 |
| natefinch | wwitzel3: sorry, doing an interview, but possibly after, though that may be after noon. | 13:57 |
| perrito666 | I can look at it too also, wwitzel3 let me know if that thought becomes too long | 13:57 |
| wwitzel3 | perrito666: if you want to hangout while I wrap this up, then we can pair on it | 13:58 |
| wwitzel3 | perrito666: I glanced at it, but didn't have any quick ideas | 13:58 |
| perrito666 | well, if for a hangout you need my screen shared it will be a problem :) my linux pc is not hangoutable :p | 13:59 |
| voidspace | rogpeppe: so I've pushed the test for 1.16 StatePort parsing based on the data you gave me | 14:03 |
| rogpeppe | voidspace: cool | 14:03 |
| perrito666 | wwitzel3: branching 1.18 to test it locally | 14:04 |
| voidspace | rogpeppe: just tweaking the test to write out a 1.18 config file from it so I can push the 1.18 test for the same thing | 14:04 |
| rogpeppe | voidspace: i'm working on changing environs/cloudinit to use StateServingInfo | 14:04 |
| voidspace | rogpeppe: that will be the only missing piece for my branch | 14:04 |
| voidspace | subject to exhaustive review of course | 14:04 |
| rogpeppe | voidspace: i got the data by bootstrapping a 1.16 local environ, BTW | 14:04 |
| rogpeppe | voidspace: so you could do the same thing with 1.18 potentially | 14:04 |
| voidspace | rogpeppe: ok | 14:05 |
| wwitzel3 | perrito666, rogpeppe: pushed up dates for https://codereview.appspot.com/83150043/ when you have time for another review. Thank you. | 14:05 |
| wwitzel3 | perrito666: I pulled down jam's branch and will see what I can get from that locally | 14:06 |
| dimitern | fwereade, agreed | 14:08 |
| dimitern | fwereade, but i haven't changed that - just added an extra check before StartInstance | 14:08 |
| fwereade | dimitern, cool | 14:08 |
| fwereade | oh wait | 14:08 |
| fwereade | dimitern, why would we do that though? | 14:08 |
| dimitern | fwereade, to save time? | 14:09 |
| fwereade | dimitern, it's a whole new code path specifically to avoid setting StartInstance errors in the usual place where people will see them | 14:09 |
| dimitern | fwereade, ok, i see your point | 14:09 |
| dimitern | fwereade, will drop the check and just call start instance | 14:10 |
| fwereade | dimitern, that's great, tyvm | 14:10 |
| fwereade | dimitern, if we want to save provider calls at some point we can do basiacl | 14:10 |
| fwereade | dimitern, actually | 14:10 |
| fwereade | dimitern, if yu can make it clean, I endorse what you're doing -- but please just make sure the errors end up on the machine status as they would have done had you called StartInstance | 14:11 |
| fwereade | dimitern, do not feel obliged though | 14:11 |
| fwereade | dimitern, threading it nicely through the provisioner task might easily not be worth the complexity | 14:12 |
| voidspace | ERROR cannot use 37017 as state port, already in use | 14:13 |
| voidspace | when I use netstat it reports that the port is open | 14:13 |
| voidspace | but for pid it reports "-" | 14:13 |
| voidspace | ah, but "sudo netstat" gives me the real answer | 14:13 |
| perrito666 | wwitzel3: do you know anything about dummy environ state tests must be run with MgoTestPackage ? | 14:18 |
| wwitzel3 | perrito666: nope | 14:21 |
| voidspace | rogpeppe2: so I get an error trying to bootstrap with trunk | 14:28 |
| voidspace | rogpeppe2: https://pastebin.canonical.com/107549/ | 14:28 |
| voidspace | error: --instance-id option must be set | 14:28 |
| rogpeppe2 | voidspace: that means you've got a jujud that's not in the same directory as your juju executable, i think | 14:29 |
| rogpeppe2 | voidspace: how did you bootstrap? | 14:29 |
| voidspace | rogpeppe2: see the pastebin | 14:29 |
| rogpeppe2 | voidspace: ah, sorry. will get me 2-factor auth key | 14:30 |
| rogpeppe2 | 526487 | 14:30 |
| rogpeppe2 | ha ha | 14:30 |
| voidspace | hah | 14:31 |
| voidspace | rogpeppe2: ah, I've done a "go install" instead of a "go build" | 14:31 |
| voidspace | rogpeppe2: and it might now be working... | 14:31 |
| rogpeppe2 | voidspace: ah, right | 14:31 |
| rogpeppe2 | voidspace: go build isn't useful for much, generally | 14:31 |
| voidspace | rogpeppe2: yeah, this is taking much longer! | 14:31 |
| voidspace | sorry for the noise... | 14:32 |
| rogpeppe2 | voidspace: this change is proving a little invasive. i think it might be better to do it as a followup to yours. | 14:33 |
| voidspace | rogpeppe2: right | 14:34 |
| voidspace | rogpeppe2: except mine has a conflict with trunk | 14:34 |
| voidspace | rogpeppe2: so we can't land mine without it | 14:34 |
| voidspace | still bootstrapping... | 14:34 |
| rogpeppe2 | voidspace: it does take ages to bootstrap - it downloads a whole image, i think | 14:34 |
| rogpeppe2 | voidspace: although, this is the local provider and on trunk, right? | 14:35 |
| voidspace | rogpeppe2: I might have an agent.cof though | 14:35 |
| voidspace | rogpeppe2: yes | 14:35 |
| rogpeppe2 | voidspace: hmm, that generally completes quite quickly for me | 14:35 |
| voidspace | "Bootstrapping Juju machine agent" | 14:35 |
| jamespage | sinzui, around? | 14:36 |
| voidspace | rogpeppe2: if it's downloading anything it will be sloooow | 14:36 |
| voidspace | rural internet | 14:36 |
| jamespage | sinzui, I have some juju-core CI questions for the Ubuntu MRE | 14:36 |
| voidspace | I think I can just use this conf though | 14:36 |
| rogpeppe2 | voidspace: sgtm | 14:37 |
| voidspace | rogpeppe2: ok to put the real certs straight into the test file? they'll be regenerated next time I bootstrap, right | 14:37 |
| sinzui | jamespage, I just added my first comment, I need to add more | 14:37 |
| jamespage | sinzui, thanks | 14:37 |
| wwitzel3 | mgz: ping | 14:38 |
| rogpeppe2 | voidspace: yeah, i think so. | 14:38 |
| voidspace | rogpeppe2: hah, the existing test data for 1_18 is for machine-0 | 14:39 |
| voidspace | so I actually need a config *without* the secrets | 14:39 |
| voidspace | hmmm... and it's still bootstrapping | 14:39 |
| voidspace | ah, and this is why | 14:40 |
| voidspace | a million log lines saying | 14:40 |
| voidspace | 2014-04-01 14:31:22 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused | 14:40 |
| dimitern | mgz, ping | 14:40 |
| rogpeppe2 | hmm, does anyone else see a test failure of state/api in trunk? | 14:41 |
| rogpeppe2 | the test looks wrong to me | 14:41 |
| voidspace | rogpeppe2: passes for me | 14:43 |
| voidspace | well, now trying api/... | 14:44 |
| voidspace | yep - all passes | 14:44 |
| rogpeppe2 | voidspace: ah, i think it's probably to do with talktalk | 14:44 |
| rogpeppe2 | hmm, not sure actually | 14:46 |
| rogpeppe2 | voidspace: could you paste me the output of running go test -gocheck.vv -gocheck.v 'TestOpenMultiple$' launchpad.net/juju-core/state/api | 14:47 |
| rogpeppe2 | voidspace: please | 14:47 |
| rogpeppe2 | oops | 14:47 |
| rogpeppe2 | s/-gocheck.v /-gocheck.f / | 14:47 |
| rogpeppe2 | voidspace: ^ | 14:48 |
| rogpeppe2 | i can't see how it can work - the address from Listen isn't ok to dial AFAICS | 14:48 |
| mgz | wwitzel3, dimitern: hey | 14:49 |
| voidspace | rogpeppe2: yep | 14:49 |
| dimitern | mgz, i'll need that branch soon ;) | 14:50 |
| voidspace | rogpeppe2: 0 passed | 14:50 |
| perrito666 | wwitzel3: I got it to fail, that is for sure | 14:50 |
| perrito666 | :p | 14:50 |
| mgz | dimitern: just done some fiddling on the maas code, merging it now | 14:50 |
| dimitern | mgz, thanks! | 14:51 |
| dimitern | mgz, did you manage to live test it? | 14:51 |
| voidspace | rogpeppe2: however, if I do | 14:51 |
| rogpeppe2 | voidspace: oh, frick. go test launchpad.net/juju-core/state/api -gocheck.vv -gocheck.f 'TestOpenMultiple$' | 14:51 |
| voidspace | go test launchpad.net/juju-core/state/api -gocheck.vv -gocheck.f 'TestOpenMultiple$' | 14:51 |
| voidspace | I get ok launchpad.net/juju-core/state/api0.325s | 14:51 |
| voidspace | and no other output | 14:51 |
| rogpeppe2 | voidspace: weird | 14:52 |
| rogpeppe2 | voidspace: what if you cd to state/api and do go test -gocheck.vv -gocheck.f 'TestOpenMultiple$' ? | 14:52 |
| fwereade | dimitern, I am confused... we have StartInstanceParams which has a Networks field; and a MachineConfig field, which itself has Networks fields | 14:52 |
| mgz | dimitern: no, not yet | 14:52 |
| fwereade | dimitern, which one counts? why does the other exist? | 14:52 |
| voidspace | rogpeppe2: a lot of output but a pass | 14:52 |
| voidspace | rogpeppe2: want a pastebin? | 14:53 |
| rogpeppe2 | voidspace: please | 14:53 |
| dimitern | fwereade, StartInstanceParams had this added initially, but the machineConfig one will be used for the cloudinit setup | 14:53 |
| voidspace | rogpeppe2: https://pastebin.canonical.com/107557/ | 14:53 |
| fwereade | dimitern, can we drop it from StartInstanceParams then? otherwise it's just a bug waiting to happen | 14:53 |
| dimitern | fwereade, and maas provider uses StartInstanceParams one to call acquireNode with networks, when set | 14:53 |
| voidspace | brb | 14:53 |
| dimitern | fwereade, i'd like to do that in a follow-up, when integrating with mgz's branch | 14:54 |
| rogpeppe2 | voidspace: weird | 14:54 |
| rogpeppe2 | voidspace: [LOG] 36.85478 INFO juju.state.api connection established to "wss://[::]:35729/" | 14:54 |
| rogpeppe2 | voidspace: that doesn't seem to work on my machine | 14:55 |
| fwereade | dimitern, btw, what led us to try to do network setup in cloudinit? is it *really* easier that an one-shot job in the machine agent? | 14:55 |
| rogpeppe2 | voidspace: ahhh, perhaps because i've got ipv6 disabled | 14:55 |
| dimitern | fwereade, it's easier for me at least | 14:55 |
| dimitern | fwereade, and less code i think | 14:55 |
| fwereade | dimitern, what's easier? | 14:55 |
| wwitzel3 | mgz: wondering how I would pull down a remote branch and switch to it? without making a whole new folder | 14:56 |
| dimitern | fwereade, do i need to test anything wrt provisioning machines with networks when we have a test that errors from StartInstance are transformed to StatusError? | 14:56 |
| fwereade | dimitern, "easier" is a valid argument, I just can't see how it applies here :) | 14:56 |
| wwitzel3 | mgz: can't seem to remember or find the syntax | 14:56 |
| dimitern | fwereade, I need to add 1 API call and a few scripts and everything can be done in the provisioner and cloudinit | 14:57 |
| fwereade | dimitern, don't think so, there's already a test for that | 14:57 |
| dimitern | fwereade, otherwise we'll also need a worker | 14:57 |
| dimitern | fwereade, ok, thought so | 14:57 |
| mgz | wwitzel3: `bzr branch --switch lp:PATH/TO/BRANCH co:BRANCH` in the dir with the colo branch setup | 14:58 |
| wwitzel3 | mgz: co: .. that is what I kept forgetting | 14:58 |
| wwitzel3 | mgz: thank you | 14:58 |
| rogpeppe2 | mgz: what is supposed to happen if you make a tcp connection to an all-zeros IP address? | 14:58 |
| mgz | the socket library should give you an error | 14:59 |
| fwereade | dimitern, honestly I'm not seeing the complexity in a one-shot worker that ignores Stop() and just uses a tomb for error transmission | 15:00 |
| rogpeppe2 | mgz: well, it doesn't (on voidspace's machine, at any rate, and it looks like the gobot machine too) | 15:00 |
| wwitzel3 | perrito666: I'm running the tests now, I was accidently merging trunk which was fixing what ever issue this merge is having | 15:00 |
| dimitern | fwereade, i have it mostly done already | 15:01 |
| fwereade | dimitern, whereas every little bit of weight we add to cloudinit worries me | 15:01 |
| dimitern | fwereade, it's a temporary solution until we have the worker | 15:02 |
| fwereade | dimitern, the bulk of it should be identical, right? | 15:02 |
| fwereade | dimitern, it's just when those same scripts happen to run? | 15:02 |
| perrito666 | wwitzel3: it blows when merged to jam's branch, running testsuite now, bbl | 15:02 |
| perrito666 | Ill go lunch | 15:02 |
| dimitern | fwereade, yeah, and a new api facade and methods | 15:02 |
| dimitern | fwereade, and the worker itself | 15:03 |
| fwereade | dimitern, it's a one-method facade, though, right? | 15:03 |
| dimitern | fwereade, so you're against setting up networks in cloudinit in general? | 15:03 |
| mgz | rogpeppe2: you can use a known-invalid hostname instead optionally | 15:04 |
| rogpeppe2 | voidspace: i'm presuming this program passes if you run it on your machine: http://play.golang.org/p/1TD2_F1NTd | 15:04 |
| fwereade | dimitern, somewhat against it, yeah | 15:04 |
| rogpeppe2 | mgz: in this case, the tests are relying on it being valid | 15:04 |
| dimitern | fwereade, if you're really feeling that way, i can go with the worker | 15:04 |
| mgz | (still vulnerable to bad dns servers... ideally we don't want bogus connections getting out at all) | 15:04 |
| rogpeppe2 | mgz: which is troubling | 15:04 |
| fwereade | dimitern, where are you getting the info about what networks actually exist at cloudinit time? | 15:04 |
| rogpeppe2 | mgz: does this code run ok on your machine? http://play.golang.org/p/1TD2_F1NTd | 15:04 |
| dimitern | fwereade, but i can't guarantee the whole lot will be ready by tomorrow eod, as we talked | 15:04 |
| fwereade | dimitern, I'm still talking it through and may yet be convinced | 15:05 |
| dimitern | fwereade, provisioner gets that and passes the needed information to render the appropriate cloudinit | 15:05 |
| mgz | fwereade: from maas /api/1.0/networks/?node=<systemidofnode> | 15:05 |
| mgz | dimitern: sending to bot with version dep bump | 15:07 |
| dimitern | mgz, ah, dependencies.tsv needs updating yes | 15:08 |
| fwereade | dimitern, mgz: so, I may be missing something -- what's the difference between the method on the provisioner facade vs the one on the mooted new one? | 15:09 |
| voidspace | rogpeppe2: trying | 15:09 |
| mgz | dimitern: right, that's why it was a bit more of a dance | 15:09 |
| dimitern | fwereade, so the provisioner one is called before StartInstance to get the networks and pass them in StartInstanceParams/MachineConfig, from which the cloudinit scripts get their params | 15:10 |
| dimitern | fwereade, and the networker api is basically the same thing, but prepares and runs the scripts at startup | 15:11 |
| dimitern | fwereade, in the latter case we don't have the provisioner api call, in the former we don't have the worker or its api | 15:11 |
| fwereade | dimitern, I'm not convinced yet I'm afraid -- that StartInstanceParams/MachineConfig thing feels like a pretty strong sign we're DIW | 15:12 |
| dimitern | fwereade, and also, in the latter case if you specify invalid networks (unknown or not available on the machine) you'll get an error after MA starts and no status error, whereas in the former case the provisioner can set statuserror in these cases | 15:12 |
| voidspace | rogpeppe2: seems to work | 15:13 |
| voidspace | [::]:48575 &net.TCPAddr{IP:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, Port:48575, Zone:""} | 15:13 |
| voidspace | accepted | 15:13 |
| voidspace | dialled | 15:13 |
| fwereade | dimitern, surely not? those networks still go into StartInstanceParams, and the provider barfs then if it can't give them to us | 15:13 |
| dimitern | fwereade, DWI=Direct Inside Wire ? :) | 15:13 |
| fwereade | dimitern, Doing It Wrong ;p | 15:13 |
| dimitern | ah | 15:13 |
| rogpeppe2 | voidspace: right, thought so. otherwise tests would've failed on your machine | 15:13 |
| rogpeppe2 | voidspace: but tests were passing on my machine, so i guess something's changed. | 15:14 |
| dimitern | fwereade, well, acquireNode either gives us a node with these networks or returns an error | 15:14 |
| fwereade | dimitern, yeah | 15:14 |
| dimitern | fwereade, so i stand corrected, with a worker we should still have startinstance-time errors, which will be recorded in status | 15:14 |
| fwereade | dimitern, should be, I think | 15:15 |
| mgz | rogpeppe2: well, that does the same on a canonistack machine as it does for voidspace | 15:15 |
| voidspace | godammit, still can't bootstrap on my machine | 15:15 |
| voidspace | 2014-04-01 15:15:23 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused | 15:15 |
| fwereade | dimitern, my big concern with the worker approach is that machine agent tests will remain a godawful fucking nightmare to test by side-effect, and doing it right *there* really will push us past allmanner f deadlines | 15:15 |
| rogpeppe2 | mgz: yup, i'm not surprised | 15:15 |
| voidspace | rebooting, something's futzed | 15:16 |
| rogpeppe2 | mgz: but AFAICS it should not be working, right? | 15:16 |
| mgz | I'm pretty sure if I write it in C, it doesn't | 15:16 |
| dimitern | fwereade, not sure I'm following you there - why MA tests will suffer? | 15:16 |
| * rogpeppe2 tries to remember his rusty sockets skills | 15:16 | |
| fwereade | dimitern, it's hell testing anything in the machine agent because there's no indirection layer -- we can't test that it starts a Fooer, we need to start the agent and hang around watching other stuff until we get evidence roughly aligned with the notion that it might have done so | 15:17 |
| fwereade | dimitern, and this will try to rewrite config that expects sudo access, I would imagine | 15:18 |
| dimitern | fwereade, yeah right | 15:18 |
| fwereade | dimitern, so all the other tests will start barfing in really weird ways | 15:18 |
| dimitern | fwereade, correct | 15:18 |
| fwereade | dimitern, not necessarily reproducible, etc etc | 15:18 |
| dimitern | fwereade, we can mock IsRootUser or something though, like for the local provider | 15:18 |
| fwereade | dimitern, it still sucks doing that at arm's length | 15:18 |
| fwereade | dimitern, ok, I have convinced myself | 15:19 |
| dimitern | fwereade, :) so? | 15:19 |
| fwereade | dimitern, go ahead with the cloudinit approach, but *please* make sure the code at the sharp end is so nicely isolated you can just move it and be done | 15:20 |
| fwereade | dimitern, and we need to have networks on *one* of MachineConfig and StartInstanceParams :) | 15:20 |
| dimitern | fwereade, ok, will try doing it sensibly | 15:21 |
| fwereade | dimitern, if it happens in a followup I'm not too bothered, so long as it does happen -- add a card maybe? | 15:21 |
| fwereade | dimitern, actually add a followup card for the worker | 15:21 |
| dimitern | fwereade, i'll poke it around some more and might do it now actually | 15:21 |
| fwereade | dimitern, this is mr.right-now, not mr.right | 15:21 |
| dimitern | fwereade, there are several cards re the worker | 15:21 |
| fwereade | dimitern, great :) | 15:22 |
| fwereade | dimitern, I find myself wishing for dependency graphs in kanban and stuff | 15:22 |
| voidspace | didn't help, still can't bootstrap trunk with the local provider | 15:22 |
| voidspace | 2014-04-01 15:21:29 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused | 15:22 |
| dimitern | fwereade, cheers | 15:22 |
| * fwereade bbiab again | 15:22 | |
| dimitern | fwereade, i still need the review though ;) | 15:22 |
| voidspace | rogpeppe2: final test pushed | 15:32 |
| rogpeppe2 | voidspace: brill | 15:32 |
| voidspace | so only resolving the APIServerDetails / StateServingInfo conflict left for my branch | 15:32 |
| voidspace | rogpeppe2: want a review on your branch? | 15:33 |
| rogpeppe2 | voidspace: please - trivial: https://codereview.appspot.com/83090044 | 15:34 |
| voidspace | rogpeppe2: yep, looks good to me | 15:34 |
| rogpeppe2 | voidspace: ta | 15:34 |
| wwitzel3 | another for good measure | 15:35 |
| rogpeppe2 | mgz: apparently it does work in C (try telnet 0.0.0.0 22) | 15:35 |
| voidspace | :-) | 15:35 |
| mgz | rogpeppe2: even gethostbyaddr doesn't complain, which surprises me | 15:36 |
| dimitern | fwereade, I dropped the networks from startinstanceparams and now only the ones inside machineconfig are used | 16:13 |
| perrito666 | wwitzel3: ping | 16:16 |
| mgz | dimitern: branch landed | 16:17 |
| dimitern | mgz, awesome | 16:18 |
| rogpeppe2 | voidspace: lp:~rogpeppe/juju-core/mfoord-stateservinginfo | 16:19 |
| jam | wwitzel3: perrito666: I think it is just that the 1.18 branch had a test case in it that needs to be updated to use a new import | 16:22 |
| jam | I would think you could just change to that dir, run "go test" directly, and it should print out the bad imports | 16:23 |
| perrito666 | jam: I got two failing here, replicaset and .. | 16:24 |
| perrito666 | machine | 16:25 |
| jam | so, for example :FAILlaunchpad.net/juju-core/cloudinit [build failed] | 16:25 |
| jam | cd cloudinit | 16:25 |
| jam | go test | 16:25 |
| jam | should just show a bad import | 16:25 |
| perrito666 | jam: sadly, here they work | 16:27 |
| jam | perrito666: did you take the 1.18 branch and merge it with mine? | 16:27 |
| perrito666 | jam: nope, merge had failed | 16:28 |
| jam | I think I found the problem.... It looks like the build process had created a library for a directory we had deleted, if I just nuke $GOPATH/pkg it works | 16:29 |
| voidspace | rogpeppe2: merged, now running tests | 16:30 |
| voidspace | rogpeppe2: I see a SharedSecret failure already | 16:30 |
| jam | at least, on the bot | 16:30 |
| perrito666 | jam: let me check | 16:30 |
| perrito666 | jam: same here | 16:31 |
| jam | perrito666: so that isn't what *you* will see. I think the steps to reproduce are: "checkout the 1.18 branch, install it, merge my branch, try to run the test suite". The initial build will have left some cruft behind that go doesn't realize is stale. | 16:31 |
| perrito666 | jam: it what i did | 16:31 |
| perrito666 | since i first tried 1.18 | 16:32 |
| perrito666 | a rm of pkg fixed it | 16:32 |
| perrito666 | brb | 16:32 |
| dimitern | mgz, fwereade, updated https://codereview.appspot.com/83200043/ - should be much more straightforward now | 16:34 |
| bloodearnest | heya, does anyone know a way to fake a public-address with the local provider? | 16:42 |
| wwitzel3 | perrito666: was grabbing some lunch | 16:44 |
| wwitzel3 | perrito666: I must be doing something wrong because I pulled down jam's branch and all the tests passed for me after running godeps -u | 16:46 |
| rogpeppe2 | mgz: looks like there might've been a failure to update dependencies.tsv | 16:47 |
| wwitzel3 | rogpeppe2: when you get a chance, if you could have another look at https://codereview.appspot.com/83150043/ | 16:47 |
| rogpeppe2 | mgz: i see these failures running tests in provider/maas | 16:47 |
| rogpeppe2 | ./environ_whitebox_test.go:342: suite.providerSuite.testMAASObject.TestServer.NewNetwork undefined (type *gomaasapi.TestServer has no field or method NewNetwork) | 16:47 |
| rogpeppe2 | ./environ_whitebox_test.go:538: suite.providerSuite.testMAASObject.TestServer.ConnectNodeToNetwork undefined (type *gomaasapi.TestServer has no field or method ConnectNodeToNetwork) | 16:47 |
| jam | wwitzel3: it appears to be a Go issue. If you branch juju-core/1.18 and then "go get" it to build the dependencies, and *then* merge my branch, your $GOPATH/pkg will have some libs in it | 16:47 |
| jam | that should be rebuilt | 16:47 |
| jam | but it would seem are not | 16:47 |
| jam | and then it can't link properly | 16:47 |
| jam | wwitzel3: perrito666: I cleaned out the dir on the bot, and the branch looks to be landing now. | 16:48 |
| wwitzel3 | jam: I wonder if we should make that part of the build process for the bot? | 16:49 |
| mgz | rogpeppe2: I messed up the edit, only the revno change was applied, not the revid | 16:49 |
| natefinch | mgz: for shame! | 16:49 |
| rogpeppe2 | mgz: ah | 16:52 |
| rogpeppe2 | mgz: in general, it's a not a bad idea to generate the whole file automatically | 16:52 |
| rogpeppe2 | mgz: i.e. godeps -t $(go list ./...) > dependencies.tsv | 16:53 |
| rogpeppe2 | (-t should probably be the default actually) | 16:53 |
| rogpeppe2 | (as should ./...) | 16:54 |
| mgz | rogpeppe2: stamp on cr 83060044 please | 16:55 |
| mgz | rogpeppe2: that would be a bad idea, because I have serv | 16:55 |
| mgz | *several, branches on other revs | 16:56 |
| mgz | or non-trunk | 16:56 |
| rogpeppe2 | mgz: link? | 16:56 |
| mgz | take and | 16:56 |
| mgz | *take an existing code review link and replace the number | 16:56 |
| rogpeppe2 | oh, ok then :-) | 16:56 |
| mgz | https://codereview.appspot.com/83060044 | 16:57 |
| mgz | there was one up the screen a bit | 16:57 |
| rogpeppe2 | mgz: LGTM | 16:59 |
| jam | sinzui: it has now landed | 17:03 |
| sinzui | thank you jam | 17:06 |
| jam | sinzui: so we just need to land the joyent stuff there | 17:08 |
| sinzui | jam, no rush...it doesn' pass qa. I wont accept it unit it does | 17:08 |
| perrito666 | jam: wwitzel3 sorry, was having a second lunch | 17:09 |
| perrito666 | :p | 17:10 |
| voidspace | rogpeppe2: branch proposed | 17:10 |
| voidspace | https://codereview.appspot.com/82960044/ | 17:10 |
| jam | wallyworld: when you can, land your stuff into the lp:juju-core/1.18 | 17:17 |
| === vladk is now known as vladk|offline | ||
| sinzui | wallyworld, Juju CI doesn't love the provider. We found several bugs preventing CI from passing. https://bugs.launchpad.net/juju-core/+bugs?field.tag=joyent-provider | 17:21 |
| sinzui | We are blocked by bug 1300877 | 17:23 |
| _mup_ | Bug #1300877: joyent fails to bootstrap due to missing shared-secret <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300877> | 17:23 |
| mgz | sinzui: having a look as wallyworld is likely not on yet | 17:24 |
| sinzui | mgz, It's 3:25 AM for him. If he is up, he wont be comprehensible | 17:26 |
| sinzui | mgz, This issue might be more crucial to some devs. trunk is broken: bug 1300889 | 17:27 |
| _mup_ | Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1300889> | 17:27 |
| hazmat | why are we instance polling against the provider? | 17:28 |
| * hazmat forgot | 17:28 | |
| voidspace | see you all tomorrow | 17:30 |
| voidspace | g'night | 17:30 |
| voidspace | EOD | 17:30 |
| rogpeppe2 | EOD for me too | 17:32 |
| rogpeppe2 | hazmat: because a) we don't know when an instance gets an address without polling and b) addresses can change | 17:33 |
| rogpeppe2 | g'night all | 17:33 |
| natefinch | night rogpeppe2 | 17:33 |
| hazmat | rogpeppe2, all of which is discoverable from the instance.. yes? | 17:36 |
| rogpeppe2 | hazmat: yes | 17:36 |
| hazmat | so no need to poll. | 17:36 |
| hazmat | the provider.. the instance already knows and can update. | 17:37 |
| hazmat | rogpeppe2, thanks | 17:37 |
| rogpeppe2 | hazmat: the state needs to know the instance addresses | 17:38 |
| hazmat | rogpeppe2, machine agents can update state | 17:38 |
| rogpeppe2 | hazmat: how does the machine agent find its own addresses without calling a provider method (the instance Addresses method in fact)? | 17:39 |
| hazmat | rogpeppe2, depends on which environment its brought up in.. it can talk to the metadata source in most of those environments.. or it can query its nics addresses. | 17:40 |
| rogpeppe2 | hazmat: ah, by discoverable from the instance you mean "discoverable by code running on the instance", not "discoverable from the Instance value" :-) | 17:40 |
| hazmat | rogpeppe2, yes | 17:40 |
| hazmat | metadata servers are live data streams in openstack, ec2 between instance and underlying iaas | 17:41 |
| rogpeppe2 | hazmat: i have no problem with getting machines to update their own addresses - it's compatible with the current model. | 17:46 |
| hazmat | rogpeppe2, and stops some of silliness of dos'ing the user's cloud account on rate limits. | 17:46 |
| rogpeppe2 | hazmat: yeah. we do make some effort to avoid making lots of calls now, BTW. | 17:47 |
| rogpeppe2 | hazmat: although the constants should probably be checked for reasonableness | 17:47 |
| hazmat | rogpeppe2, its an inherent problem imo to how we're creating iaas resources.. | 17:47 |
| hazmat | rogpeppe2, creating machines individually, polling them, creating security groups per machine, checking them all the time .. | 17:47 |
| hazmat | rogpeppe2, working on sprint topics for later this month.. | 17:48 |
| rogpeppe2 | hazmat: right | 17:48 |
| rogpeppe2 | hazmat: creating machines individually probably isn't *too* much of a problem, as you don't create machines that often. but polling them definitely can be. | 17:48 |
| hazmat | rogpeppe2, you may not.. but i do.. | 17:49 |
| hazmat | rogpeppe2, which is how i ended up finding the provisioner bug that garbage collecting machines after 150.. | 17:49 |
| hazmat | still want to source dive on that one.. but in meetings all day.. | 17:49 |
| hazmat | rogpeppe2, your right though its not as much of an issue as the instance polling or security group polling/per server stuff | 17:50 |
| rogpeppe2 | hazmat: i think the provisioner is wasteful because it assumes that something else may be actively messing with the machines under its control | 17:50 |
| rogpeppe2 | hazmat: if it assumed an environment largely static apart from through its own intervention, i think it could be a lot better | 17:51 |
| hazmat | rogpeppe2, the entire iaas interaction model hasn't changed from pyjuju days .. i wrote that code at the first juju sprint at my house.. | 17:51 |
| rogpeppe2 | hazmat: but that's definitely an assumption we'd have to think hard about | 17:51 |
| hazmat | we've just copied the model forward.. | 17:51 |
| rogpeppe2 | hazmat: yup | 17:51 |
| rogpeppe2 | hazmat: didn't want to reinvent everything... | 17:51 |
| natefinch | hazmat: but at least you're admitting it's your fault ;) | 17:55 |
| hazmat | natefinch, well some of it.. there were quite a few regressions nonetheless.. | 17:55 |
| hazmat | i autoretried transient provider errors for example. | 17:55 |
| hazmat | natefinch, and i never polled provider for addresses, i had the machine agent do it in provider specific manner (ifconfig, metadata) etc. | 17:56 |
| hazmat | natefinch, but sure i'll take responsibility for my mistakes :-) | 17:56 |
| natefinch | hazmat: I was really just joking. There's definitely stuff we need to improve. It's just a matter of prioritizing it. | 17:57 |
| hazmat | natefinch, but i can't talk all the blame for those decisions.. | 17:57 |
| hazmat | we had quite some 'discussions' | 17:57 |
| hazmat | yup | 17:57 |
| natefinch | hazmat: once we get the newbies up to speed, we'll have a lot more throughput. And once this damn HA stuff lands... | 17:58 |
| perrito666 | speaking of newbies going up to speed, I am trying to do "CLI: Ensure deploy --to and add-unit --to reports an error when the selected machine's provisioned networks match the service's" but I am not sure what is it about, hints? | 17:59 |
| wwitzel3 | trying to bootstrap trunk and I am getting Unable to locate package juju-mongodb .. what does that seem like I should know about that | 17:59 |
| perrito666 | wwitzel3: broken soething when switched to 1.18 and back? | 18:01 |
| wwitzel3 | perrito666: yeah, looks like one of the machines in the maas was dirty | 18:02 |
| fwereade | perrito666, heyhey | 18:04 |
| fwereade | perrito666, this'll be inside the state package | 18:05 |
| natefinch | perrito666: I presume that is supposed to be "Report an error when the networks *do not* match". Basically, if you have a machine on a specific network, and the service has a *different* network it requires, we shouldn't let you try to deploy the service to that machine | 18:05 |
| fwereade | perrito666, yeah, what nate said | 18:05 |
| jam | sinzui: what do you need to get a 1.17.8 out the door? *I'm* not aware of the QA failures that we should be fixing. | 18:06 |
| perrito666 | fwereade: natefinch thank you | 18:06 |
| fwereade | perrito666, in particular take care of the fact that machines have two different sets of networks -- the include/exclude with which they were created, and the *actual* set of networks they're on | 18:06 |
| sinzui | jam, Bug #1300889 is serious for trunk. The brokenness delays CI from testing 1.18. 1.17.8 can be any set of passing revisions. I am not demanding anything new be landed after 1.17.7 | 18:09 |
| _mup_ | Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1300889> | 18:09 |
| perrito666 | fwereade: I presume we are speaking about the actual set | 18:09 |
| fwereade | perrito666, yeah, desired service networks need to match actual machine networks | 18:10 |
| jam | sinzui: so, AIUI, we'll want to cherrypick wallyworld's Joyent provider changes into the 1.18 branch, and then not create it from trunk. | 18:10 |
| jam | which is why I moved 1.17.7 over to the 1.18 branch. | 18:10 |
| fwereade | perrito666, you might be able to draw inferences about possible matches based on requested machine networks alone,for the situations where the machines don't yet have actual networks, but I don't think that's a particularly major concern | 18:11 |
| wwitzel3 | Ok, new issue bootstrapping trunk .. the shared-secret for mongo in /var/lib/juju doesn't seem to be getting created. | 18:11 |
| wwitzel3 | "mongod.37017[8686]: Tue Apr 1 18:07:38.932 error getting file /var/lib/juju/shared-secret: No such file or directory" | 18:11 |
| jam | sinzui: which brings us back to r2499 on trunk | 18:11 |
| jam | and then a couple patches on top of that | 18:11 |
| fwereade | wwitzel3, rogpeppe2 was going to move where that was stored? | 18:11 |
| jam | rather than everything in trunk today | 18:11 |
| sinzui | jam, I could do that. But as I said. the joyent test doesn't pass. | 18:12 |
| wwitzel3 | fwereade: ok, I will investigate that | 18:12 |
| wwitzel3 | fwereade: thaks | 18:12 |
| fwereade | wwitzel3, he said it would be in the agent confg | 18:12 |
| sinzui | jam, CI will not bless the joyent provider in its current state. We have marked the test as not required. I would claim it works | 18:13 |
| jam | fwereade: do you know the source of why we are saying "Joyent should be in 1.18" ? | 18:13 |
| jam | *I'm* personally ok with blessing 1.17.7 as 1.18, but there seem to be conflicting requirements | 18:14 |
| fwereade | jam, so long as we get it into 14.04 it's not a big deal -- the theory was that it was close enough to complete to go in without stress and hassle | 18:14 |
| jam | fwereade: from what I can tell there is stress and hastle :) | 18:15 |
| fwereade | jam, sinzui: this is plainly not the case, so let's not block 1.18 on it | 18:15 |
| jam | fwereade: sinzui: are *you* both ok if we bless 1.17.7 as 1.18.0 ? | 18:15 |
| jam | should we be marshalling the troops into testing it as such? | 18:15 |
| jam | I know of bug https://bugs.launchpad.net/juju-core/+bug/1299802 but I wasn't able to reproduce it | 18:16 |
| _mup_ | Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Triaged> <https://launchpad.net/bugs/1299802> | 18:16 |
| sinzui | jam I am okay with that | 18:16 |
| sinzui | jam, I think we need to address bug 1299802 to say we have 1.18.0 | 18:17 |
| _mup_ | Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Triaged> <https://launchpad.net/bugs/1299802> | 18:17 |
| jam | sinzui: if I could reproduce it, yes. But upgrade just worked for me. | 18:17 |
| sinzui | jam, CI never saw this issue. Clould the bug be invalid | 18:17 |
| jam | sinzui: I was following up on it for rogpeppe2 who filed the bug. I haven't been able to reproduce it (though I've only tried one time) .The symptoms are baffling (as we have 2 requests in a row and the second one is returning an old value.) | 18:18 |
| === johnweldon is now known as jcw4 | ||
| fwereade | jam, anything that gets us a stable release with the last cycle's goodness in gets my approval | 18:18 |
| fwereade | jam, +1 | 18:18 |
| jam | sinzui: so it is sort of "do we run the test N times and see if we can trigger it"? That is what CI has been doing, right? | 18:19 |
| sinzui | jam, right it does. | 18:19 |
| jam | sinzui: https://bugs.launchpad.net/juju-core/+bug/1300877 looks like something new from axw | 18:19 |
| _mup_ | Bug #1300877: joyent fails to bootstrap due to missing shared-secret <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300877> | 18:19 |
| jam | at least, I didn't think we needed shared-secret until the recent HA changes. | 18:20 |
| jam | sinzui: which implies it isn't the Joyent provider's fault | 18:20 |
| sinzui | jam, well we will see when 1.18 is tested. | 18:20 |
| sinzui | oh, well we will see when the additions are merged | 18:21 |
| jam | sinzui: well.... do we want to delay 1.18 for the additions? | 18:21 |
| jam | there is some doubt that it will be worthwhile | 18:21 |
| jam | and we can fix trunk and just have it there. | 18:21 |
| jam | it sounds like fwereade is happy to let the Joyent provider slip | 18:22 |
| jam | I don't know of a specific stakeholder requirement for Joyent in 1.18 | 18:22 |
| jam | I'd rather just call 1.17.7 1.18.0 if we are happy. | 18:22 |
| sinzui | jam, The only reason I think we want to extra revisions is because we promised something would be in 1.18 | 18:22 |
| sinzui | cmars, does bug 1290824 have to be in 1.18.0 | 18:22 |
| _mup_ | Bug #1290824: juju should ask the charm store to decide the default series for a charm <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1290824> | 18:22 |
| jam | sinzui: "somebody promised someone" but I don't know who to put in those blanks. | 18:22 |
| jam | and it sounds like fwereade isn't one of those people | 18:23 |
| jam | and *I'm* not. | 18:23 |
| jam | so we can wait for Ian to find out where his requirements are coming from. | 18:23 |
| fwereade | jam, arosales cares very much that it lands for 14.04, but that is the only specific stakeholder I am aware of | 18:23 |
| jam | fwereade: right. 14.04 is separate (IMO) | 18:23 |
| jam | because all the stuff we're doing is critical for 14.04 :) | 18:23 |
| === vladk|offline is now known as vladk | ||
| sinzui | jam, It might be fair to say that 1.18.0 docs is the blocker. I think I need to get the collated release notes together, and update the docs. for the release. I need a day at least. I think 2 days is more realistic | 18:26 |
| jam | sinzui: then we're not in a rush and can sort out the release stuff. There is bug #1282690 | 18:26 |
| _mup_ | Bug #1282690: ensure joyent provider gets included in 1.18 release <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282690> | 18:26 |
| jam | but I have the feeling that is "it must be in trusty" | 18:27 |
| jam | not "it must be in 1.18" | 18:27 |
| sinzui | jam, That is my feeling too | 18:27 |
| sinzui | 1.18.1 is easy to make | 18:27 |
| * arosales reads back scroll | 18:28 | |
| sinzui | jam, are stopping odd-even versions with the 1.18.0 release? What do I update trunk to 1.19.a1...1.19.b1...1.19.0 | 18:29 |
| jam | sinzui: we have to do a 1.20, because 1.18 doesn't know that 1.19 would be a "stable" release. | 18:29 |
| arosales | jam fwereade: I think this may be some building blocks that cmars is working on. But we can get around it by specifically having users state what the preference is. | 18:29 |
| fwereade | arosales, ah, Iwas talking about joyent | 18:30 |
| sinzui | jam, understood | 18:30 |
| arosales | jam, fwereade: the only issue is when a charm lives in both precise and trusty and the user does not make a statement on what their preference is. | 18:30 |
| arosales | fwereade: ah joyent, yes we need that :-) | 18:30 |
| fwereade | arosales, cmars is hard at work on default-series as we speak :) | 18:30 |
| arosales | fwereade: ack | 18:30 |
| cmars | yep | 18:30 |
| arosales | jam what are the concerns with joyent? | 18:30 |
| jam | arosales: does it have to be in 1.18 | 18:31 |
| jam | we have a 1.17.7 release that looks nice and stable | 18:31 |
| jam | but doesn't have it | 18:31 |
| fwereade | arosales, joyent has no *specific* 1.18 requirement, though? AIUI it's 14.04, and we hoped it was already good enough to slot in, but it's not | 18:31 |
| jam | do we delay 1.18 to get it in. | 18:31 |
| arosales | can we land the majority, and bug fix post? | 18:31 |
| arosales | wallyworld: had suggested we don't "turn it on" and land bug fixes post 1.18 to "turn it on" | 18:32 |
| arosales | but we would need the majority of code to land, or SRU paperwork is a lot harder | 18:32 |
| arosales | jam: better question, what is blocking Joyent? | 18:32 |
| sinzui | jam, arosales, we might need to call joyent 1.20.0 if the additional code is not "like* a bug fix to the eyes of Ubuntu | 18:32 |
| jam | arosales: it landed in trunk, trunk is not stable, it did not land in an otherwise-stable branch. | 18:33 |
| jam | so it is "unknown" if there are problems | 18:33 |
| jam | though we haven't gotten it to work in trunk | 18:33 |
| arosales | sinzui: that is my point for landing it in 1.18. SRU'ing it in will be a lot more since it is a feature, but we can call it enablment | 18:34 |
| arosales | jam: work required to test joyent in current stable is how much? | 18:35 |
| sinzui | arosales, we have a test | 18:35 |
| sinzui | arosales, the test failed because of another bug introduced into trunk a few hours ago | 18:35 |
| sinzui | arosales, when wallyworld merged joyent into the 1.18 branch, CI will test it. We will know if it works or not | 18:35 |
| arosales | ok, as I understand it that is the issue for landing joyent in 1.18 is the testing | 18:36 |
| arosales | current tests are failing due to a bug outside joyent, that perhaps joyent provides | 18:36 |
| arosales | so if we take out joyent the bug is still there | 18:36 |
| arosales | jam: do you have a bug # ? | 18:37 |
| arosales | s/provides/exposes/ | 18:37 |
| sinzui | Juju code and features really grew in the last 5 months. Can I say "Juju is 20% more fucking awesome" in the release notes | 18:37 |
| arosales | ha :-) | 18:38 |
| arosales | jam sinzui sorry for being dense here, but I'll try to summerize | 18:38 |
| arosales | 1. There is a question of landing Joyent in 1.18 | 18:39 |
| arosales | 2. The reason is Joyent tests are not passing atm | 18:39 |
| arosales | 3. Test aren't passing due to a new found bug which Jam is referencing that may or may not be dependant on joyent | 18:39 |
| jam | arosales: so, I think the bigger thing is "why does it have to be in 1.18" vs "it needs to be in trusty" | 18:40 |
| arosales | jam, sinzui ^ is this correct? | 18:40 |
| sinzui | arosales, yes. | 18:40 |
| arosales | if 1.20 is in trusy before final freeze I am ok with that | 18:40 |
| sinzui | jam, 1.18.0 entered CI. I expect CI to love it like it loved 1.17.7 | 18:40 |
| * arosales was the understanding 1.18 was the final juju relase before trusty GA | 18:41 | |
| jam | arosales: we have a bunch of stuff that is also meant to be for trusty GA | 18:42 |
| arosales | jam: to your point joyent does not have a hard dep for 1.18, but does have a hard dep for trusty GA | 18:43 |
| jam | sinzui: fwereade: so if it is going to be ~2 days to get the docs together, we can take that time and try for a 1.17.8 w/ Joyent, but be ready to pull the plug and go with 1.17.7, does that sound fair? | 18:44 |
| jam | arosales: I respect that getting it in early if everything looks good is better PR wise | 18:44 |
| sinzui | jam, +1 | 18:44 |
| arosales | so as long as we have plan in place for trusty GA I am ok with that. Now we should be really transparent to the Ubuntu Archive Admins and let them know what is still planning on being delivered so they are not surprised with the branch post 1.18. | 18:44 |
| fwereade | jam, sinzui: sgtm | 18:44 |
| sinzui | jam, CI really tells us yes or no. It is easy to revert if we get a no | 18:45 |
| jam | sinzui: r | 18:45 |
| jam | right. | 18:45 |
| arosales | fwereade: jam: sinzui: thanks for trying to get all the stake holder issues in. I know its a tough job. | 18:45 |
| jam | I just mean, 1.18 isn't *delayed* if we try to get Joyent in. If it looks like it would be, we don't delay we just go with 1.17.7d | 18:46 |
| jam | sinzui: another question for you | 18:46 |
| jam | sinzui: arm vs armhf | 18:46 |
| jam | do we know why the tools we build have armhf in them, but juju internally wants to call them arm | 18:47 |
| jam | https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014 is a patch towards fixing it | 18:47 |
| jam | but we have to decide if "the tools must be right" | 18:47 |
| jam | so we have to conform to them | 18:47 |
| jam | or if we can change the naming on the tools. | 18:47 |
| jam | sinzui: because I might be wrong, but if you untar one of those juju-1.17.6.1-trusty-armhf.tgz files, and have it run jujud --version | 18:48 |
| jam | I *think* it would spit out juju-1.17.6.1-trusty-arm | 18:48 |
| sinzui | jam, I have never understood the internal names. The tool naming script is convention/guess. Not reason | 18:48 |
| jam | and not juju-1.17.6.1-trusty-armhf | 18:48 |
| jam | jhobbs: do you have an Arm board that can give us an answer? | 18:49 |
| jam | jhobbs: I *can* say that simplestreams uses armhf: http://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json | 18:49 |
| sinzui | jam http://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/view/head:/assemble-public-tools.bash | 18:49 |
| sinzui | jam, The see the get_arch() rule | 18:50 |
| jhobbs | does this log help answer? | 18:50 |
| jhobbs | https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014/comments/503262 | 18:50 |
| jhobbs | this is from a local bootstrap on an armhf | 18:50 |
| jhobbs | running juju-1.17.6-trusty-arm | 18:50 |
| jam | jhobbs: that just tells me the "juju" client thinks it is 1.17.6-trusty-arm, but not what the jujud binary thinks it is inside the tarball. | 18:51 |
| jam | However, I think given simplestreams, and other sources of information into this system | 18:51 |
| jam | it is easier to rename all the internal-to-juju stuff to call it armhf | 18:51 |
| jam | so the function | 18:51 |
| sinzui | jam, Ubuntu spits out archs, the script has to decide what to do when it finds one in an archive. The script used to abort. I removed it because powerpc is supposedly legitimate from ubuntu's perspective. I assume if we made a package for the arch, it is fine to make the same tool. But juju/go has it's own thoughts on the matter | 18:51 |
| jam | ubuntuArch() which maps from 386 => i386 | 18:51 |
| jam | needs todo the same for "arm" => "armhf" | 18:52 |
| jam | sinzui: and somewhere it is ppc64le and somewhere ppc64el, I haven't quite sorted all that out | 18:52 |
| sinzui | jam, sorry. I mean to say the script used to abort when it found an unknown arch. Now It warns | 18:52 |
| sinzui | jam, exactly the issue that made me choose to warn. | 18:53 |
| sinzui | The difference looks like a typo | 18:53 |
| jam | jhobbs: so I think the answer is. The path of least resistance is to get "juju version" to report "juju-1.17.6-armhf", and then tool lookup, etc can just continue using armhf | 18:53 |
| jhobbs | jam ok cool | 18:54 |
| jhobbs | jujud --version? | 18:54 |
| jam | jhobbs: well, they both use the same logic | 18:54 |
| jhobbs | or juju version? or are they same thing? | 18:54 |
| jam | so yes, both of them. | 18:54 |
| jhobbs | ok cool, i will try to do that and resubmit the patch | 18:55 |
| jam | sinzui: my understanding is "ppc64el" stands for Power PC 64 Little Endian | 18:55 |
| jam | jhobbs: so it *should* be changing it in juju/arch/arch.go | 18:56 |
| sinzui | jam. I need to increment the rev of the 1.18 branch. CI knows the version is less than what we are working on. I can use 1.17.8 or 1.18.0. I favor the latter. | 18:56 |
| jam | and tracking down any other constants that we're missing (hopefully few) | 18:56 |
| jam | sinzui: I think we're going to try for Joyent, so 1.17.8 | 18:56 |
| sinzui | jam, so "le" means "endian little"? | 18:57 |
| sinzui | okay | 18:57 |
| jhobbs | jam yeah, the patch i submitted just changed it in juju/arch/arch.go (and unit tests), which was enough to have it find the right tools | 18:57 |
| jhobbs | but i didn't check output of juju version | 18:57 |
| jam | jhobbs: so we used to have an "ubuntuArch" function | 18:59 |
| jam | in version/version.go IIRC | 18:59 |
| jam | I thought that moved to juju/arch/arch.go | 18:59 |
| jhobbs | that maps go arch to ubuntu arch it sounds like | 18:59 |
| jhobbs | i have to get on a call, thanks for the help! | 19:00 |
| jam | jhobbs: NormalizeArch has a bunch of regexes, one of them maps "386" to "i386", and we have "armv.*" mapping to ARM. We just need to map "arm" to ARM | 19:00 |
| bodie_ | quick question about this diagram http://blog.labix.org/wp-content/uploads/2013/06/config-changed.png | 19:43 |
| bodie_ | we're trying to understand how Set works | 19:43 |
| bodie_ | my understanding is that apiclient Call triggers stuff on the state server | 19:44 |
| bodie_ | but it's not clear how it gets to Machine 2 and more importantly the unit | 19:44 |
| bodie_ | I'm also not certain my understanding is correct | 19:45 |
| bodie_ | I thought the units / services query the state server for changes, and download them if there are changes | 19:46 |
| === vladk is now known as vladk|offline | ||
| natefinch | bodie_: sorry, I don't know that part of the code well | 19:57 |
| natefinch | bodie_: I presume they must poll for changes | 19:57 |
| bodie_ | we touched on some of it in my email thread, but how the unit knows when there's new content on the stateservice is unclear. I believe you are correct | 19:58 |
| natefinch | bodie_: charms have hooks, which are just executable files, which get called when things happen. Config-changed is a hook that gets called when the config changes. | 20:00 |
| bodie_ | I see, so the state service triggers config-changed on the unit? | 20:01 |
| natefinch | bodie_: I'm not sure of the exact mechanism that goes from {data updated in mongodb} to {config-changed hook runs} | 20:03 |
| sinzui | natefinch, do you have a minute to review a branch that increments the 1.18 branch version https://codereview.appspot.com/83300043 | 20:26 |
| sinzui | natefinch, nm, wrong target | 20:27 |
| natefinch | sinzui: let me know when/if you need me to do that | 20:30 |
| thumper | o/ | 20:31 |
| natefinch | thumper: yo | 20:32 |
| natefinch | thumper: what's accounts.conf? | 20:33 |
| thumper | natefinch: the idea that we don't have configuration for environments, just accounts, like amazon or hp-cloud | 20:33 |
| thumper | you then name the environment during bootstrap and use an account | 20:33 |
| thumper | I'm sure there is a blueprint somewhere | 20:34 |
| natefinch | thumper: I get it. so separating the name from the provider info | 20:35 |
| thumper | acj | 20:35 |
| thumper | ack | 20:35 |
| wallyworld | fwereade: i notice in the backscroll there is an issue with the joyent provider? i'd like to know what it is as 1. units tests pass, 2. i tested live and it worked fine with wordpress/mysql | 20:35 |
| natefinch | thumper: so almost like extending what we have to allow you to bootstrap multiple copies of what we now consider a single environment defined in environments.yaml, just giving it an extra name on top of that name. | 20:36 |
| mwhudson | sinzui: hi, i wanted to ask you about the status of getting juju ci going on arm64 | 20:36 |
| thumper | natefinch: kinda a bit *waves hands* | 20:37 |
| natefinch | thumper: lol, good enough | 20:37 |
| sinzui | natefinch, https://codereview.appspot.com/83310043 is correct | 20:37 |
| natefinch | sinzui: lgtm | 20:39 |
| sinzui | mwhudson, The experience has been dismal. The AMI is under powered. 2 in 5 attempts to start it and run tests fail because the instance dies while were are using it. 3 out of 5 attempts fail because we cannot compile it. And one of the reasons it takes forever is because we need to update the image with the correct tool chain | 20:40 |
| sinzui | thank you natefinch | 20:40 |
| mwhudson | sinzui: AMI? | 20:41 |
| sinzui | mwhudson, yes, http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/walk-unit-tests-arm64-trusty/66/console | 20:41 |
| mwhudson | oh, you are using the fast model? | 20:41 |
| mwhudson | er foundation model | 20:42 |
| sinzui | mwhudson, I cannot say. I am using the AMI that was built by danf | 20:42 |
| mwhudson | oh | 20:42 |
| mwhudson | hmf | 20:42 |
| sinzui | ^ that instance has been up for 50 minutes and we still haven't been able to ssh in to it to do apt upgrades and installs | 20:43 |
| * mwhudson CANNOT WAIT for hw that is not nda-ed up the ass | 20:43 | |
| mwhudson | 50 minutes seems appalling | 20:43 |
| sinzui | mwhudson, The test can accept ssh credentials to an instance that is up or start an AMI | 20:43 |
| sinzui | mwhudson, I haven't been able to keep an instance alive for more than 18 hours. I cannot reuse one that has the current tools :( | 20:44 |
| mwhudson | ok | 20:44 |
| mwhudson | sinzui: are you managing to run the tests on ppc64 ? | 20:45 |
| mwhudson | sinzui: also, do you test amd64 but built with gccgo? | 20:45 |
| sinzui | mwhudson, yep they are great. The same test is run by sshing to an instance | 20:45 |
| mwhudson | cool | 20:45 |
| mwhudson | so if i can scare some hw up, you could use that? | 20:46 |
| sinzui | yep | 20:46 |
| mwhudson | which is probably not likely in the short term but oh well | 20:46 |
| mwhudson | i wonder if qemu system is there enough yet | 20:48 |
| mwhudson | export INSTANCE_TYPE=m1.xlarge | 20:49 |
| mwhudson | that does seem underpowered | 20:49 |
| mwhudson | sinzui: could you try, i dunno, c3.8xlarge? | 20:49 |
| wallyworld | sinzui: do you know anything about the discussion in the backscroll about joyent and 1.18? there's a claim joyent tests aren't passing. does that refer to CI tests? unit tests pass cause otherwise it wouldn't have landed. and I tested live with wordpress/mysql. so is the discussion just around CI setup? | 20:50 |
| sinzui | wallyworld, good that you asked. | 20:50 |
| sinzui | wallyworld, the main bug is also the bug that broke hp and azure deploy. joyent may be fine | 20:51 |
| wallyworld | ah ok. is that a recent bug in trunk? | 20:51 |
| sinzui | wallyworld, I am merging the version inc into 1.18 now. You can gather your joyent changes and merged them. The joyent test is already setup and it will run | 20:52 |
| sinzui | wallyworld, yes r2524 landed 12 hours ago is the problem | 20:52 |
| wallyworld | sinzui: i was expecting to be asked to merge joyent into 1.18 once 1.18 was updated with 1.17.7 revision. joyent is pretty much standalone | 20:53 |
| wallyworld | i was xpecting that we would ship 1.18 with joyent | 20:53 |
| wallyworld | i will merge joyent into 1.18 after breakfast | 20:53 |
| sinzui | wallyworld, we are waiting for gobot to merge my branch. you can prepare merges now | 20:54 |
| wallyworld | ok, will do. i was concerned when i saw what seemed to be a joyent problem (or what people were saying was a joent problem) | 20:55 |
| sinzui | wallyworld, so was I. abentley happened be looking at both issues as I was reporting them in IRC. He reported the root cause in a different channel. | 20:57 |
| wallyworld | sinzui: ok, np. i was worried when stakeholders like arosales might have thought joyent was broken also | 20:57 |
| wallyworld | sinzui: do you have the link for your fancy CI dashbaord? i have misplaced it | 20:58 |
| sinzui | wallyworld, CI is currently at http://ec2-54-84-137-170.compute-1.amazonaws.com/ | 20:59 |
| wallyworld | sinzui: i found that one. you also had a summarised one | 20:59 |
| sinzui | wallyworld, http://ec2-54-84-218-58.compute-1.amazonaws.com:6543/ci summarises an older version we just ran | 21:00 |
| sinzui | wallyworld, It it is several weeks behind what CI does since jcsackett has been working on other reporting issues | 21:00 |
| wallyworld | ok, np. i liked looking at it :-) | 21:01 |
| wallyworld | i'll use the standard jenkins one | 21:01 |
| * thumper rants | 21:02 | |
| * thumper takes a deep breath... | 21:02 | |
| sinzui | wallyworld, any test/job running with -devel means we know it can fail, but it wont curse the revision | 21:02 |
| wallyworld | ok | 21:03 |
| thumper | anyone know how to have gnuflags accept the same arg multiple times? | 21:03 |
| thumper | like the python "append" type | 21:03 |
| thumper | so we can go "juju debug-log --include foo --include bar ..." | 21:03 |
| * thumper wants to match pyjuju | 21:03 | |
| wallyworld | thumper: no idea. but i fear it may not be possible | 21:04 |
| thumper | fuzz bucket | 21:04 |
| wallyworld | rog is the best person i think | 21:04 |
| * thumper ignores for now | 21:04 | |
| thumper | and works on the api server side | 21:04 |
| alexisb | hehe fuzz bucket, I am going to start using that | 21:10 |
| sinzui | wallyworld, Do you have a moment to review a branch that increment trunk to 1.19.0 https://codereview.appspot.com/83060045 | 21:13 |
| wallyworld | sure | 21:13 |
| wallyworld | jeez, that was a big one | 21:14 |
| wallyworld | thumper: this is is a backport of joyent into 1.18 so sinzui can run the CI tests https://code.launchpad.net/~wallyworld/juju-core/joyent-1.18/+merge/213724 | 21:17 |
| * thumper looks | 21:17 | |
| wallyworld | it's a cherry pick of 3 trunk revs | 21:17 |
| thumper | wow | 21:17 |
| thumper | wallyworld: lgtm | 21:18 |
| wallyworld | thumper: sorry :-( it's essentiall bzr merge -r 2515..2516 trunk | 21:18 |
| wallyworld | 3 times | 21:18 |
| wallyworld | for rev 2512, 2515, 2516 | 21:18 |
| thumper | wallyworld: cherry pick is fine IMO | 21:18 |
| thumper | do it | 21:18 |
| wallyworld | ok ta :-) | 21:18 |
| * thumper goes back to debug-log | 21:18 | |
| thumper | rogpeppe2: I don't suppose you are around? | 21:24 |
| thumper | hmm... half 10 at night | 21:24 |
| thumper | perhaps a bit hopeful here | 21:24 |
| thumper | natefinch: done anything with web sockets? | 21:27 |
| natefinch | thumper: not really, sorry | 21:28 |
| thumper | hmm... | 21:28 |
| thumper | I'm not sure this code works... | 21:28 |
| thumper | ah... | 21:34 |
| thumper | found it | 21:34 |
| thumper | that elusive line that connects everything | 21:34 |
| sinzui | perrito666, I got the backup test to work by selecting a slower env/region. | 21:36 |
| sinzui | perrito666, I think speed is the issue. I am going to change CI to run the test itself with my new Hp env | 21:37 |
| ahasenack | guys, have you seen this error before? | 21:52 |
| ahasenack | 2014-04-01 21:41:49 INFO juju runner.go:262 worker: start "lxc-provisioner" | 21:52 |
| ahasenack | 2014-04-01 21:41:49 ERROR juju runner.go:220 worker: exited "lxc-provisioner": permission denied | 21:52 |
| ahasenack | I used juju add-machine to add a machine, got it, then I tried to deploy services to it using lxc | 21:53 |
| ahasenack | and it's looping on that error | 21:53 |
| ahasenack | juju 1.17.7 | 21:53 |
| ahasenack | and then | 21:53 |
| ahasenack | 2014-04-01 21:41:49 INFO juju runner.go:254 worker: restarting "lxc-provisioner" in 3s | 21:53 |
| ahasenack | and it just loops | 21:53 |
| ahasenack | https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1299588 | 21:54 |
| _mup_ | Bug #1299588: LXC permission denied issue with 1.17.7 <micro-cluster> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588> | 21:54 |
| === hatch__ is now known as hatch | ||
| hazmat | why do we still have m1.* instances defined for ec2.. | 22:11 |
| perrito666 | sinzui: hey I was answering to you | 22:11 |
| perrito666 | sinzui: now I wonder if the problem is in the testing script or in the actual restore | 22:12 |
| perrito666 | if it is the second we have another.. bug | 22:12 |
| sinzui | perrito666, The failure is in the juju-restore. I have run just it repeatedly in the past. | 22:15 |
| * perrito666 curses out loud in spanish | 22:15 | |
| perrito666 | ok, as much as I am tempted to add a 1st world problems meme on the bug I will add the new info so the bug is addressed properly and the information remains there | 22:18 |
| thumper | ahasenack: with maas? | 22:23 |
| thumper | sinzui: do we have maas in CI yet? | 22:24 |
| sinzui | thumper, no. | 22:24 |
| thumper | sinzui: is there an ETA with that? | 22:24 |
| thumper | or are we still missing the hardware? | 22:24 |
| sinzui | possibly next month when either hardware or a cloud that lets me run vmaas comes into existence. | 22:25 |
| === hatch__ is now known as hatch | ||
| wallyworld_ | sinzui: 1.18 branch now has joyent provider merged in | 22:44 |
| rick_h_ | wallyworld_: is that the last bit required to use the joyent provider or is there more to come? | 22:45 |
| wallyworld_ | rick_h_: it works. there's some followup needed to make it "perfect" | 22:45 |
| rick_h_ | wallyworld_: ok, but we should be able to grab the 1.18 branch and bootstrap a joyent env? | 22:45 |
| wallyworld_ | rick_h_: yep. i tested in trunk | 22:46 |
| rick_h_ | wallyworld_: cool thanks | 22:46 |
| sinzui | wallyworld_, fab. 1.18 as 1.17.8 is completing tests now | 22:47 |
| wallyworld_ | rick_h_: while i have you - for a while, trunk has has public/private addresses moved off units and onto their assigned machines, even though there's a method on unit that delegates through to the machine to get the info | 22:47 |
| wallyworld_ | rick_h_: i'm doing some clean up in trunk, and now i need to change some megawatcher tests | 22:48 |
| wallyworld_ | to formalise the fact that the setter methods are now redundant | 22:48 |
| rick_h_ | wallyworld_: k, I think frankban had a little heads up but let us know and we'll keep an eye out and see if it effects the api stuff we need for machine view | 22:48 |
| wallyworld_ | which means that the tests need to change because there's no event published for units when the underlying machine address changes | 22:49 |
| wallyworld_ | i'll send an email - i think it's all good, just want to be sure | 22:49 |
| rick_h_ | wallyworld_: yea, not sure without looking into stuff more. If the proxy method is there we should be good | 22:51 |
| wallyworld_ | ok | 22:51 |
| ahasenack | thumper: no, manual provider | 22:52 |
| thumper | ahasenack: I'll ask axw when he starts | 22:53 |
| * thumper goes to hit things and think how to fix his filtering problem | 22:53 | |
| ahasenack | ok | 22:53 |
| ahasenack | thumper: I added a comment and logs to https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1299588 | 22:58 |
| _mup_ | Bug #1299588: LXC permission denied issue with 1.17.7 <landscape> <micro-cluster> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588> | 22:58 |
| ahasenack | thumper: news: same thing happened with aws, so no weird setup is needed | 23:31 |
| ahasenack | I'll append to the bug | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
