[00:25] anyone know how to get the lbox tool to work properly on a headless host? [00:26] or can I simply use the launchpad site to propose my merge? isn't there some process for going through rietveld? [00:26] we've been collaborating using a remote dev box [00:36] bodie_: you need to set the... sensible-browser iirc, to nothing and it will print the link to authorize lbox [00:41] okay, cool [00:42] 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:43] bodie_: nope [00:43] perrito666 -- http://paste.ubuntu.com/7303428/ -- this is what I get after authorizing it from another host [00:44] ah, might be working now [00:44] did you d the whole confirmation dance? it is not as straight forward iirc [00:53] 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:55] Also I thought the MR description had to be 50 words, not 50 characters. lol [00:56] bodie_: hah, 50 characters for the first line [00:56] and then more details after that allowed [00:56] ah..... [00:57] well, that is a very terse description then, lol [00:57] ex https://github.com/juju/juju-gui/pull/249 [00:57] the 50 chars is becoming a common convention [00:57] I mean, I crammed the whole MR description into the 50 characters thinking it was the limit. [00:57] lol, no, just that first line [00:57] It's not quite twitter speak.... :$ [00:58] so that a one line diff is reasonable and no-wrap [00:58] ahhh [00:58] but you can expand/list/etc in the body of the commit [00:58] yeah === Ursinha is now known as Ursinha-afk [00:58] is there a way to amend that? [00:59] 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.... === Ursinha-afk is now known as Ursinha [01:01] axw: hello [01:02] arosales: heya [01:02] axw: were you working with thumper and davechenney on the power enablment bits? [01:02] arosales: nope [01:03] axw: ah ok [01:03] arosales: is there something broken? [01:03] axw: do you happen to know if any other juju core folks were working on power enablment besdies thumper and dave? [01:04] axw: getting a seg fault and I know there is a kernel bug opened just not sure if it was recently resolved . . . [01:04] arosales: I think waigani has been fixing some of hte tests... [01:04] and wallyworld was looking at one stage [01:04] I'm not sure if there was anyone else [01:04] there were packaging guys looking at the kernel bug [01:05] not sure of the status [01:05] bodie_: your sso acct is not setup? [01:05] sso? [01:07] axw: wallyworld: thanks for the info. Looking at https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1275620 [01:08] I think the fix may be in gccgo, just not sure when that fix is going to make it into trusty [01:08] arosales: yeah, i'm not up on the latest status sorry [01:08] i wasn't sure if it was just gccgo related or not [01:09] bodie_: strange, can you pastebin the whole output? (omitting any info that you considered not public :p) [01:09] it actually looks like Google was blocking my login from the VPS for security reasons :/ [01:09] giving it another go [01:10] arosales: what is your email? I'll forward you the latest on that issue [01:10] bodie_: oh [01:10] wallyworld: no worries [01:10] 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

[01:11] I think this is the one we are actually hitting [01:11] on -08 kernels we are ok, but anything more recent we consistantly seg fault [01:12] THERE we go. thanks google.... [01:12] https://codereview.appspot.com/90130044 ! ^_^ [01:12] 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:15] waigani: yup they look to be related [02:31] 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:32] jose: yep, reitveld is used with a tool called lbox to submit patches. [02:33] rick_h_: erm, would you mind helping me to propose an MP? [02:33] 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

[02:33] jose: I'm looking for the doc. Not done it myself. :) [02:34] oh, ok, thanks :) [02:34] jose: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/CONTRIBUTING [02:34] blargh, I suppose I need to check better for files like that in the future :P [02:34] thanks rick_h_ :) [02:34] jose: all good, thanks for going through the process [02:35] np :) [03:20] uh, looks like I'm getting an error when proposing [03:20] RuntimeError: maximum recursion depth exceeded in cmp it says [04:18] wallyworld: do we have a sprint topic about bulk API? [04:18] machine provisioning is getting pretty chatty now [04:22] axw: yes, i think so, i remember seeing it [04:22] * axw hunts [04:23] Bulk cloud API calls (both scalability, and things like port-ranges) [04:23] i also recall reading some prose [04:23] hmm that's a bit different [04:23] I'm talking about bulk Juju API calls [04:24] bulk is maybe the wrong word [04:24] I mean combining API calls, for example [04:24] i know what you mean, it's there somewhere [04:24] ok [04:25] oh hey wallyworld, have a minute? [04:25] hi sure [04:25] I'm having some problems doing a proposal for juju-core [04:26] erm, let me find the error [04:26] ok [04:28] 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:29] 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:30] hmmm. i've not seen that error before, but it looks like your initial creation of the branch missed something [04:30] what does bzr info say [04:30] launchpad is the means by which the landing bit picks up and merges the code [04:31] codereview.appspot.com is an ancilliary tool because some folks didn't like launchoad initially [04:31] let's check bzr info [04:31] but lp is the main tool via which stuff needs to be proposed [04:33] bzr info gives the same error I think [04:33] so, saying I want to get https://code.launchpad.net/~jose/juju-core/init-comment-default-series merged into lp:juju-core [04:34] would an MP be enough/good? or I still need to go through rietveld? [04:34] no, mp is fine by me. i prefer lp [04:35] ok, let's link the bug and do an mp then :) [04:35] but your bzr setup is broken though if bzr info doesn't work [04:35] bzr info is broken when I execute it via cobzr [04:35] but if I do it with bzr, it gives the following output: [04:36] http://paste.ubuntu.com/7304444/ [04:36] * wallyworld sighs - cobzr is another tools which was not needed [04:36] I should recognize the CONTRIBUTING file complicates the process x1000 [04:37] 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] bzr, lightweight checkouts,and switch are all that's needed [04:37] yeah, the contributing file talks about cobzr and lbox [04:38] sadly lbox is unavoidable since rietveld is the review tool most people like using [04:39] anyways, do your mp in lp for now and we'll get it reviewed [04:40] awesome, thanks :) [04:40] who should I set as the reviewer? or should I just leave that blank? [04:42] leave it blank - i'll look at it now [04:42] thank you! [04:42] https://code.launchpad.net/~jose/juju-core/init-comment-default-series/+merge/216660 is it [04:45] jose: the boilerplate environment.yaml file already has a commented out section for default series... [04:45] # The default series to deploy the state-server and charms on. [04:45] # [04:45] # default-series: precise [04:45] 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:46] ok, I'm modifying that line [04:46] the juju init output does tell the user to edit the yaml file to suit [04:46] thanks very much for contributing [04:46] no prob :) [04:47] 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:49] and, message changed [04:51] looking [04:52] 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:53] provider/local/environprovider.go [04:53] oh, gotcha, gotcha :) [04:56] that should do [04:58] 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] thank you [04:58] awesome! [04:58] no prob, glad I could help :) [04:58] should I mark that bug as fix committed? [04:59] jose: no, that will be done automatically by launcghpad once it lands [04:59] good then [04:59] thanks for approving! [04:59] np. you'll get an email soon hopefully saying it landed [05:00] cool [06:48] so quiet these days... :) === 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 [08:43] jam: morning [08:44] morning vladk, how's it going? [08:54] morning all [08:55] morning voidspace [09:23] morning [09:24] hey perrito666 [09:37] hello [09:40] wwitzel3: morning [09:43] voidspace: hey, enjoy the holiday weekend? [09:53] wwitzel3: yeah, very good thanks [09:53] wwitzel3: my church has a big easter celebration weekend, so I've been to six meetings [09:54] wwitzel3: so hectic, but great fun catching up with all my friends from round the country [09:54] voidspace: nice [09:54] wwitzel3: I'm just catching up with administrivia and then we should (could) hangout [09:54] also the bluebells are out [09:55] wwitzel3: you have a good weekend? [09:56] voidspace: I did thanks :) [10:01] jam: ? [10:01] perrito666: just finishing up another hangout, will be there soon [10:37] hi all,does any one know how to specify a public ip pool when juju bootstrap with openstack [10:37] when using neutron as network service [10:37] as juju can't login the instance without a public ip [10:52] yaguang: "use-floating-ip: true" in environments.yaml [10:53] jam, I see that option, but juju complains floatingip pool need to be specified [10:54] jam, with neutron, you need to specify the pool to allocate a floating ip to instance [10:56] yaguang: can you ask in #ubuntu-server about the neutron setup you need? [10:57] yaguang: note, you don't really need public ips, provided you put the machines on a network you can route to [10:58] mgz, the problem is that with public ip, instance can only be accessed in netns [10:58] s/with/without/ [11:58] 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

[11:58] ? [12:00] wwitzel3: do you have a handle on https://bugs.launchpad.net/bugs/1304407 ? [12:00] <_mup_> Bug #1304407: juju bootstrap defaults to i386

[12:02] jam, wwitzel3: this is the review: https://codereview.appspot.com/89900043/ this is the branch: lp:~natefinch/juju-core/045-amd64plz [12:02] wwitzel3: it just needs a test that we pick amd64 if it's an option [12:03] jam: let's do it [12:06] vladk: I'm in https://plus.google.com/hangouts/_/canonical.com/vlad-john [12:23] wwitzel3: let me know when you're back [12:23] hmm... [12:23] actually, I'll go on lunch [12:23] wwitzel3: I'll catch up with you in a bit [12:28] natefinch: "juju ensure-availability" takes an '-n' parameter that is mandatory. Did you discuss this with Rog? [12:28] 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

[12:28] but I wanted to check if I missed some discussion [12:32] 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:34] ok, this looks to be the conversation: https://codereview.appspot.com/81700043/diff/1/cmd/juju/ensureha.go#newcode58 [12:34] Which is "a default of 1 seems wrong" which I agree with [13:26] jam: I think 3 is the only sane default, and it's almost always useful to have a sane default [13:28] natefinch: the path from StateServingInfo into writing stuff to disk is *really* convoluted [13:29] natefinch: so I'm trying to fix EnsureAvailability so that it picks the default series based on the existing machines [13:30] natefinch: however, in client_test.go today, we don't actually *have* any state machines when we run the first EnsureAvailability command [13:30] which is completely *not the way it would be* [13:30] and it further has the bug that the StateServingInfo doc in the DB is only created when you *open* the State [13:31] after you've created machine-0 [13:31] 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] but I'm trying to reopen state, and getting "bad password cannot create the log db" [13:32] jam: the stateServingInfo doc is created at state initialize time [13:33] jam: unless we're upgrading [13:33] rogpeppe1: but in JujuConnSuite there *is no machine-0 [13:33] so there is no valid machines serving the state [13:33] there are [13:33] rogpeppe1: so we have to create one, and then get the doc to be recreated [13:33] jam: yeah, that's wrong - the tests should add a machine before calling ensureavailability [13:34] jam: but the doc is still created [13:34] jam: even when there are no machines [13:34] rogpeppe1: well, there is a doc, but it has no contents [13:34] creating the machine [13:34] jam: yeah [13:34] doesn't update the doc [13:34] so you have to create the machine [13:34] and then re-open the state [13:34] for it to put machine-0 in [13:34] rogpeppe1: unless there is some other trick I should know about [13:35] jam: i don't understand what you mean by putting machine-0 in stateservinginfo - stateservinginfo doesn't have any machine info in [13:36] jam: unless you're actually talking about state *server* info [13:36] rogpeppe1: if I do: _, err := s.State.AddMachine("quantal", state.JobManageEnviron) [13:36] rogpeppe1: then it dosen't end up in StateServingInfo [13:36] jam: StateServingInfo doesn't have any machine info in [13:36] rogpeppe1: so it still looks like there are no machines actually serving the state [13:36] jam: i don't understand your statement [13:37] jam: unless you're talking about StateServerInfo [13:37] rogpeppe1: sorry, I think you're right about StateServerInfo [13:37] because that's not confusing ;) [13:37] just a typo looking through similarly named things on 5 different object types [13:37] jam: and StateServerInfo *should* be maintained by AddMachine [13:37] jam: if it isn't, that's a regression and needs to be fixed [13:37] jam: but i'm pretty sure it is [13:37] jam: otherwise the logic wouldn't work [13:37] rogpeppe1: I'm pretty sure just doing AddMachine doesn't put any MachineIds into StateServerInfo [13:38] jam: it definitely should do [13:38] EnsureAvailability does [13:38] so the tests that start with EnsureAvailability(1) work [13:38] and bootstrap does [13:38] so in real-life it works [13:38] rogpeppe1: but in real life we never have a case where there is no machine-0 [13:38] because life starts somewher :) [13:43] ahh,, ffs, I can't just poke EnsureAvailability either because that notices that len(VotingMachines) == 0 [13:44] 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] natefinch: the fact that JujuConnSuite doesn't match a bootstrapped environ is bad here [13:45] natefinch: it is the only place where you have a Mongo running and *no* machine to host it [13:45] jam: about a million years ago I tried to change things so the dummy environ creates a bootstrap machine [13:45] jam: but it broke many many tests [13:46] rogpeppe1: I can imagine [13:46] it makes it hard to do things like "machine-0 is *this* type of machine" [13:46] jam: because we have loads of tests that assume that the first machine created has id 0 [13:46] 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:47] rogpeppe1: state/open.go has newState() which calls createStateServersDoc [13:47] which notices that if "len info.MachineIds == 0" then it will create it. [13:47] jam: yeah, it needs to [13:47] jam: because we might be in an upgraded environment [13:47] jam: but state.Initialize calls state.Open [13:47] rogpeppe1: sure, it just means I can backdoor it. [13:48] jam: you should not need to [13:48] rogpeppe1: I have to create the machine, then get it to run the upgrade ode [13:48] code [13:48] jam: AddMachine with JobManageEnviron *should* add the machine to StateServerInfo [13:48] rogpeppe1: it doesn'tt [13:48] flat out [13:48] it doesn't [13:48] jam: i thought there were tests that tested that specifically [13:49] rogpeppe1: so I see maintainStateServerOPs [13:49] jam: State.AddMachines calls maintainStateServerOps [13:49] but when I'm testing it, I see len(VotingMachineIds) == 0 [13:49] jam: which should do that [13:49] jam: there are no *voting* machine ids [13:49] jam: but there will be a non-voting machine [13:50] rogpeppe1: if there is only machine-0, why wouldn't it be voting ? [13:50] rogpeppe1: ok, PEBKAC, it wasn't the test I fixed that was failing, it was the other tests. [13:50] jam: that's a reasonable question. [13:50] that *weren't* creating a machine [13:51] jam: BTW i think the logic should create a voting machine id unless NoVote is true [13:52] rogpeppe1: well, again, that isn't the "standard" path that we're going to get machine-0 is it? [13:52] maybe it is [13:52] the first step is just AddMachine(the thing I just started) [13:53] jam: AddMachine should add the machine to the voting servers [13:53] jam: i'd be surprised if it doesn't [13:53] rogpeppe1: so it might, I'll have to double check that now that I've sorted out which tests are actually failing [13:53] jam: ok [13:53] I certainly expected that we would always have 1 voting machine [13:54] jam: i believe we do [13:54] but stuff broke because we never created machine-0 [13:54] jam: (after the first machine is actually created) [13:54] and I fixed that for one test, and the others broke, and I thought it was my test that was breaking [13:56] ok, we have a voting machine after AddMachine [13:58] jam: good. everything seems to be working as it should then. [14:02] jam: BTW i think it might be reasonable if AddMachine also took its series from the state server machines by default [14:03] jam: because then at least we know that calling juju add-machine will work [14:05] 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] jam: yeah [14:06] s/arch/series/ [14:08] voidspace: https://code.launchpad.net/~wwitzel3/juju-core/008-ha-rsyslog [14:11] natefinch: rogpeppe1: so AXW's comment seems to me that he wanted a default to mean "preserve the existing availability" [14:12] 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] 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:13] 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] jam: which comment? [14:13] rogpeppe1: https://codereview.appspot.com/90160044/ [14:13] about the default N for ensure-availability [14:13] jam: ok. but are you amenable to the change in principle? [14:13] * jam goes to spend time with the familyd [14:14] jam: +1 to making the default the current number [14:14] I haven't particpated in the discussion enough to really contribute there. [14:14] 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:19] jam: i had a "LGTM but please use errgo for the package identifier" [14:19] jam: which is basically what i'm doing now [14:19] jam: but that was a little while ago. the LGTM might have expired. [14:20] jam: i can make the changes in about 15 seconds, but lbox proposing it takes ages. [14:25] hi guys, can I get a review on our MR? https://code.launchpad.net/~binary132/juju-core/skeletal_actions/+merge/216651 [14:25] it's a little hefty [14:25] whenever you have time [14:25] thanks in advance :) [14:26] rietveld at https://codereview.appspot.com/90130044 [14:29] voidspace: http://www.rsyslog.com/sending-messages-to-a-remote-syslog-server/ [14:29] rogpeppe1: what does swapping in errgo get us right now? Do we get file/line numbers for those errors? [14:30] 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] natefinch: and, yes, we might get file/line numbers for those errors [14:31] rogpeppe1: keeping that code from bitrotting seems worthwhile [14:31] natefinch: (but those errors aren't really the important ones as they're easy to grep for) [14:31] natefinch: that code has already bitrotted (i just do it from scratch each time), but the conversion program may bitrot [14:33] is the ProvisioningScript the api call i would use to "juju run" a shell script before any of the hooks are run? [14:34] 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] natefinch: cool === Ursinha is now known as Ursinha-afk [14:37] or is an api command available that allows me to run abitrary commands on a machine before any hooks are executed [14:41] stokachu: what are you trying to accomplish? [14:42] natefinch: writing a plugin to do some initial setup on the machine before running a charm [14:42] stokachu: you can always do add-machine, set up some stuff, and then deploy --to it [14:42] natefinch: by doing juju run or juju ssh? [14:43] stokachu: juju run, yeah. You can do juju add-machine, juju run --machine 1, juju deploy foo --to 1 [14:44] so how do i do it through the api? [14:44] i want to pass it a script to run [14:45] 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:46] i can add-machine through the api just fine [14:46] stokachu: there's a RunOnAllMachines api endpoint === Ursinha-afk is now known as Ursinha [14:48] so that endpoint RUnOnAllMachines, does it support passing a script over the wire? or is it for running commands independently [14:50] stokachu: looks like it just takes a list of commands, not a full script [14:51] ok [14:51] is the run commands done as root as well? [14:51] i dont have to worry about sudo or anything like in the charms? [14:52] stokachu: yeah, it's run as the "ubuntu" user which generally has root privs [14:53] ok cool [14:54] so essentially i could run juju scp, then call the api to execute that command [14:54] stokachu: that should work, yeah [14:54] 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] in the api section of the code anyway [14:57] stokachu: yeah, scp doesn't use the API [14:57] ok cool, thanks man [14:58] welcome [15:02] natefinch: last question, other than juju scp is there any other way to upload files to machine using the api? [15:02] rogpeppe1, natefinch: I don't think Go van only import a master branch from git. Am I wrong? [15:02] sinzui: i'm not sure what you mean [15:03] sinzui: the only thing in Go that knows about branches is "go get" [15:03] marcoceppi: maybe you know? ^ [15:03] stokachu: I don't think so. What's wrong with using the juju client's juju scp? [15:03] natefinch: if im on a remote machine with no juju client [15:04] 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] rogpeppe1, right. I can "go get" github.com/juju/core/1.18 [15:04] ^ rogpeppe1 I mean I can *not* [15:05] sinzui: you can always use version control to get a branch before building it with go [15:05] natefinch: yea just wanted the ability to interface with juju without relying on juju binary [15:05] stokachu: but..... you have *code* that you're relying on somewhere. [15:05] rogpeppe1, for CI and releases, I need to keep the branch info separate and I need another step to checkout that branch [15:06] can I have a review on https://codereview.appspot.com/90310043 [15:06] rogpeppe1: ^ you should be on holiday, no? (but if not... :) [15:06] natefinch: yea but that doesn't necessarily mean i have to have juju installed with it [15:06] natefinch, That presumes a little too much. Currently, we use go get, then switch to the branch. [15:07] natefinch, Then run godeps to pin all the branches to the correct version [15:07] stokachu: well, otherwise you're just duplicating effort with what we have in juju client [15:08] natefinch, The new issue is that bzr urls has branch and (implicitly) repo, git only supports repo (implicitly master) [15:08] natefinch: what if its library bindings [15:08] 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:10] 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] stokachu: not sure what you mean. [15:11] 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:17]