| bodie_ | anyone know how to get the lbox tool to work properly on a headless host? | 00:25 |
|---|---|---|
| bodie_ | or can I simply use the launchpad site to propose my merge? isn't there some process for going through rietveld? | 00:26 |
| bodie_ | we've been collaborating using a remote dev box | 00:26 |
| perrito666 | bodie_: you need to set the... sensible-browser iirc, to nothing and it will print the link to authorize lbox | 00:36 |
| bodie_ | okay, cool | 00:41 |
| bodie_ | perrito666, I think I've already done that, because it's giving me the link, but I thought I had to visit the URL on the same host | 00:42 |
| perrito666 | bodie_: nope | 00:43 |
| bodie_ | perrito666 -- http://paste.ubuntu.com/7303428/ -- this is what I get after authorizing it from another host | 00:43 |
| bodie_ | ah, might be working now | 00:44 |
| perrito666 | did you d the whole confirmation dance? it is not as straight forward iirc | 00:44 |
| bodie_ | it looks like it's working but now it's telling me to auth with my google account, and that's not working yet. | 00:53 |
| bodie_ | Also I thought the MR description had to be 50 words, not 50 characters. lol | 00:55 |
| rick_h_ | bodie_: hah, 50 characters for the first line | 00:56 |
| rick_h_ | and then more details after that allowed | 00:56 |
| bodie_ | ah..... | 00:56 |
| bodie_ | well, that is a very terse description then, lol | 00:57 |
| rick_h_ | ex https://github.com/juju/juju-gui/pull/249 | 00:57 |
| rick_h_ | the 50 chars is becoming a common convention | 00:57 |
| bodie_ | I mean, I crammed the whole MR description into the 50 characters thinking it was the limit. | 00:57 |
| rick_h_ | lol, no, just that first line | 00:57 |
| bodie_ | It's not quite twitter speak.... :$ | 00:57 |
| rick_h_ | so that a one line diff is reasonable and no-wrap | 00:58 |
| bodie_ | ahhh | 00:58 |
| rick_h_ | but you can expand/list/etc in the body of the commit | 00:58 |
| bodie_ | yeah | 00:58 |
| === Ursinha is now known as Ursinha-afk | ||
| bodie_ | is there a way to amend that? | 00:58 |
| bodie_ | I keep getting invalid user or password after it asks me for my Google creds. I've tried with binary132 as well as binary132@gmail.com, I know I'm using the correct password, and I authorized it on Rietveld.... | 00:59 |
| === Ursinha-afk is now known as Ursinha | ||
| arosales | axw: hello | 01:01 |
| axw | arosales: heya | 01:02 |
| arosales | axw: were you working with thumper and davechenney on the power enablment bits? | 01:02 |
| axw | arosales: nope | 01:02 |
| arosales | axw: ah ok | 01:03 |
| axw | arosales: is there something broken? | 01:03 |
| arosales | axw: do you happen to know if any other juju core folks were working on power enablment besdies thumper and dave? | 01:03 |
| arosales | axw: getting a seg fault and I know there is a kernel bug opened just not sure if it was recently resolved . . . | 01:04 |
| axw | arosales: I think waigani has been fixing some of hte tests... | 01:04 |
| axw | and wallyworld was looking at one stage | 01:04 |
| axw | I'm not sure if there was anyone else | 01:04 |
| wallyworld | there were packaging guys looking at the kernel bug | 01:04 |
| wallyworld | not sure of the status | 01:05 |
| perrito666 | bodie_: your sso acct is not setup? | 01:05 |
| bodie_ | sso? | 01:05 |
| arosales | axw: wallyworld: thanks for the info. Looking at https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1275620 | 01:07 |
| arosales | I think the fix may be in gccgo, just not sure when that fix is going to make it into trusty | 01:08 |
| wallyworld | arosales: yeah, i'm not up on the latest status sorry | 01:08 |
| wallyworld | i wasn't sure if it was just gccgo related or not | 01:08 |
| perrito666 | bodie_: strange, can you pastebin the whole output? (omitting any info that you considered not public :p) | 01:09 |
| bodie_ | it actually looks like Google was blocking my login from the VPS for security reasons :/ | 01:09 |
| bodie_ | giving it another go | 01:09 |
| waigani | arosales: what is your email? I'll forward you the latest on that issue | 01:10 |
| perrito666 | bodie_: oh | 01:10 |
| arosales | wallyworld: no worries | 01:10 |
| arosales | waigani: also do you know the latest on https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1304754 | 01:10 |
| _mup_ | Bug #1304754: gccgo on ppc64el using split stacks when not supported <ppc64el> <trusty> <gccgo-4.9 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1304754> | 01:10 |
| arosales | I think this is the one we are actually hitting | 01:11 |
| arosales | on -08 kernels we are ok, but anything more recent we consistantly seg fault | 01:11 |
| bodie_ | THERE we go. thanks google.... | 01:12 |
| bodie_ | https://codereview.appspot.com/90130044 ! ^_^ | 01:12 |
| waigani | waigani: if I remember correctly, I think the two are related - dave is the best one to ask - hopefully the email I sent will be helpful | 01:12 |
| arosales | waigani: yup they look to be related | 01:15 |
| jose | hello, guys! I have a fix for a file in juju-core, and I was wondering what's the correct way of making an MP, as I've seen codereview.appspot.com used in the past | 02:31 |
| rick_h_ | jose: yep, reitveld is used with a tool called lbox to submit patches. | 02:32 |
| jose | rick_h_: erm, would you mind helping me to propose an MP? | 02:33 |
| jose | I think I fixed https://bugs.launchpad.net/juju-core/+bug/1309805 as the description mentioned | 02:33 |
| _mup_ | Bug #1309805: LXC / Local provider machines do not boot without default-series <config> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1309805> | 02:33 |
| rick_h_ | jose: I'm looking for the doc. Not done it myself. :) | 02:33 |
| jose | oh, ok, thanks :) | 02:34 |
| rick_h_ | jose: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/CONTRIBUTING | 02:34 |
| jose | blargh, I suppose I need to check better for files like that in the future :P | 02:34 |
| jose | thanks rick_h_ :) | 02:34 |
| rick_h_ | jose: all good, thanks for going through the process | 02:34 |
| jose | np :) | 02:35 |
| jose | uh, looks like I'm getting an error when proposing | 03:20 |
| jose | RuntimeError: maximum recursion depth exceeded in cmp it says | 03:20 |
| axw | wallyworld: do we have a sprint topic about bulk API? | 04:18 |
| axw | machine provisioning is getting pretty chatty now | 04:18 |
| wallyworld | axw: yes, i think so, i remember seeing it | 04:22 |
| * axw hunts | 04:22 | |
| wallyworld | Bulk cloud API calls (both scalability, and things like port-ranges) | 04:23 |
| wallyworld | i also recall reading some prose | 04:23 |
| axw | hmm that's a bit different | 04:23 |
| axw | I'm talking about bulk Juju API calls | 04:23 |
| axw | bulk is maybe the wrong word | 04:24 |
| axw | I mean combining API calls, for example | 04:24 |
| wallyworld | i know what you mean, it's there somewhere | 04:24 |
| axw | ok | 04:24 |
| jose | oh hey wallyworld, have a minute? | 04:25 |
| wallyworld | hi sure | 04:25 |
| jose | I'm having some problems doing a proposal for juju-core | 04:25 |
| jose | erm, let me find the error | 04:26 |
| wallyworld | ok | 04:26 |
| jose | ok, so when I try to do 'bzr switch' it tells me the branch doesn't exist, or if I do 'lbox propose -bug=bugnumber' I get http://paste.ubuntu.com/7304413/ | 04:28 |
| jose | I was wondering if there's a way to do a proposal in codereview.appspot.com without using this tools, if the branch is in LP and I already have a bug number | 04:29 |
| wallyworld | hmmm. i've not seen that error before, but it looks like your initial creation of the branch missed something | 04:30 |
| wallyworld | what does bzr info say | 04:30 |
| wallyworld | launchpad is the means by which the landing bit picks up and merges the code | 04:30 |
| wallyworld | codereview.appspot.com is an ancilliary tool because some folks didn't like launchoad initially | 04:31 |
| jose | let's check bzr info | 04:31 |
| wallyworld | but lp is the main tool via which stuff needs to be proposed | 04:31 |
| jose | bzr info gives the same error I think | 04:33 |
| jose | so, saying I want to get https://code.launchpad.net/~jose/juju-core/init-comment-default-series merged into lp:juju-core | 04:33 |
| jose | would an MP be enough/good? or I still need to go through rietveld? | 04:34 |
| wallyworld | no, mp is fine by me. i prefer lp | 04:34 |
| jose | ok, let's link the bug and do an mp then :) | 04:35 |
| wallyworld | but your bzr setup is broken though if bzr info doesn't work | 04:35 |
| jose | bzr info is broken when I execute it via cobzr | 04:35 |
| jose | but if I do it with bzr, it gives the following output: | 04:35 |
| jose | http://paste.ubuntu.com/7304444/ | 04:36 |
| * wallyworld sighs - cobzr is another tools which was not needed | 04:36 | |
| jose | I should recognize the CONTRIBUTING file complicates the process x1000 | 04:36 |
| wallyworld | does the contributing file talk about cobzr? that is unfortunate if it does as it's just not needed and makes things much harder | 04:37 |
| wallyworld | bzr, lightweight checkouts,and switch are all that's needed | 04:37 |
| jose | yeah, the contributing file talks about cobzr and lbox | 04:37 |
| wallyworld | sadly lbox is unavoidable since rietveld is the review tool most people like using | 04:38 |
| wallyworld | anyways, do your mp in lp for now and we'll get it reviewed | 04:39 |
| jose | awesome, thanks :) | 04:40 |
| jose | who should I set as the reviewer? or should I just leave that blank? | 04:40 |
| wallyworld | leave it blank - i'll look at it now | 04:42 |
| jose | thank you! | 04:42 |
| jose | https://code.launchpad.net/~jose/juju-core/init-comment-default-series/+merge/216660 is it | 04:42 |
| wallyworld | jose: the boilerplate environment.yaml file already has a commented out section for default series... | 04:45 |
| wallyworld | # The default series to deploy the state-server and charms on. | 04:45 |
| wallyworld | # | 04:45 |
| wallyworld | # default-series: precise | 04:45 |
| wallyworld | i think we just want to add a comment in there to tell the user to uncomment defaultseries and set to precise or trusty as needed | 04:45 |
| jose | ok, I'm modifying that line | 04:46 |
| wallyworld | the juju init output does tell the user to edit the yaml file to suit | 04:46 |
| wallyworld | thanks very much for contributing | 04:46 |
| jose | no prob :) | 04:46 |
| wallyworld | it's great when we can get help with all the little paper cut issues like this as we often doesn't get the time to polish these user facing annpyances | 04:47 |
| jose | and, message changed | 04:49 |
| wallyworld | looking | 04:51 |
| wallyworld | jose: sorry, i didn't mean change the juju init message. the extra juju init output is not needed. just add a line to the comment in the yaml boilerplate telling the user they should uncomment the default-series line and choose precise or trusty | 04:52 |
| wallyworld | provider/local/environprovider.go | 04:53 |
| jose | oh, gotcha, gotcha :) | 04:53 |
| jose | that should do | 04:56 |
| wallyworld | jose: yep, i'll approve and the landing bot will pick it up. depending on what else is in the queue, it should land in say 20 minutes or so | 04:58 |
| wallyworld | thank you | 04:58 |
| jose | awesome! | 04:58 |
| jose | no prob, glad I could help :) | 04:58 |
| jose | should I mark that bug as fix committed? | 04:58 |
| wallyworld | jose: no, that will be done automatically by launcghpad once it lands | 04:59 |
| jose | good then | 04:59 |
| jose | thanks for approving! | 04:59 |
| wallyworld | np. you'll get an email soon hopefully saying it landed | 04:59 |
| jose | cool | 05:00 |
| jam | so quiet these days... :) | 06:48 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === psivaa-afk is now known as psivaa | ||
| === vladk|offline is now known as vladk | ||
| vladk | jam: morning | 08:43 |
| jam | morning vladk, how's it going? | 08:44 |
| voidspace | morning all | 08:54 |
| jam | morning voidspace | 08:55 |
| perrito666 | morning | 09:23 |
| mgz | hey perrito666 | 09:24 |
| wwitzel3 | hello | 09:37 |
| voidspace | wwitzel3: morning | 09:40 |
| wwitzel3 | voidspace: hey, enjoy the holiday weekend? | 09:43 |
| voidspace | wwitzel3: yeah, very good thanks | 09:53 |
| voidspace | wwitzel3: my church has a big easter celebration weekend, so I've been to six meetings | 09:53 |
| voidspace | wwitzel3: so hectic, but great fun catching up with all my friends from round the country | 09:54 |
| wwitzel3 | voidspace: nice | 09:54 |
| voidspace | wwitzel3: I'm just catching up with administrivia and then we should (could) hangout | 09:54 |
| voidspace | also the bluebells are out | 09:54 |
| voidspace | wwitzel3: you have a good weekend? | 09:55 |
| wwitzel3 | voidspace: I did thanks :) | 09:56 |
| perrito666 | jam: ? | 10:01 |
| jam | perrito666: just finishing up another hangout, will be there soon | 10:01 |
| yaguang | hi all,does any one know how to specify a public ip pool when juju bootstrap with openstack | 10:37 |
| yaguang | when using neutron as network service | 10:37 |
| yaguang | as juju can't login the instance without a public ip | 10:37 |
| jam | yaguang: "use-floating-ip: true" in environments.yaml | 10:52 |
| yaguang | jam, I see that option, but juju complains floatingip pool need to be specified | 10:53 |
| yaguang | jam, with neutron, you need to specify the pool to allocate a floating ip to instance | 10:54 |
| mgz | yaguang: can you ask in #ubuntu-server about the neutron setup you need? | 10:56 |
| mgz | yaguang: note, you don't really need public ips, provided you put the machines on a network you can route to | 10:57 |
| yaguang | mgz, the problem is that with public ip, instance can only be accessed in netns | 10:58 |
| yaguang | s/with/without/ | 10:58 |
| jam | vladk: my son's homework was pretty quick, want to do a hangout to get started on bug #1310255 | 11:58 |
| _mup_ | Bug #1310255: juju-run failure /var/lib/juju/system-identity not accessible in HA <ha> <juju-run> <juju-core:Triaged by klyachin> <https://launchpad.net/bugs/1310255> | 11:58 |
| jam | ? | 11:58 |
| jam | wwitzel3: do you have a handle on https://bugs.launchpad.net/bugs/1304407 ? | 12:00 |
| _mup_ | Bug #1304407: juju bootstrap defaults to i386 <amd64> <apport-bug> <ec2-images> <metadata> <trusty> <juju-core:In Progress by natefinch> <juju-core 1.18:In Progress by natefinch> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1304407> | 12:00 |
| natefinch | jam, wwitzel3: this is the review: https://codereview.appspot.com/89900043/ this is the branch: lp:~natefinch/juju-core/045-amd64plz | 12:02 |
| natefinch | wwitzel3: it just needs a test that we pick amd64 if it's an option | 12:02 |
| vladk | jam: let's do it | 12:03 |
| jam | vladk: I'm in https://plus.google.com/hangouts/_/canonical.com/vlad-john | 12:06 |
| voidspace | wwitzel3: let me know when you're back | 12:23 |
| voidspace | hmm... | 12:23 |
| voidspace | actually, I'll go on lunch | 12:23 |
| voidspace | wwitzel3: I'll catch up with you in a bit | 12:23 |
| jam | natefinch: "juju ensure-availability" takes an '-n' parameter that is mandatory. Did you discuss this with Rog? | 12:28 |
| jam | I filed bug #1311083 because I think setting 3 is a sane default | 12:28 |
| _mup_ | Bug #1311083: juju ensure-availability should default to -n=3 <ha> <ui> <juju-core:In Progress by jameinel> <https://launchpad.net/bugs/1311083> | 12:28 |
| jam | but I wanted to check if I missed some discussion | 12:28 |
| jam | https://code.launchpad.net/~jameinel/juju-core/ensure-availability-default-3-1311083/+merge/216706 or https://codereview.appspot.com/90160044 for anyone who wants a quick review | 12:32 |
| jam | ok, this looks to be the conversation: https://codereview.appspot.com/81700043/diff/1/cmd/juju/ensureha.go#newcode58 | 12:34 |
| jam | Which is "a default of 1 seems wrong" which I agree with | 12:34 |
| natefinch | jam: I think 3 is the only sane default, and it's almost always useful to have a sane default | 13:26 |
| jam | natefinch: the path from StateServingInfo into writing stuff to disk is *really* convoluted | 13:28 |
| jam | natefinch: so I'm trying to fix EnsureAvailability so that it picks the default series based on the existing machines | 13:29 |
| jam | natefinch: however, in client_test.go today, we don't actually *have* any state machines when we run the first EnsureAvailability command | 13:30 |
| jam | which is completely *not the way it would be* | 13:30 |
| jam | and it further has the bug that the StateServingInfo doc in the DB is only created when you *open* the State | 13:30 |
| jam | after you've created machine-0 | 13:31 |
| natefinch | jam: the tests were where we had the most difficulty with this code. I agree that we shouldn't be testing with zero state servers to start | 13:31 |
| jam | but I'm trying to reopen state, and getting "bad password cannot create the log db" | 13:31 |
| rogpeppe1 | jam: the stateServingInfo doc is created at state initialize time | 13:32 |
| rogpeppe1 | jam: unless we're upgrading | 13:33 |
| jam | rogpeppe1: but in JujuConnSuite there *is no machine-0 | 13:33 |
| jam | so there is no valid machines serving the state | 13:33 |
| jam | there are | 13:33 |
| jam | rogpeppe1: so we have to create one, and then get the doc to be recreated | 13:33 |
| rogpeppe1 | jam: yeah, that's wrong - the tests should add a machine before calling ensureavailability | 13:33 |
| rogpeppe1 | jam: but the doc is still created | 13:34 |
| rogpeppe1 | jam: even when there are no machines | 13:34 |
| jam | rogpeppe1: well, there is a doc, but it has no contents | 13:34 |
| jam | creating the machine | 13:34 |
| rogpeppe1 | jam: yeah | 13:34 |
| jam | doesn't update the doc | 13:34 |
| jam | so you have to create the machine | 13:34 |
| jam | and then re-open the state | 13:34 |
| jam | for it to put machine-0 in | 13:34 |
| jam | rogpeppe1: unless there is some other trick I should know about | 13:34 |
| rogpeppe1 | jam: i don't understand what you mean by putting machine-0 in stateservinginfo - stateservinginfo doesn't have any machine info in | 13:35 |
| rogpeppe1 | jam: unless you're actually talking about state *server* info | 13:36 |
| jam | rogpeppe1: if I do: _, err := s.State.AddMachine("quantal", state.JobManageEnviron) | 13:36 |
| jam | rogpeppe1: then it dosen't end up in StateServingInfo | 13:36 |
| rogpeppe1 | jam: StateServingInfo doesn't have any machine info in | 13:36 |
| jam | rogpeppe1: so it still looks like there are no machines actually serving the state | 13:36 |
| rogpeppe1 | jam: i don't understand your statement | 13:36 |
| rogpeppe1 | jam: unless you're talking about StateServerInfo | 13:37 |
| jam | rogpeppe1: sorry, I think you're right about StateServerInfo | 13:37 |
| natefinch | because that's not confusing ;) | 13:37 |
| jam | just a typo looking through similarly named things on 5 different object types | 13:37 |
| rogpeppe1 | jam: and StateServerInfo *should* be maintained by AddMachine | 13:37 |
| rogpeppe1 | jam: if it isn't, that's a regression and needs to be fixed | 13:37 |
| rogpeppe1 | jam: but i'm pretty sure it is | 13:37 |
| rogpeppe1 | jam: otherwise the logic wouldn't work | 13:37 |
| jam | rogpeppe1: I'm pretty sure just doing AddMachine doesn't put any MachineIds into StateServerInfo | 13:37 |
| rogpeppe1 | jam: it definitely should do | 13:38 |
| jam | EnsureAvailability does | 13:38 |
| jam | so the tests that start with EnsureAvailability(1) work | 13:38 |
| jam | and bootstrap does | 13:38 |
| jam | so in real-life it works | 13:38 |
| jam | rogpeppe1: but in real life we never have a case where there is no machine-0 | 13:38 |
| jam | because life starts somewher :) | 13:38 |
| jam | ahh,, ffs, I can't just poke EnsureAvailability either because that notices that len(VotingMachines) == 0 | 13:43 |
| natefinch | jam: like I said, the tests is where we had the most problems with this code :) There's just a lot of moving pieces and a lot of mongo quirks to work around. | 13:44 |
| jam | natefinch: the fact that JujuConnSuite doesn't match a bootstrapped environ is bad here | 13:44 |
| jam | natefinch: it is the only place where you have a Mongo running and *no* machine to host it | 13:45 |
| rogpeppe1 | jam: about a million years ago I tried to change things so the dummy environ creates a bootstrap machine | 13:45 |
| rogpeppe1 | jam: but it broke many many tests | 13:45 |
| jam | rogpeppe1: I can imagine | 13:46 |
| jam | it makes it hard to do things like "machine-0 is *this* type of machine" | 13:46 |
| rogpeppe1 | jam: because we have loads of tests that assume that the first machine created has id 0 | 13:46 |
| jam | rogpeppe1: *right* now I think I can make it work if I can re-open State so that we trigger the upgrade logic | 13:46 |
| * rogpeppe1 goes and looks at the code | 13:46 | |
| jam | rogpeppe1: state/open.go has newState() which calls createStateServersDoc | 13:47 |
| jam | which notices that if "len info.MachineIds == 0" then it will create it. | 13:47 |
| rogpeppe1 | jam: yeah, it needs to | 13:47 |
| rogpeppe1 | jam: because we might be in an upgraded environment | 13:47 |
| rogpeppe1 | jam: but state.Initialize calls state.Open | 13:47 |
| jam | rogpeppe1: sure, it just means I can backdoor it. | 13:47 |
| rogpeppe1 | jam: you should not need to | 13:48 |
| jam | rogpeppe1: I have to create the machine, then get it to run the upgrade ode | 13:48 |
| jam | code | 13:48 |
| rogpeppe1 | jam: AddMachine with JobManageEnviron *should* add the machine to StateServerInfo | 13:48 |
| jam | rogpeppe1: it doesn'tt | 13:48 |
| jam | flat out | 13:48 |
| jam | it doesn't | 13:48 |
| rogpeppe1 | jam: i thought there were tests that tested that specifically | 13:48 |
| jam | rogpeppe1: so I see maintainStateServerOPs | 13:49 |
| rogpeppe1 | jam: State.AddMachines calls maintainStateServerOps | 13:49 |
| jam | but when I'm testing it, I see len(VotingMachineIds) == 0 | 13:49 |
| rogpeppe1 | jam: which should do that | 13:49 |
| rogpeppe1 | jam: there are no *voting* machine ids | 13:49 |
| rogpeppe1 | jam: but there will be a non-voting machine | 13:49 |
| jam | rogpeppe1: if there is only machine-0, why wouldn't it be voting ? | 13:50 |
| jam | rogpeppe1: ok, PEBKAC, it wasn't the test I fixed that was failing, it was the other tests. | 13:50 |
| rogpeppe1 | jam: that's a reasonable question. | 13:50 |
| jam | that *weren't* creating a machine | 13:50 |
| rogpeppe1 | jam: BTW i think the logic should create a voting machine id unless NoVote is true | 13:51 |
| jam | rogpeppe1: well, again, that isn't the "standard" path that we're going to get machine-0 is it? | 13:52 |
| jam | maybe it is | 13:52 |
| jam | the first step is just AddMachine(the thing I just started) | 13:52 |
| rogpeppe1 | jam: AddMachine should add the machine to the voting servers | 13:53 |
| rogpeppe1 | jam: i'd be surprised if it doesn't | 13:53 |
| jam | rogpeppe1: so it might, I'll have to double check that now that I've sorted out which tests are actually failing | 13:53 |
| rogpeppe1 | jam: ok | 13:53 |
| jam | I certainly expected that we would always have 1 voting machine | 13:53 |
| rogpeppe1 | jam: i believe we do | 13:54 |
| jam | but stuff broke because we never created machine-0 | 13:54 |
| rogpeppe1 | jam: (after the first machine is actually created) | 13:54 |
| jam | and I fixed that for one test, and the others broke, and I thought it was my test that was breaking | 13:54 |
| jam | ok, we have a voting machine after AddMachine | 13:56 |
| rogpeppe1 | jam: good. everything seems to be working as it should then. | 13:58 |
| rogpeppe1 | jam: BTW i think it might be reasonable if AddMachine also took its series from the state server machines by default | 14:02 |
| rogpeppe1 | jam: because then at least we know that calling juju add-machine will work | 14:03 |
| jam | rogpeppe1: I think having PreferredSeries return the state server arch instead of LatestLTSSeries would be ok, but I think that is more of a conversation that we need to bring up for discussion. | 14:05 |
| rogpeppe1 | jam: yeah | 14:05 |
| jam | s/arch/series/ | 14:06 |
| wwitzel3 | voidspace: https://code.launchpad.net/~wwitzel3/juju-core/008-ha-rsyslog | 14:08 |
| jam | natefinch: rogpeppe1: so AXW's comment seems to me that he wanted a default to mean "preserve the existing availability" | 14:11 |
| jam | I would be fine making the default 0, and have that interpreted on the server as 3 or whatever N is currently running if N != 1 | 14:12 |
| rogpeppe1 | jam, natefinch: i have a version of https://codereview.appspot.com/70770043/ that consists of entirely automatic changes and uses "errgo" rather than "errors" as the errgo package identifier. i'd quite like to get it in, but it would be nice to have advance approval because of the overheads of proposal. | 14:12 |
| jam | rogpeppe1: as this is not in the critical path to release, I can't commit the time to reviewing it today (especially since I'm 1.5hrs past EOD already) | 14:13 |
| rogpeppe1 | jam: which comment? | 14:13 |
| jam | rogpeppe1: https://codereview.appspot.com/90160044/ | 14:13 |
| jam | about the default N for ensure-availability | 14:13 |
| rogpeppe1 | jam: ok. but are you amenable to the change in principle? | 14:13 |
| * jam goes to spend time with the familyd | 14:13 | |
| rogpeppe1 | jam: +1 to making the default the current number | 14:14 |
| jam | I haven't particpated in the discussion enough to really contribute there. | 14:14 |
| jam | I think we had gotten to the point of "yes we should use errgo", but I wasn't a voting member of those discussions | 14:14 |
| rogpeppe1 | jam: i had a "LGTM but please use errgo for the package identifier" | 14:19 |
| rogpeppe1 | jam: which is basically what i'm doing now | 14:19 |
| rogpeppe1 | jam: but that was a little while ago. the LGTM might have expired. | 14:19 |
| rogpeppe1 | jam: i can make the changes in about 15 seconds, but lbox proposing it takes ages. | 14:20 |
| bodie_ | hi guys, can I get a review on our MR? https://code.launchpad.net/~binary132/juju-core/skeletal_actions/+merge/216651 | 14:25 |
| bodie_ | it's a little hefty | 14:25 |
| bodie_ | whenever you have time | 14:25 |
| bodie_ | thanks in advance :) | 14:25 |
| bodie_ | rietveld at https://codereview.appspot.com/90130044 | 14:26 |
| wwitzel3 | voidspace: http://www.rsyslog.com/sending-messages-to-a-remote-syslog-server/ | 14:29 |
| natefinch | rogpeppe1: what does swapping in errgo get us right now? Do we get file/line numbers for those errors? | 14:29 |
| rogpeppe1 | natefinch: it doesn't change any existing external behaviour, but it means we lose our dependency on github.com/errgo/errgo and it sets us up for the next stage. | 14:30 |
| rogpeppe1 | natefinch: and, yes, we might get file/line numbers for those errors | 14:30 |
| natefinch | rogpeppe1: keeping that code from bitrotting seems worthwhile | 14:31 |
| rogpeppe1 | natefinch: (but those errors aren't really the important ones as they're easy to grep for) | 14:31 |
| rogpeppe1 | natefinch: that code has already bitrotted (i just do it from scratch each time), but the conversion program may bitrot | 14:31 |
| stokachu | is the ProvisioningScript the api call i would use to "juju run" a shell script before any of the hooks are run? | 14:33 |
| natefinch | rogpeppe1: ok, just do it. If the code compiles and the tests pass, then I don't think anyone can argue too much. | 14:34 |
| rogpeppe1 | natefinch: cool | 14:34 |
| === Ursinha is now known as Ursinha-afk | ||
| stokachu | or is an api command available that allows me to run abitrary commands on a machine before any hooks are executed | 14:37 |
| natefinch | stokachu: what are you trying to accomplish? | 14:41 |
| stokachu | natefinch: writing a plugin to do some initial setup on the machine before running a charm | 14:42 |
| natefinch | stokachu: you can always do add-machine, set up some stuff, and then deploy --to it | 14:42 |
| stokachu | natefinch: by doing juju run or juju ssh? | 14:42 |
| natefinch | stokachu: juju run, yeah. You can do juju add-machine, juju run --machine 1, juju deploy foo --to 1 | 14:43 |
| stokachu | so how do i do it through the api? | 14:44 |
| stokachu | i want to pass it a script to run | 14:44 |
| stokachu | with the api i want to be able to add-machine, upload a script via sftp or something, then execute it before a charm is deployed | 14:45 |
| stokachu | i can add-machine through the api just fine | 14:46 |
| natefinch | stokachu: there's a RunOnAllMachines api endpoint | 14:46 |
| === Ursinha-afk is now known as Ursinha | ||
| stokachu | so that endpoint RUnOnAllMachines, does it support passing a script over the wire? or is it for running commands independently | 14:48 |
| natefinch | stokachu: looks like it just takes a list of commands, not a full script | 14:50 |
| stokachu | ok | 14:51 |
| stokachu | is the run commands done as root as well? | 14:51 |
| stokachu | i dont have to worry about sudo or anything like in the charms? | 14:51 |
| natefinch | stokachu: yeah, it's run as the "ubuntu" user which generally has root privs | 14:52 |
| stokachu | ok cool | 14:53 |
| stokachu | so essentially i could run juju scp, then call the api to execute that command | 14:54 |
| natefinch | stokachu: that should work, yeah | 14:54 |
| stokachu | is there an api for scp or does that have to be run manually, i couldnt find any reference to it in the code | 14:54 |
| stokachu | in the api section of the code anyway | 14:54 |
| natefinch | stokachu: yeah, scp doesn't use the API | 14:57 |
| stokachu | ok cool, thanks man | 14:57 |
| natefinch | welcome | 14:58 |
| stokachu | natefinch: last question, other than juju scp is there any other way to upload files to machine using the api? | 15:02 |
| sinzui | rogpeppe1, natefinch: I don't think Go van only import a master branch from git. Am I wrong? | 15:02 |
| rogpeppe1 | sinzui: i'm not sure what you mean | 15:02 |
| rogpeppe1 | sinzui: the only thing in Go that knows about branches is "go get" | 15:03 |
| stokachu | marcoceppi: maybe you know? ^ | 15:03 |
| natefinch | stokachu: I don't think so. What's wrong with using the juju client's juju scp? | 15:03 |
| stokachu | natefinch: if im on a remote machine with no juju client | 15:03 |
| natefinch | stokachu: I guess I don't know why you'd be on a random machine without juju, but with whatever code you're writing | 15:04 |
| sinzui | rogpeppe1, right. I can "go get" github.com/juju/core/1.18 | 15:04 |
| sinzui | ^ rogpeppe1 I mean I can *not* | 15:04 |
| natefinch | sinzui: you can always use version control to get a branch before building it with go | 15:05 |
| stokachu | natefinch: yea just wanted the ability to interface with juju without relying on juju binary | 15:05 |
| natefinch | stokachu: but..... you have *code* that you're relying on somewhere. | 15:05 |
| sinzui | rogpeppe1, for CI and releases, I need to keep the branch info separate and I need another step to checkout that branch | 15:05 |
| mgz | can I have a review on https://codereview.appspot.com/90310043 | 15:06 |
| mgz | rogpeppe1: ^ you should be on holiday, no? (but if not... :) | 15:06 |
| stokachu | natefinch: yea but that doesn't necessarily mean i have to have juju installed with it | 15:06 |
| sinzui | natefinch, That presumes a little too much. Currently, we use go get, then switch to the branch. | 15:06 |
| sinzui | natefinch, Then run godeps to pin all the branches to the correct version | 15:07 |
| natefinch | stokachu: well, otherwise you're just duplicating effort with what we have in juju client | 15:07 |
| sinzui | natefinch, The new issue is that bzr urls has branch and (implicitly) repo, git only supports repo (implicitly master) | 15:08 |
| stokachu | natefinch: what if its library bindings | 15:08 |
| sinzui | SO I need to change CI and Releases to gather another piece of information, the branch, and I need a step to switch to that branch when juju goes to git hub | 15:08 |
| natefinch | sinzui: yes... although go get launchpad.net/juju-core/1.18 wouldn't work anyway, since it would put the juju-core code in $GOPATH/src/launchpad.net/juju-core/1.18 | 15:10 |
| natefinch | stokachu: not sure what you mean. | 15:10 |
| sinzui | natefinch, It does work, but not that way. Release tarballs always exercise go-get, then switches to a branch and revision. The branch is a url. git is a name. | 15:11 |
| natefinch | sinzui: I guess I'm not sure what the problem is, if you had to go get and switch before, and you do the same with git. | 15:17 |
| natefinch | sinzui: does it matter if the switch target is a url or a name? they're both just strings, right? | 15:17 |
| sinzui | natefinch, There are some issues because a url enough information for CI/releases to get all the juju code. It is not with git. It is two pieces of information that I need to store now | 15:18 |
| natefinch | sinzui: oh, I see. | 15:19 |
| sinzui | or I create a pretend url with the extra information | 15:19 |
| sinzui | natefinch, This is a niggle that makes CI transition to github awkward. Obviously it can be fixed in a day, but I was hoping that Go had a solution for the problem | 15:19 |
| natefinch | sinzui: there is a solution, but it requires us to do a little work ahead of time. You can make a redirector service that can translate, for example juju.com/v1.18/juju-core into github.com/juju/juju-core (branch 1.18) | 15:20 |
| natefinch | sinzui: that's actually the "correct" way to solve this problem.... we've been going against the grain with godeps and using non-head branches etc etc | 15:21 |
| sinzui | ah, thank you natefinch. I forgot about that | 15:21 |
| stokachu | natefinch: if im writing an application using a api library i shouldnt need the actual juju command | 15:34 |
| stokachu | the api server supports uploading of charms though | 15:36 |
| natefinch | stokachu: the juju client pretty much is an api library, and one that we keep up to date with the rest of our changes. But I understand it may not work for all purposes. | 15:41 |
| stokachu | i think it would be cool override cloud-init too | 15:43 |
| marcoceppi | stokachu: you can use regular rsync | 15:59 |
| marcoceppi | you just have to have ssh keys on that machine, and know the IPs | 15:59 |
| stokachu | marcoceppi: do i just supply it the ssh key | 15:59 |
| stokachu | i think the api lets me get those ssh keys | 15:59 |
| marcoceppi | `rsync -avz ubuntu@<juju-machine-ip>:... ./` | 15:59 |
| marcoceppi | stokachu: maybe, not sure | 15:59 |
| natefinch | stokachu: you can certainly override cloud-init, but there is almost certainly code in jujud that will assume stuff has been done in cloud-init. | 16:00 |
| stokachu | so i wanted to maybe utilize the provisioningscript api call to override cloud-init in a manual provider | 16:00 |
| stokachu | but it looks like it would be run after a machine is deployed | 16:01 |
| voidspace | need moar coffeez | 16:09 |
| === jamespag` is now known as jamespage | ||
| voidspace | natefinch: ping | 16:50 |
| natefinch | voidspace: pacman (so much better than pong) | 16:51 |
| voidspace | natefinch: hah, nice - I'll have to remember that | 16:51 |
| voidspace | natefinch: so I'm working with wwitzel3 on the rsyslog issue | 16:51 |
| voidspace | natefinch: we think we can do most of the work with the rsyslog configuration | 16:51 |
| hazmat | hmm.. api-endpoints on trunk has degraded | 16:51 |
| hazmat | http://pastebin.ubuntu.com/7308341/ | 16:51 |
| natefinch | voidspace: awesome | 16:51 |
| voidspace | natefinch: with some extra work to update the config when available state servers change | 16:51 |
| voidspace | natefinch: with the slight side issue (to be dealt with later) that new state servers possibly want all the previous logs too | 16:52 |
| voidspace | natefinch: so we currently have separate config templates for nodes and stateserver machine | 16:52 |
| voidspace | natefinch: nodes are currently configured to log just to the *first* state server machine | 16:52 |
| voidspace | natefinch: changing that to have multiple rules logging to all of them is easy | 16:52 |
| voidspace | natefinch: state servers only log locally (to a file) | 16:53 |
| voidspace | natefinch: we need to change this to log locally *plus* to send all log messages generated on the machine to the other state servers | 16:53 |
| natefinch | hazmat: what's degraded about that? | 16:53 |
| hazmat | natefinch, previously it would return the first line.. | 16:53 |
| voidspace | natefinch: obviously not to just forward *all* messages, or they would forward all the ones they received and every message would be logged an infinite number of times | 16:54 |
| voidspace | which might annoy people | 16:54 |
| hazmat | natefinch, its now returning every possible state server address. the whole point of the method is for api clients to connect to the state server. | 16:54 |
| voidspace | natefinch: sooo, we need an rsyslog rule that matches locally generated messages | 16:54 |
| natefinch | voidspace: yeah, that sounds good. definitely handling new servers added getting old logs is something that can sit in a todo for right now | 16:54 |
| hazmat | natefinch, so private addresses, local host addreses need not apply. ipv6 addreses should only be shown on switch, etc. it breaks existing clients that were using the output previously | 16:54 |
| voidspace | natefinch: well, we probably need to do adding new servers unless the info for all state servers is always immediately available | 16:55 |
| voidspace | but that aside | 16:55 |
| voidspace | (we'll figure that out shortly) | 16:55 |
| voidspace | we need a rule that can filter local messages | 16:55 |
| natefinch | hazmat: yeah, jam was looking at that too. Certainly the localhost ones are just wrong (especially since you might legitimately have a local environment running on localhost). | 16:56 |
| voidspace | natefinch: I'm currently scouring the interwebs for examples of matching local messages only | 16:56 |
| voidspace | natefinch: is this something you know about or should I delve further into my search? | 16:56 |
| natefinch | voidspace: I know less about rsyslog than probably anyone else on the team :) | 16:57 |
| voidspace | I can see we have %HOSTNAME% available to the templates | 16:57 |
| voidspace | natefinch: haha | 16:57 |
| voidspace | but I don't think local messages will come in with hostname | 16:57 |
| voidspace | maybe we can match on the *absence* of a hostname as we know the format of *forwarded messages* | 16:57 |
| hazmat | natefinch, its also confusing because the notion with ha is that each entry would be a different state server | 16:57 |
| voidspace | that sounds potentially ropey though | 16:57 |
| voidspace | natefinch: ok, I'll continue | 16:58 |
| natefinch | hazmat: brb, gotta help with the kids for a second. I think part of the idea is that IPs internal to the environment will work from inside environment, and the external ones might not. | 16:58 |
| hazmat | natefinch, one of the primary users of the api is the cli client which isn't in the environment. notions of external/internal are definitely fuzzy | 17:00 |
| hazmat | filed a bug on it to track fwiw http://pad.lv/1311227 | 17:00 |
| natefinch | hazmat: the idea is that you dial all the addresses (staggered slightly) and use whatever one connects first. I believe the way the CLI works is that when it connects to one, it resorts that one to the top of the list, so next time it's likely to connect first again. | 17:11 |
| hazmat | natefinch, the issue is a bit more than that.. if this api is used by agents then result need to differ by login | 17:12 |
| hazmat | natefinch, there's little value in an a cli client connecting to localhost, private ip addresses, or ipv6 (unless requested).. | 17:13 |
| hazmat | where as agents preferentially want the private addresses | 17:13 |
| natefinch | hazmat: right | 17:13 |
| === vladk is now known as vladk|offline | ||
| natefinch | hazmat: probably the ultimately right thing to do is return the same list to everyone, but include the networkscope, so the consumer can decide what addresses is appropriate for itself. the client would only look at public, agents would only look at cloudlocal, etc. | 17:17 |
| hazmat | yeah.. more incompatible output ;-) | 17:17 |
| hazmat | natefinch, in that case (incompatible output) differentiating the state servers would also be good | 17:18 |
| natefinch | hazmat: can't keep the world frozen for forever :) Really, the only problem with the current output (aside from the fact that it's not the same as what we had before) is that some of the addresses are ambiguous (localhost, 10. addresses from outside the cloud, etc) | 17:19 |
| hazmat | natefinch, well the current output is a regression for users of that cli command imo | 17:19 |
| natefinch | hazmat: the API servers are all identical... there's no reason to differentiate | 17:20 |
| hazmat | natefinch, 'so the consumer can decide what addresses is appropriate for itself. ' | 17:20 |
| hazmat | also applies to multiple distinct endpoints.. even if resulting traffic is identitcal | 17:21 |
| voidspace | wwitzel3: example of having separate rulesets for local and received messages | 17:21 |
| voidspace | wwitzel3: http://www.rsyslog.com/tag/more-complex-scenarios/ | 17:21 |
| hazmat | natefinch, ie a client wants to grab a set of ipv4 public addresses to round robin to.. how do they know their getting an ha set without servers identified distinctly | 17:22 |
| natefinch | hazmat: I'm not sure I understand. You get a list of IP addresses the environment says are for the API.... what does that have to do with HA? We always return addresses for all state servers. If you're in HA, you'll get addresses from multiple servers. What does the client need to know? | 17:24 |
| hazmat | natefinch, i have a client that refuses to connect to an env unless its in ha mode.. how does it know the difference without state servers identified in the result? | 17:24 |
| natefinch | hazmat: juju status would show multiple state servers. api-endpoints is not the call to make to determine if you're in HA mode. | 17:25 |
| hazmat | natefinch, it is the call to get the api endpoints | 17:25 |
| hazmat | natefinch, which is what the client needs to connect to.. if one server has 4 public ip addresses, how does the client distinguish to get only get the ones representing a unique set of endpoints for the state servers that it can talk to | 17:26 |
| hazmat | it can't unless the results also distinguish state servers in addition to endpoints | 17:27 |
| natefinch | hazmat: but it doesn't matter what API server it talks to | 17:27 |
| hazmat | natefinch, the traffic doesn't matter, the connection being ha does.. ie. the client wants to be able to fall back to a different server, how does it know there's a different server to fallback to? | 17:28 |
| natefinch | hazmat: it has more API addresses it can connect, just round robin on those. | 17:29 |
| hazmat | natefinch, if they all point to the same server? | 17:29 |
| hazmat | natefinch, you expressed the desire to pass the information to the client, but your also saying let's not pass it because it shouldn't matter | 17:30 |
| hazmat | that's not very consistent | 17:30 |
| natefinch | hazmat: the information I wanted to pass was the type of network address, not the machine that was behind it. | 17:30 |
| hazmat | i'm saying it does matter if the client wants to know that there are multiple vms it can connect to | 17:30 |
| hazmat | why should the client try a bunch of addresses for a machine it may know it can't talk to ... | 17:30 |
| hazmat | because that machine is down now.. when if it knew which addresses mapped to the state server, it could just fallback to the next actual server | 17:31 |
| natefinch | hazmat: it just seems like you're trying to overload api-addresses. There's juju status if you want to know the status of the state servers | 17:31 |
| hazmat | natefinch, its already been overloaded | 17:32 |
| hazmat | natefinch, i'm trying to clean it up.. you suggested breaking compatiblity already.. i'm saying well let's give the clients all the info they need. | 17:32 |
| natefinch | hazmat: well, we could return yaml document with each server and a list of addresses with what type they are (public, cloud local, etc) | 17:41 |
| hazmat | natefinch, sounds good | 17:41 |
| natefinch | hazmat: probably not something we can do this week, though. We're pretty slammed, and a ton of people are off at gophercon | 17:42 |
| hazmat | natefinch, yeah... i'm already on site | 17:43 |
| hazmat | natefinch, its a regression though in the dev version, so it would be good to fix up or make compatible at least for the next stable, not sure when that's scheduled | 17:43 |
| natefinch | hazmat: pretty sure that'll be post-vegas. But we should be able to target it for that, I'd think. | 17:44 |
| natefinch | hazmat: I wonder if we should have tests external to juju-core that show any break in compatibility with old versions. Obviously they wouldn't be able to test everything, but simple things like this could at least be caught and discussed / noted in release notes. | 17:47 |
| natefinch | hazmat: I gotta run to a doctor's appointment, back in an hour or so. | 17:48 |
| === natefinch is now known as natefinch-afk | ||
| hazmat | natefinch-afk, yeah.. part of the issue is that the functional regression suite is only hit a small fraction of the surface area (bootstrap/destroy-env/deploy/add-unit/relation/expose etc) | 17:50 |
| hazmat | i should setup some sort of ci for some of the extant plugins | 17:51 |
| hazmat | natefinch-afk, hmm.. although i just ran into an interesting case and regression as a result of the same.. i'm currently spanning regions with manual provider which used to work fine.. but with 1.19 breaks because the machines initially connect on public, get the cloud local address, and attempt to reconnect back with that cloud-local addresses which is broken since the machines are on different cloud-local/subnets, resulting in down machines. | 17:57 |
| hazmat | http://paste.ubuntu.com/7308797/ | 18:01 |
| === hatch__ is now known as hatch | ||
| === vladk|offline is now known as vladk | ||
| === natefinch-afk is now known as natefinch | ||
| bac | hi sinzui, can i pick your brain about logging in to charmworld? | 20:05 |
| sinzui | bac sure | 20:21 |
| bodie_ | thanks for the feedback natefinch | 20:26 |
| bodie_ | :) | 20:26 |
| bodie_ | i'll reply in thread | 20:26 |
| natefinch | bodie_: no problem. Glad to have this work getting done. I don't remember if I said so, but the code looks generally good. | 20:27 |
| bac | sinzui: may have to wait util tomorrow... | 20:36 |
| === vladk is now known as vladk|offline | ||
| === hatch___ is now known as hatch | ||
| stokachu | so im trying to write some code against juju-core but i keep hitting this error: http://paste.ubuntu.com/7310622/ | 23:11 |
| stokachu | i thought someone brought this up previously but couldnt find it in my irc logs | 23:11 |
| stokachu | cmars: i get that same error when trying to build your juju-nat plugin too | 23:12 |
| stokachu | cmars: have you run into that issue before? | 23:12 |
| Guest46215 | stokachu: looks like you've pulled tip of code.google.com/p/go.crypto which breaks juju. Go's lack of proper dependency mgmt sucks. you can run godeps -u dependencies.tsv to get the correct revision | 23:19 |
| stokachu | Guest46215: ah perfect that worked | 23:20 |
| stokachu | Guest46215: thanks! | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!