=== axw-away is now known as axw
axwwallyworld: https://codereview.appspot.com/91740043/03:00
axwtested live with maas03:00
wallyworldaxw: already looking :-)03:00
axwgoing to go do some packing, bbiab03:00
axwwallyworld: hrm, it is selecting the instance but it doesn't seem to be bootstrapping. I will continue investigating... there may be another change required to bootstrap though03:09
wallyworldbranch looks ok - i did have a suggestion about the error checking in bootstrap03:09
wallyworldi've +1ed it so you can land once it works :-)03:10
axwwallyworld: testing again with a fresh maas node, could've been because it was dirty03:21
axwwallyworld: I didn't want to return other errors because we don't care about whether they're well formed03:21
axwwallyworld: just that they're unscoped or not03:21
axwbootstrap doesn't care if you specify an lxc placement with an invalid machine id03:22
axwbecause it just doesn't support lxc placement03:22
wallyworldaxw: ok, it makes sense now that i think a bit harder03:29
axwalrighty, worked fine with a new node03:31
jamwallyworld: https://code.launchpad.net/~wallyworld/juju-core/bootstrap-supported-series/+merge/216974 LGTM04:09
jammorning all04:09
wallyworldjam: great thanks04:09
jamwallyworld: fwiw I think we actually want to target 1.18 with that patch04:10
wallyworldjam: we want to get a lot of stuff into 1.1804:10
jamwallyworld: since 1.18 local is broken in the same way04:10
wallyworldi'll land in 1.19 first cause that ships tomorrow and then will back port04:11
jamwallyworld: *I* find it much easier to land to 1.18 and then merge up, but as you wish04:11
wallyworldi just cherry pick :-)04:11
wallyworldbut i can see that could get messy easier than landing to 1.18 first04:12
jamwallyworld: 1 case isn't bad, N cases starts to get hairy04:12
jamwallyworld: can I ask to have you peek at https://code.launchpad.net/~natefinch/juju-core/045-amd64plz/+merge/21661204:12
jamIt looks like FindInstanceSpec doesn't like that we prefer amd64 now04:13
jamand I think you have some familiarity with that code04:13
wallyworldthat was actually on my list04:13
wallyworldcause i tried to land it this morning04:13
wallyworldthere's a couple of failures04:13
wallyworldjam: btw, is the weekly meeting on tonight with everyone away? i can't make it cause it's my son's birthday04:14
jamwallyworld: you lazy slacker, how dare you have a family life! :)04:14
wallyworldyeah, bad i am04:14
jamwallyworld: I think we'll still do it with whoever is around04:14
jambut don't feel bad04:14
wallyworldsure, axw was wondering also04:14
wallyworldprobs will just be discussing getting 1.19 out anuway04:15
axwwoot, maas-name is merged04:21
jamaxw: so that is "juju deploy --to maas-name:foobar" ?04:32
axwjam: sorry was eating lunch. not quite; for one thing deploy/add-unit are not supported yet (I opened a new bug for that)04:47
axwjam: we can now do "juju add-machine [env-name:]<maas-name>"04:48
axwjam: also s/add-machine/bootstrap/04:48
jamaxw: [env-name:] why wouldn't it be -e envname ?04:48
axwjam: it's how fwereade wanted it, not exactly sure when we'd have env-name != implied env04:49
axwjam: but you can leave it out altogether and it uses the implied env name04:49
jamwallyworld: lp:~wallyworld/juju-core/bootstrap-supported-series just bounced with test suite failures04:49
axwjam: I *think* it's for multi-env04:49
wallyworldah, ok, just about to propose the i386 branch04:49
wallyworldwill look in a bit04:50
jamwallyworld: I'm looking at your constraints vocabs patch04:50
wallyworldgreat ta04:50
jamwallyworld: reviewed https://codereview.appspot.com/96730043/04:58
wallyworldta, will look rsn04:58
jamwallyworld: On your SeriesToUpload patch, I was surprised to see Lucid04:59
wallyworldjam: i didn't add it, it was already there04:59
wallyworldi think the test just set it up as the preferred series in config05:00
wallyworldjust to have something other than precise to use05:00
wallyworldjam: i tweaked some metadata and a test and fixed a nil pointer issue and it seems to work now https://codereview.appspot.com/90720043/05:02
jamwallyworld: LGTM05:03
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
fwereadeaxw, jam: it's not really env-name, it's provider-name (or, heh, really more like account-name) but since we don't have those concepts in play at the moment we can't sanely reference them06:56
jamfwereade: fwiw, Id rather bring that in  when we actually have multi-provider environments06:56
jambut as long as you can just leave it off, I guess it is fine.06:57
jamI do wonder if we want to continue the --to syntax06:57
axwyeah, just as long as we don't prevent future use06:57
jamsince that would match how it would end up on things that aren't bootstrap and add-machine06:57
jambut I suppose add-machine already uses the ssh: syntax06:57
fwereadejam, axw: yes, Iwould generally prefer that we not make a big deal of the prefixes; I just wantthem in place for when we do06:58
fwereadejam, axw: I think a placement directive is meaningful both as a positional arg and as a --to payload06:58
fwereadejam, axw: and it's to our benefit to make it look nice and easy in both cases, just as it is to our benefit to design it such that we can expandin plausibledirections in future without having to change everything ;)06:59
axwme too. "I'm bootstrapping $machine" vs. "I'm deploying $service to $machine"06:59
jamfwereade: axw: any chance that your change allows "juju bootstrap ssh:user@host" at the same time ?07:01
fwereadeaxw: although, hmm, I suddenly fret that --to works better on bootstrap...07:01
axwjam: no, I did think of that, but it's not possible atm07:01
axwjam: because we use the bootstrap-host when preparing07:01
fwereadeaxw, jam: I'm not quite sure what positional arg I would be saving it for07:01
fwereadeaxw, ah, that's a shame07:01
axwjam, fwereade I added a TODO in provider/manual to revisit it tho07:02
jamaxw: AIUI we have a bug open on it07:02
fwereadeaxw, it does STM that we don't really even need an environments.yaml for that case,though07:02
fwereadeaxw, that's a bigger change, but one we should make soonish07:02
jamaxw: bug #128221707:03
_mup_Bug #1282217: Specifying bootstrap-host requires editing environments.yaml <bootstrap> <ci> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282217>07:03
fwereadeaxw, I haveto write it upproperly for vegas07:03
jamand possibly bug #128264207:03
_mup_Bug #1282642: Bootstrap prefers .jenv over environments.yaml <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1282642>07:03
axwah yes, that's right07:03
jamfwereade: so AIUI in bug #1282217, we need it in Prepare because we potentially call SyncTools before we bootstrap07:03
_mup_Bug #1282217: Specifying bootstrap-host requires editing environments.yaml <bootstrap> <ci> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282217>07:03
axwjam, fwereade: the main issue is that we have multiple ways of preparing an environment, and it currently needs to be usable before bootstrap07:03
jamhowever, sync-tools is sort of dying anyway, so I'd rather not tie us to that07:04
fwereadejam, yeah, but I'm not sure there's any reasonable remaining justification for sync-tools07:04
fwereadejam, axw: I don't *think* there's anything beyond sync-tools keeping Prepare distinct from Bootstrap, is there?07:04
axwfwereade: only plugins, but they probably don't need it07:05
jamfwereade: Prepare is the time when we take the rough template and fill out all the random bits07:05
jamso I don't mind it as a step07:05
jambut that step can happen only during bootstrap for all I care07:05
axwthat would be nice07:05
fwereadejam, yeah, I'm not really against *prepare* so much as I am against environments.yaml07:05
jamfwereade: I *think* the fact that we gave bootstrap --source means we've replaced the other needs we had07:05
jamfwereade: with some possible caveats07:07
jamlike I think we are missing a way to say "Give me a copy of the tools that are at $URL"07:07
axwthe juju-metadata plugin uses PrepareFromName. does it need it to?07:07
jamand --metadata-source requires it to be a local path07:07
jamso you can bootstrap from a public URL either07:07
axwI think it might, so we can prepare tools and metadata in keystone or whatever07:07
jamaxw: I'm a firm believer that metadata should not be a plugin07:07
jamaxw: and I think it is in the same boat as sync-tools, in that when you are preparing your own image/tool metadata07:08
jamyou can't have an env bootstrapped yet07:08
jambecause you're creating its infrastructure07:08
axwright... so it just needs to be able to deal with an "unprepared" env config07:08
jamaxw: but I don't think manual actually needs it, since you're not doing image lookup if your target is manual07:09
fwereadejam, axw: I dunno, I feel like creating metadata and uploading it are very distinct things07:09
jamyou may need it for tools07:09
fwereadejam, axw: and that separation points towards the pluginness being a good thing07:09
jamtohugh again, I think --source for bootstrap is a better workflow there07:09
fwereadejam, axw: it probably shouldn't be about environments at all07:09
fwereadejam, axw: plugins for metadata generation, for them as needs it07:10
jamfwereade: actually, I firmly believe it shouldn't involve an env, because I often try to configure stuff, and I don't have a default env, and it just goes "poo" you must set -e07:10
jamfwereade: afaict it doesn't really do anything with the env, at least for generate07:10
jammaybe validate will use it for where to find the stream data07:10
fwereadejam, axw: --source args that let you point at local or remote metadata that gets pushed into your environment07:10
fwereadejam, axw: would be nicest of all, really, to have validate again just point at a metadata source07:11
fwereadejam, axw: then if an environment uses that source, yay, you know it's validated07:11
axwfwereade: how do point at the environment storage?07:12
axwalthough hm, the tools don't actually upload to env storage?07:15
jamaxw: the metadata does07:15
jamor can07:15
axwjam: sorry I meant the plugin. doesn't look like it does... maybe there's a flag I'm missing07:16
axwanyway, if we can make it so prepare is only ever called by bootstrap that would be awesome07:17
fwereadeaxw, jam: yeah, I don't think we really need to -- although I think I'm backing off the idea that you *can't* validate metadata for an env, it still seems perfectly reasonable to just take the source from the env and check that source07:19
axwseems sane. I think once it's in the env, it should be reasonable to assume it's valid07:21
jamfwereade: I feel like you have a better handle on what should be happening while hooks are firing, I think I've gotten the context down small enough in https://bugs.launchpad.net/juju-core/+bug/1311825 but I don't quite understand why it does/doesn't do stuff07:48
_mup_Bug #1311825: test failure UniterSuite.TestUniterUpgradeConflicts <ci> <intermittent-failure> <test-failure> <juju-core:In Progress by jameinel> <https://launchpad.net/bugs/1311825>07:48
jamfwereade: do you want to Hangout about it?07:49
fwereadejam, sure, but you may just be watching me catching up07:50
jamfwereade: https://plus.google.com/hangouts/_/canonical.com/john-william07:51
mfoordmorning all08:42
fwereademfoord, heyhey09:03
mfoordfwereade: o/09:06
fwereadejam, https://codereview.appspot.com/9272004409:10
jamfwereade: LGTM09:11
jamfwereade: me thinks we might want that patch in 1.18 ?09:11
jamsince it is about making CI happier to make releases09:11
jamfwereade: provisioner treats no tools as error: https://codereview.appspot.com/9372004409:34
natefinchmorning all09:37
jammorning natefinch09:43
jamnatefinch: care to start your day with a review ? https://code.launchpad.net/~jameinel/juju-core/1.18-provisioner-no-tools-is-fatal-1311676/+merge/21701109:43
natefinchjam: sure09:45
natefinchperrito666: morning09:52
* perrito666 notices his bug resembles a mamushka doll09:54
axwjam: not going to be able to make the meeting, I have to look after my daughter09:59
jamaxw: np10:00
axwalso I have tomorrow off - national holiday. see you all in vegas10:00
jamaxw: see you next week10:00
jamfwereade: standup ?10:01
perrito666axw: you can bring your daughter to the meeting its becoming a thing :)10:02
natefinchaxw: see you in vegas10:02
natefinchperrito666: you have a point :)10:02
jamvladk|offline: group standup ?10:03
* perrito666 sees the test running for too long and knows he is about to get an error10:32
=== vladk|offline is now known as vladk
mfoordnatefinch: you need to bring your daughter to Vegas. Daily standups without her just won't be the same...10:45
natefinchmfoord: haha10:45
psivaajam: hey, could you help taking a look at http://paste.ubuntu.com/7315688/  for juju bootstrap with trunk version, 1.19.1-trusty-amd64 pls?11:25
jampsivaa: known bug we won't fix, you have to use --upload-tools to bootstrap trukn11:27
psivaajam: ack, i think i tried that too. let me do that again. thanks11:28
jampsivaa: bug #130833711:28
_mup_Bug #1308337: 1.19.1 cannot bootstrap 1.19.0 (no longer installs mongodb-server during bootstrap) <regression> <juju-core:Won't Fix> <https://launchpad.net/bugs/1308337>11:28
psivaajam: thanks. with --upload-tools i got http://paste.ubuntu.com/7314791/ in a private cloud. not sure if the cloud being overly restrictive is any reason.11:30
psivaai'll try that with hpcloud11:30
jampsivaa: you're using juju-core with gccgo and not compiling with static linking11:30
jampsivaa: var/lib/juju/tools/ error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory11:30
jampsivaa: you need to set flags, let me go look them up11:30
jampsivaa: var/lib/juju/tools/ error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory11:31
jampsivaa: INSTALL_FLAGS := -gccgoflags=-static-libgo11:31
jampsivaa: so you should be doing "go install -gccgoflags=-static-libgo" when building juju from trunk11:31
psivaaack, will try that. thanks jam11:31
wwitzel3anyone else having issues with publickey denied with juju ssh to machine 0? using local provider?12:02
jamwwitzel3: your local machine isn't accepting your own ssh key, but that isn't that uncommon. ssh 0 is never guaranteed to work ,because most people don't even run openssh on their laptop/etc12:12
jamwwitzel3: what command are you running?12:12
jameg "juju debug-log" never worked with local until recent 1.19.1-ish stuff12:13
jamthumper turned debug-log into an api call.12:13
wwitzel3jam: just juju ssh 012:43
jamwwitzel3: right, that depends entirely on if "ssh localhost" works12:44
jamwwitzel3: not something guaranteed for local provider12:44
wwitzel3jam: well, I can run ssh localhost and it works as expected12:45
jamwwitzel3: sorry, can you "ssh ubuntu@localhost" ?12:45
wwitzel3jam: oh right, because that is the user it is expecting12:45
mfoordcanonical wiki not responding12:46
mfoordand I want some lxc information from it12:46
mfoordso that seems like a good time to go on lunch12:46
mfoordback soon(ish)12:47
wwitzel3miss you already12:47
mfoordwwitzel3: liar :-)12:47
perrito666mfoord: also irc server is not letting me connect12:48
jammfoord: wiki just came up for me12:48
jamslow, but it did come up12:48
jamI can't land anything on the 1.18 branch on the bot, the test suite is broken on tip13:10
jamdidn't wallyworld have a patch recently because we had some test isolation issues when releases were made?13:10
* wallyworld has vague recollections but can't recall the details13:11
jamwallyworld: does https://code.launchpad.net/~jameinel/juju-core/1.18-provisioner-no-tools-is-fatal-1311676/+merge/217011/comments/515862/+download ring any bells ?13:12
jamwallyworld: I'm just getting lots of "no tools available" failures on the 1.18 branch13:13
jameven without my patch (if I SSH in manually and try it)13:13
jambut it passes on my machine on trusty13:13
wallyworldjam: it's the changed lts thing13:13
jamah, ffs, LatestLTSSerise became trusty13:13
jamso all the tests that were expecting "precise" to just work13:13
wallyworldjam: i fixed it in trunk with the SeriesToUpload fix13:14
wallyworldit sorta worked before but then we got the %LTS% placeholder put in13:15
jamwallyworld: I can land my patch today by just editing /usr/share/distro-info/ubuntu.csv ...13:15
jamand making Trusty come out next month13:15
wallyworldi need to backport a bunch of fixes to 1.1813:16
jamwallyworld: well, the test which failed now passes on the bot13:16
jamI feel a bit dirty, but I feel *very* pragmatic13:16
wallyworldsometimes that's fine :-)13:17
wallyworldjam: so it seems we won't have 1.19.1 for ODC unless we shift out some bugs13:18
jamwallyworld: High bugs don't block releasing 1.19.113:18
jamwallyworld: they're just the stuff I want next on everyone's queues13:19
jamthey probably block 1.2013:19
jamHigh 1.19.1 bugs do, High 1.20 bugs probably don't...13:19
jamas we're essentially doing priority by keeping multiple milestones13:19
jamnatefinch:  wwitzel3: can I get a trivial review: https://code.launchpad.net/~jameinel/juju-core/1.18-panic-parsing-jenv-1312136/+merge/21703613:28
jamwe were ignoring an 'err' return that could cause a later pani()13:28
wwitzel3+ 1 we shouldn't do that13:28
wwitzel3haha, taking a look13:28
alexisbdude! you guys are kicking a** on bugs!13:31
jamalexisb: well, I feel like I'm reporting as many as I'm fixing, but we are doing a lot of them13:33
alexisbjam :) understood13:33
alexisbbut finding them is important to13:33
wwitzel3jam: that's interesting, because it was declared as a var and then used in scope at the bottom of the fuction, it wasn't an compile time error when we didn't use the err we get back from the function.13:33
alexisbeither way the progress is impressive13:33
jamwwitzel3: hypothetically I should be adding a test for that path13:33
alexisbjam are we seeing a lot of regressions from HA and vlan landing?13:34
jamalexisb: we are seeing a lot of things that don't work when HA is enabled13:35
jamnot quite the same thing13:35
jamwhen you don't *use* HA, then everything still works13:35
alexisbjam ack13:35
alexisbthat is better then HA breaking everything :)13:35
fwereadenatefinch, please remind me how arch selection works after your change -- do we pick amd64 by default, regardless of client?13:38
jamalexisb: right. I think it falls under "not a regression, but fairly important bugs" which is reasonable13:38
jamgiven that HA isn't by-default13:38
fwereadenatefinch, if so, am I right in thinking it should also resolve https://bugs.launchpad.net/juju-core/+bug/1274755 and https://bugs.launchpad.net/juju-core/+bug/1262967 ?13:39
alexisbjam we will need to flush out the HA bugs and get them fixed before 1.2013:40
natefinchfwereade: I changed it to just select the same arch as the host if possible13:42
natefinchfwereade: since jam had made a good point that otherwise we'll break --uploańĎ-tools13:42
alexisbjam, for the HA sprint discussion...13:43
jamfwereade: I don't think it fixes https://bugs.launchpad.net/juju-core/+bug/127475513:43
jamthat is that our canned data doesn't include other ARCH13:43
alexisbdo you think it is a mini topic or needs a full timeslot?13:43
fwereadenatefinch, that seems backwards -- aren't we restricting by available images/tools before going further?13:43
jamalexisb: I think we're going to be talking a lot about next steps for HA, TBH13:43
jamfwereade: https://bugs.launchpad.net/juju-core/+bug/1274755 is a test-suite bug13:43
jamfwereade: so if you just run "juju bootstrap" it will pick something13:44
jamif you later run "juju upgrade-juju --upload-tools"13:44
jamWe've at least had support requests13:44
jamwhere they expected the latter to work, but were on say i38613:44
jamand you can't upload i386 tools to an amd64 env13:44
jamI'm not *sure* what clouds would have amd64 and ppc64 and then run from a ppc64 client13:45
natefinchfwereade: the arch check is the last thing we do, after other considerations (tools and constraints)13:45
jamalexisb: I'm *mostly* concerned that we have time allocated to doing the work13:45
jamalexisb: We can do the actual discussion in the bar, but I do think it is going to have a longer tail if we really want polish13:45
alexisbyep we are planning to but time aside for core coding13:46
jamalexisb: so are you saying I can have time for my team to code, or time to discuss HA ?13:47
alexisbI am saying we have already planed to have time for coding, and I can schedule time for HA discussion if needed13:48
jamalexisb: sounds good13:53
jamI realize I'm adding them late, but when I come across them, I figure it is better to bring it up13:53
jamwe'll probably be adding some during the week as well, I would imagine13:53
alexisbyes something tells me this will be a dynamic plan13:54
alexisbI am just trying to ensure we capture everything and make note of it13:54
jamalexisb: certainly, and I *definitely* appreciate that I can fire off a "we should talk about this" and not have to actually schedule it myself13:57
jamwwitzel3: I think the code in question wanted to do shared error handling, and then just didn't, or was refactored out of being shared. I can poke at it a bit more13:59
jamwwitzel3: I can't land it yet on the bot because of the Trusty / Utopic stuff (still needs to land my other branch which fixes 1.18 branch to pass the test suite again)13:59
coreycbHi, I'm getting connection failed, will retry: dial tcp connection refused' on bootstrap of local provider on trusty13:59
fwereadenatefinch, jam: dammt, I thought we'd done the SupportedArchitectures work to head that sort of problem off at the pass14:00
jamwwitzel3: cfg is needed because it gets used later on14:00
fwereadenatefinch, jam: anyway, thanks, I won't close the bugs then :)14:01
jamwwitzel3: and you can't return 'cfg' without returning 'err' I believe, we could declare 'err' more locally but we can't use := syntax14:01
jamfwereade: *shrug* I'm not sure. I'm just giving my synopsis of the bug14:01
jamsince we don't have that platform on-hand to test it14:01
jammaybe it works14:01
jamwallyworld was doing testing on ppc64, right?14:01
fwereadejam, indeed, but the evidence does not strongly point that way :)14:02
coreycb/var/log/upstart/juju-db*.log has:   "/bin/sh: 1: exec: /usr/lib/juju/bin/mongod: not found"14:02
jamcoreycb: do you have "juju-local" installed ? it should bring in "juju-mongodb"14:03
coreycbjam: nope14:04
jamcoreycb: I believe in trunk we detect if juju-local is available and if not, request that you install it14:04
fwereadejam, you remember updating the ec2instance types a couple of months ago? do you recall where you got the cpu-power scores?14:04
coreycbjam, that fixed it.  I don't think it notified me to but I could hvae missed something.  I know it told me to install mongodb-server.14:05
jamcoreycb: 1.18 detected fixed dependencies, which were valid on precise, but not trusty14:05
jamso instead we now require juju-local14:05
jamwhich brings in the right things on both platforms14:05
coreycbjam, ok I'm on 1.18.1-0ubuntu114:06
jamfwereade: I believe they changed their webpages :(14:07
natefinchjam, wwitzel3:  we should declare err inside the if scope.  Yes, you'll need to do it in two places, but it'll ensure the compiler knows if you don't use it14:07
fwereadejam, yeah, and now the only provider that understood cpu-power no longer gives us values14:08
jamfwereade: found it: https://aws.amazon.com/ec2/pricing/14:08
jamfwereade: it is under pricing, but not under instance types14:08
fwereadejam, ah-ha! thanks14:08
jamnatefinch: i did14:08
jamthough it feels pretty wasted victory14:08
jamnatefinch: that is going to be something RSN someone is going to say "Why is this code duplicated" and pull it out as they refactor the function and forget to handle the err :)14:09
jambut I *did* add a test for this case14:09
fwereadejam, and there's some new ones, might as well add them (since I'm fixing a typo and looking them up anyway ;p)14:09
jamnote that the code still has another bug14:09
jamwhich is if envs.Config() doesn't return IsNotFound14:09
jambut returns some other err14:09
jamit is going to break again14:09
natefinchjam: yeah, I was going to mention that14:09
jamnatefinch: so you can pick up my patch if you want, but I'm way past EOD and shaving yaks is not a good start to my weekend14:11
natefinchjam: no problem14:12
jamnatefinch: its pretty obvious that the author thought err was going to bubble up and be handled14:12
jambut isn't14:12
jamlike, why handle only IsNotFound here14:12
jamnatefinch: so I'd appreciate handoff of https://code.launchpad.net/~jameinel/juju-core/1.18-panic-parsing-jenv-1312136/+merge/217036. If you like it well enough, Approve it, if you want to tweak it, feel free14:13
natefinchjam: sure, I'd like to handle the non-not found error14:15
natefinchjam: seems like we don't need to handle notfound special there, just return whatever error we get14:15
jamnatefinch: sgtm, I'm not sure what errors we could handle14:17
jamwhich means we probably want to move the Warningf that I have14:17
jamand share the err14:17
jamnatefinch: the Warningf is because otherwise we don't inform the user that there data is bad, because we are trying to connect on the other Try14:18
natefinchjam: so always warn if we return a non-nil error?14:20
jamnatefinch: I think we could not warn on NotFound14:20
natefinchjam: yeah, that seems valid14:21
natefinchjam:  someone higher up is probably checking for isnotfound anyway14:21
jamhappy birthday to Vladk14:25
vladkjam: thanks14:25
perrito666vladk: hey hb14:26
perrito666why is calendar not telling me that its your bd?14:26
wwitzel3vladk: nice job, do it again next year ;)14:27
fwereadejam, another question about the m3 instance types -- they seem to accept both paravirtual and hvm images. do you know any particular reason to choose one over the other?14:31
coreycbare individual juju command options documented somewhere?14:35
=== vladk is now known as vladk|offline
natefinchcoreycb: juju help <commandname>14:36
coreycbnatefinch, duh, thanks :)14:36
natefinchcoreycb: np :)14:36
fwereadealexisb, I've just realised I've been listening to the hold music on the cross-team call for 10 mins -- do you know if it's happening?14:38
coreycbhmm 'juju debug' gets - ERROR control-bucket: expected string, got nothing14:39
alexisbfwereade, I think mark sent a cancellation notice14:39
coreycbsorry, juju debug-log14:39
alexisbbut you are not the first to ask so maybe not14:39
bloodearnestfwereade: it just got all electro-funk on me14:40
fwereadebloodearnest, yeah, it was a bit more soothing when I started listening14:40
fwereadealexisb, well, I'll drop off for now, I'm around if I'mwanted14:41
rick_h_fwereade: same here. I just gave up.14:42
rick_h_fwereade: looking through my mail for any missed notice14:42
fwereaderick_h_, couldn't find one, but iirc he is at gophercon14:42
rick_h_yep, conference has swallowed our teams14:42
alexisbyep sorry guys14:43
alexisbI would run it but I dont have the leader code14:43
alexisband I am on a plane14:43
rick_h_all good, see everyone in 4 days14:43
natefinchalexisb: I thought you were going to be there yesterday?14:45
alexisbnatefinch, I was14:46
alexisbI ended up in the ER14:46
alexisbit is a long story14:46
natefinchalexisb: whoa, hope everything's ok14:46
alexisbbut I am headed that way now14:46
alexisbyes just complications from the cold I had 3 weeks ago14:47
alexisbbut I promise everyone I am not contagious I wont get you sick14:47
natefinchalexisb: heh... I thought I was getting over my three (now almost four) week cold a couple days ago, and it just got worse.14:48
coreycbhas anyone seen this?  http://paste.ubuntu.com/7322857/14:49
coreycb(sorry for so many questions this morning)14:49
natefinchcoreycb: hmm you don't really need to do debug-log locally, since you can just view the log yourself.  But I do wonder if that's a bug in local14:53
perrito666alexisb: plane with internet sweet, here I was once asked to shut down my ipod (as in old, no internet ipod) for takeoff :p I certainly would not be allowed to use internet on flight14:54
natefinchfwereade: any known issues with debug-log on local?  Seems like it would try to ssh to localhost's port 22, and I'm not sure we can guarantee it'll be open?14:55
coreycbnatefinch, yeah I can just log into the machine for now14:55
natefinchcoreycb: it's the local provider, right?  So the logs should be under ~/.juju/local14:56
coreycbnatefinch, yes it is.  ok thanks14:57
fwereadenatefinch, not sure it ever worked properly until thumper's debug-log-via-api, thought it'd work now15:00
fwereadenatefinch, although, yeah, you can always just look at the logs ;)15:00
natefinchfwereade: is that post 1.18.1?15:00
fwereadenatefinch, I *thought* .0, but I'd have to go hunting15:00
natefinchfwereade: it's ok. I can try it out and see what's going on15:01
fwereadenatefinch, cheers15:01
natefinchanyone else having bzr issues?   I presume it's a launchpad connection problem.15:08
wwitzel3natefinch: everything was giving me issues earlier, but apparently there were some networking issues. Seems fine for me now.15:45
wwitzel3natefinch: though still a bit slower than normal15:45
natefinchwwitzel3: that's good16:15
natefinchrogpeppe: hey, how's gophercon?16:15
rogpeppenatefinch: great so far!16:15
rogpeppenatefinch: (apart from the hangover)16:15
natefinchrogpeppe: haha, well, only one person to blame for that. ;)   I hear the lower air pressure makes alcohol more effective up there16:15
rogpeppenatefinch: yeah16:17
natefinchwwitzel3: can you review my update to john's branch?  I think it's a lot easier to read, and also handles an error path that his change was missing: https://codereview.appspot.com/9074004416:30
mfoordI was wrong about rsyslog v5 docs not being online16:37
mfoordthankfully they are16:37
fwereadenatefinch, LGTM, much nicer16:38
mgzrogpeppe: how do you have a hangover already...16:38
perrito666mgz: clearly drinklag16:39
mfoordrogpeppe: hey, hi16:40
mfoordrogpeppe: obviously the right fix for the hangover is to start drinking again16:40
sinzuinatefinch, rogpeppe : CI still fails trunk because of precise unit tests: https://bugs.launchpad.net/juju-core/+bug/131226116:46
_mup_Bug #1312261: 3 unit tests  fail the entire precise suite <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1312261>16:46
sinzuinatefinch, or wwitzel3 , or anyone. ^ any ideas what can be done to the tests or to the test setup to make them pass on precise?16:49
wwitzel3natefinch: LGTM, nice job17:08
mfoordso according to rsyslogd my config file is valid17:20
mfoordneed HA up and running to try it17:21
mfoordthat'll be a task for tomorrow I think17:21
mfoordtime to go jogging17:21
mgzsinzui: one thing to check on those tests if if the precise has up to date distro-info-data17:25
sinzuimgz, you mean the archives we pull from whe we do an update could be stale?17:26
sinzuimgz, distro-info-data was installed/upgraded to 0.8ubuntu0.617:28
sinzuioh, mgz, but trusty got  0.18ubuntu0.117:28
sinzuimgz, distro-info-data_0.8ubuntu0.6_all.deb on precise does know about utopic17:30
* sinzui quickly updates publishing script to use that name instead of unctuous.17:31
perrito666has anyone ever encountered a loop of "INFO juju.state open.go:133 dialled mongo successfully" when calling state.Open() ?18:09
natefinchperrito666: doesn't sound familiar.  Are you running with --debug?  Hopefully you'd get more info about what's actyually going on.  The other option is to go look at the system logs, rsyslog, etc.  Sometimes mongo's logs will output something useful.18:11
* natefinch has to go run a quick errand, back in half hour ish.18:11
=== natefinch is now known as natefinch-afk
=== natefinch-afk is now known as natefinch
natefinchdirections for restarting Ubuntu:  click power button, restart, hit the restart button in the popup window. Wait a minute, nothing happens.  Close all applications and try again.  Wait a minute, nothing happens.  Open terminal run sudo reboot, window manager closes immediately, wait 2 minutes while ubuntu .... image spins, hold power button for 5 seconds until hard power off.  Push power button again.18:54
sinzuihands up who moved loggo from the loggo organisation to the juju organisation18:57
perrito666natefinch: wow, instead, iirc: open terminal, sync, unplug power cord18:57
natefinchperrito666: heh, well, it's a laptop, so I'd have to remove the battery too, which requires unscrewing stuff.  Probably just pushing the power button for 5 seconds to start is the best bet,.18:58
perrito666natefinch: seems your machine hates the new ubuntu kernel18:59
sinzui1.18 cannot build because loggo has moved. I need to create a shim.19:00
natefinchperrito666: something.  There was a sweet spot in there somewhere where it was rebooting correctly for a month or two.  Not so much, now.  Oh well, I don't reboot often enough for it to be a big deal.  Had to today because LXC was being a bitch and screwing my juju local19:00
natefinchsinzui: does loggo not exist in the old place?19:00
sinzuiWill go/godeps allow my to symlink, or do it need to manually get it19:01
sinzuinatefinch, yes it does exist in the old place19:01
sinzuiwell regardless, of the solution I will know soon19:01
natefinchsinzui: go build only cares about paths on disk.  it looks for "launchpad.net/loggo" under $GOPATH/src/launchpad.net/loggo  .. it has no idea and doesn't care how the code got to that directory19:02
natefinchsinzui: not sure about godeps.... it expects to be able to use VCS to sync a branch to a commit number, will probably fail if it can't do that in the correct directory19:03
sinzuithank you natefinch . I will hope for a symlink, but plan to pull from the old repo19:03
sinzuihmm, but why didn't godeps complain that the lib wasn't missing. go build certainly noticed19:04
natefinchsinzui: not sure.  Not hugely familiar with the internals of godeps.  I'd assume that if that directory didn't exist, it would barf19:04
sinzuimaybe the tarball script is calling godeps too early19:05
* sinzui looks19:05
=== jam2 is now known as jam1
sinzuinatefinch, a new clue, Looks like logo has to be in the old and new location for go to build. I tested with just old and just new and go failures.19:25
natefinchsinzui: sounds like some of the code is referencing the old path and some is referencing the new path19:25
jam1natefinch: my patch was intended for lp:juju-core/1.18 though you're proposing it against trunk19:25
natefinchjam1: doh19:25
natefinchjam1: that would be why it has 1.18 in the name, too :/19:26
sinzuinatefinch, if this is the case I think I or jam will update the code to just use the old location to meet Ubuntu's criteria for micro releases19:26
natefinchsinzui: yeah, we definitely should not be using both, that could easily cause bad behavior19:26
jam1sinzui: so the awful truth is that LTS switching to trusty broke some of our tests, I believe19:27
natefinchjam1: luckily one of the tests failed ;)19:27
jam1sinzui: bug #131217619:27
_mup_Bug #1312176: test suite fails on Precise now that Trusty is released <test-failure> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1312176>19:27
natefinch jam1: it's like one of those "are you sure you want to merge this?" popups.  You have to really mean it19:27
sinzuijam1, you can feel good that trusty tests usually pass the first time. trusty is ver stable19:28
natefinchjam1: well, shit.  I guess I should cherrypick my change and move it to a new branch19:28
jam1natefinch: can you just propose it against 1.18 or did you merge trunk in the meantime?19:30
natefinchjam1: I merged trunk :/  there were conflicts (not surprising since it was for 1.18)19:30
sinzuinatefinch, jam1. 1.18 does indeed want both loggos and the juju/loggo is unpinned because the goreps don't know about it.19:31
natefinchjam1: I can just re-branch your branch and copy over the changes, they were pretty trivial19:31
natefinchsinzui: that's a pretty important bug.  Importing both could easily cause serious issues.  We need to only use one or the other.19:31
jam1sinzui: yeah, I think hazmat noted that we have a bogus import19:31
sinzuinatefinch, jam1: https://bugs.launchpad.net/juju-core/+bug/1311909 proposal for a fix sane? I can do all the packaging changes. The upgrade suggestion might to too tricky to do19:43
_mup_Bug #1311909: juju 1.18 (local provider) depends on lxc 1.0.0 but nothing forces it to install on precise <packaging> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1311909>19:43
natefinchsinzui: sounds good to me19:46
natefinchweird, lbox totally screwed up the link to the code review19:52
natefinchno.... it looks like reitveld just reused an old number including old comments, but with the correct code19:53
* natefinch doesn't know WTF is going on with reitveld19:54
jam1sinzui: if we just put lxc 1.0.0 into ppa:juju/stable would it make it work?19:58
natefinchdammit, somehow bzr or lbox completely mangled my commit20:08
* natefinch does it over again20:08
sinzuijam1, I think it might have avoided the issue where juju-local wasn't installed20:10
natefinchahh FFS20:13
natefinchjam1, wwitzel3: not sure if either of you are still here, but I had to manually propose my new branch because lbox is somehow totally borked for this branch for whatever reason20:15
natefinchjam1, wwitzel3: https://code.launchpad.net/~natefinch/juju-core/panic-parsing-jenv-1312136/+merge/21713020:16
fwereadenatefinch, that still LGTM20:18
natefinchfwereade: thanks20:18
sinzuinatefinch, wwitzel3 will either of you be landing a branch in the next 2 hours?20:28
natefinchsinzui: in theory I have one landing right now20:29
sinzuifab, I will wait for your branch instead os replaying an old revision to test utopic building20:29
natefinchfwereade: trivial code review if you have a sec: https://codereview.appspot.com/9476004320:35
fwereadenatefinch, shouldn't there be an error returned and checked there?20:36
natefinchfwereade: oops, wow, yeah.  Thanks for catching that20:37
natefinchfwereade: fixed20:40
sinzuinatefinch, lp:juju-core/1.18 r2275 just fail again.20:43
sinzuigo build -v launchpad.net/juju-core/...20:43
sinzuitmp.t3vUjGZmJ6/RELEASE/src/launchpad.net/juju-core/state/apiserver/usermanager/usermanager.go:9:2: cannot find package "github.com/loggo/loggo" in any of:20:43
sinzui/usr/lib/go/src/pkg/github.com/loggo/loggo (from $GOROOT)20:43
sinzui/mnt/jenkinshome/jobs/build-revision/workspace/tmp.t3vUjGZmJ6/RELEASE/src/github.com/loggo/loggo (from $GOPATH20:43
fwereadenatefinch, LGTM20:44
natefinchfwereade: thanks20:45
natefinchsinzui: do you need me to fix that?20:45
sinzuinatefinch, I am about to prose a fix for the one bad import20:46
natefinchsinzui: ok20:46
natefinchsinzui: that looks to be the only place it's imported in 1.18 AFAICS20:46
sinzuinatefinch, Do you have a moment to review https://codereview.appspot.com/9678004320:52
natefinchsinzui: LGTM20:53
sinzuithank you natefinch , I will offer to the gobot god20:54
natefinchsinzui: good luck :)20:54
natefinchok, EOD for me20:56
perrito666hey, is this on syslog something I should worry about? replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)21:13
fwereadeif anyone's around, I'd appreciate a review of https://codereview.appspot.com/96790043 that included checking a random sample of it against objective reality22:26
* fwereade bed22:26
=== rogpeppe2 is now known as rogpeppe

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!