[01:45] axw: wallyworld_: plz don't review yet :D m resolving merge conflicts [01:45] ok [01:45] k [01:45] wallyworld_: someone has been very busy in the area [01:45] * anastasiamac_ rolls eyes :D [02:08] axw: wallyworld_: and resolved... PTAL http://reviews.vapour.ws/r/941/ [02:08] looking [02:09] axw: tyvm :D [04:45] phew [04:45] doc finished (for now) [04:45] email sent [04:45] I'm done [04:45] * thumper looks for the wine [08:49] morning [08:52] TheMue: morning [08:52] anastasiamac_: heya o/ [08:52] anastasiamac_: still awake? [08:53] * TheMue has to look at the time zones [08:53] TheMue: it's 7pm, m about to take my son to soccer [08:53] TheMue: but will be back again soon :D [08:53] anastasiamac_: ah, ok, not so late, but a good time to care for the son [08:53] TheMue: u r not travelling very far in April ;( [08:54] anastasiamac_: absolutily not, and the city is IMHO quite boring (have been there twice) [08:54] TheMue: yes, it's good time to care for one... unfortunately, i have 3 :( [08:54] anastasiamac_: there are others more interesting, like Hamburg or Berlin [08:54] TheMue: but with us, it will feel like new :D [08:54] anastasiamac_: hehe, I've got 2, but the are now almost 19 and 21. [08:55] TheMue: oh - so u know my dilemma [08:55] anastasiamac_: yep *lol* [08:55] TheMue: ttyl [08:55] anastasiamac_: cu [09:02] fwereade: how's it going? [09:23] jam, heyhey [09:23] jam, actually decent again, how about you? [09:25] axw, thanks for moving those relation.Hook* things [09:25] axw, I was worried there'd be import hassle [09:25] fwereade: nps, I hope it looks okay? [09:26] axw, I haven't looked at the change, just the log,but it sounds absolutely sane [09:26] ok :) [09:26] fwereade: I'll have some more changes soon, but that'll all be about storage. probably will have to pick your brain again soon [09:27] fwereade: did you have a good weekend? Things are going ok here, though we should get back on Leader Election stuff [09:27] I did manage to land a couple patches there [09:27] jam, yeah, I saw, and I have one here with just a few review fixes to apply I think [09:28] jam, so we're getting perilously close to the actually-call-the-apis point [09:28] fwereade: I was thinking to go make some coffee and then jump on a hangout, does that sound decent to you? [09:28] jam, perfect, will do likewise [10:04] dooferlad: dimitern: TheMue: got kicked out! Need to reauthenticate, sorry [11:17] dimitern, TheMue, voidspace: https://github.com/dooferlad/next_up [11:18] *click* [11:19] TheMue: Would happily move the remaining Python stuff into Go, but can't justify the time spent at the moment. Suggestions welcome :-) [11:19] dooferlad, nice! :) [11:19] dooferlad: cool [11:19] dooferlad: will come automatically over the time [11:21] dooferlad: together with more commenting *scnr* [11:21] TheMue: It has... evolved quickly. [11:21] * fwereade lunch [11:22] TheMue: I would classify it as "I don't like it, but it works" [11:23] dooferlad: for the JSON documents in Go you could use a generic (bad choice of word) JSONObject [11:23] dooferlad: with methods to fetch a map, an array or a string [11:23] dooferlad: and then just traverse the known structure [11:23] dooferlad: this is what we do for MaaS - you could nick the code from that [11:24] it's still a bit more tedious than Python, but you don't have to define a type for each document [11:25] voidspace: cool! [11:25] so GetArray returns a JSONObject representing the array, or an error if the underlying JSON you've asked for isn't an array [11:25] so more than half your code is still error handling :-) [11:26] provider/maas/environ.go is a good place to look for examples [11:26] and by coincidence the place you'll need to be looking for the networking stuff [11:27] dooferlad: did you say you had a pact referral code? [11:28] dooferlad: I'm thinking of giving them a try [11:28] dooferlad: gomaasapi.JSONObject [11:29] which should probably be broken out into it's own little library [11:36] voidspace: https://www.pactcoffee.com/spread/james-cmocka [11:36] dooferlad: thanks [11:37] voidspace: that gomaasapi.JSONObject looks spot on! [11:51] dooferlad: coffee ordered :-) [11:51] voidspace: hope you enjoy it :-) [11:59] aaaah, found it, go test dislikes the combination of -check.v or -gocheck.v with ./... [12:19] TheMue, yeah, it's either go test -v ./... or go test -check.v (in current dir) [12:30] dimitern: dooferlad: https://www.dropbox.com/s/ovdml6fs4u3n1wv/maas.txt?dl=0 [12:31] dimitern: dooferlad: that's the document on the container addressability information for MaaS [12:31] voidspace, thanks, looking [12:31] it's just an overview, but hopefully detailed enough to be useful [12:32] feel free to point out errors, missing information or suggest clarification [12:32] it doesn't detail all the specific API calls as they should be clear from the code [12:32] it's meant as a guide to the code [13:04] fwereade: are you around to chat a bit about the Dying() stuff? [13:09] * jam goes to walk the dog === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [13:41] hey guys, fwereade just texted me he's having issues with the internet connection [13:41] tasdomas, ^^ [13:54] plantuml state diagram of uniter modes : http://reviews.vapour.ws/r/944/ [13:54] still really basic; lots of room for improvement [13:55] katco: fyi, you were interested in this ^^ === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1416928 [14:51] gsamfira aznashwan o/ [14:53] marcoceppi hey there :D [14:57] jw4: thanks, i'll have a look :) [14:58] * katco is OCR today; covering for perrito666 who is on holiday today. Please send review requests my way! [15:01] katco: don't cry so loud, I'm currently finishing a larger one [15:01] katco: :D [15:02] TheMue: haha === kadams54 is now known as kadams54-away [15:14] wwitzel3, You can merge your fix for bug 1417875 and since your work is required for 1.21 and 1.22, you were permitted to to use the __JFDI__ to make it merge [15:14] Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority Progress by wwitzel3> [15:16] sinzui: thank you [15:17] dimitern, how goes your fix for bug 1416928 [15:17] Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents [15:17] sinzui, mostly done, testing various scenarios live now [15:18] rock, thank you dimitern and wwitzel3 [15:23] where can I find a picture of what's going on with Windows support? We're looking to add an "action kill" worker behavior which we were planning to implement using syscall; do we need to implement windows support as well (I know we offer a few Windows charms?) [15:31] (the current plan is to implement it in a system agnostic way and add OS specific support, fwiw.) [15:36] katco: tx [15:36] jw4: ty :) === kadams54-away is now known as kadams54 [15:38] mgz, ping [15:38] dimitern: hey [15:38] mgz, hey, any update on goose? :) [15:39] I have script for managing the pull/test, plan today is fork the existing gating job and add as experimental without the github actual landing part [15:40] mgz, sweet! please keep me updated [15:50] dimitern: would goose need a new branch for adding cinder support? technically it's not a breaking change [15:51] katco, it depends on the PR I guess [15:51] dimitern: picture a new package [15:52] katco, if you're only adding things, cindertest double subpackage included, then I guess it's backwards compatible [15:52] katco: it shouldn't, but I think we never did the "cloud doesn't support this extention/module" code, so you may have compat issues [15:53] mgz: you mean instances of openstack that don't support cinder? [15:54] or only expose it via the nova interfacs [15:56] mgz: i'm not touching the nova package, i think it's expected that users utilize the cinder API [15:56] mgz: but i might be missing the just of what you're saying [15:56] right, which may not work on any given cloud [15:56] because the older api was through nova [15:57] mgz: so wouldn't they then be able to fall back to the nova implementation? or is that not in goose? [15:57] katco, not the storage apis of nova [15:58] dimitern: mgz: ah i see [15:58] katco, but I'd vote to deal with this if we need to [15:59] cinder api is the way forward, if we need to also support nova legacy storage apis, we'll do it [15:59] basically, I think we just want to make sure the code does something sensible if keystone doesn't give you a cinder endpoint [16:00] because that's what would break existing uses [16:00] mgz: good point. i think that's more on the juju side though [16:00] dimitern: agreed. now that i can auto-generate api client's it can be trivial [16:00] we only look at endpoints if you import and try to construct a cinder object? [16:01] mgz: it would fail upon making a cinder call most likely [16:01] okay, that's late enough I guess [16:01] mgz: i haven't actually wrapped goose around the auto-generated client yet [16:02] katco, i'd like to have a look at your proposal when you're ready btw [16:02] dimitern: sure thing. that's what i'm working on today [16:03] dimitern: (i'll be getting back to amz after this, but i want to unblock my team) [16:03] katco, sgtm [16:03] dimitern: here's the autogenerated code: http://paste.ubuntu.com/10212665/ [16:05] katco, cool, can I suggest to tweak the generation to follow Go style guide? e.g. no "_" in field names mostly and stripping from doc comments will be nicer [16:06] dimitern: yeah it needs a bit more cleanup. i'm not sure i'll be able to easily get rid of the "_", but will endeavor to [16:06] dimitern: within a reasonable amount of time [16:06] katco, cheers [16:07] katco, also, are these client-facing exports? [16:07] dimitern: the idea is that goose wraps this [16:07] katco, i.e. do I have to call DeleteSnapshot(request MakeRequestFn, args DeleteSnapshotParams) directly? [16:07] katco, ah, that's better [16:07] dimitern: so probably not; we'll see how the api evolves [16:08] dimitern: mostly i just didn't want to sit there and write a billion http requests :) [16:08] katco, do you even need them all? [16:09] dimitern: what do you mean? [16:09] katco, remember that everything we use in juju needs a corresponding support in its corresponding test double (e.g. testservices/novatestservice) [16:10] katco, so that live tests can be written against these and run (quickly) against them the same way as they would against live OS servers [16:11] dimitern: apologies; i'm not drawing the connection [16:12] katco, the test servers implement the same API as the real openstack servers (well, only a subset needed by juju) [16:13] dimitern: do http requests somehow preclude us from testing that manner? [16:13] katco, so that you can then write "local live" tests running against the test doubles or real openstack servers [16:14] katco, no, but if you implement the full cinder api just to save time writing each method individually, this won't help with the implementation of the test double [16:15] dimitern: i.e. the tests should be able to use this code to hit the test double [16:15] dimitern: ping [16:16] katco, juju (and its live tests) will use the generated code to talk to real OS API or the test double [16:16] dimitern: i might be missing something, but i still don't see an issue [16:17] dimitern: just pass in a MakeRequestFn that does what you want with the *http.Request [16:19] katco, it's not just about tweaking a request or response, it's about faking a sequence of calls, e.g. start a node, allocate an ip to it, list node's ips, set node state, etc. [16:21] dimitern: i'll have a look at nova and see if i can understand better what you're describing [16:22] katco, yeah, have a look at juju livetests as well and you the open stack test services are used in goose and in juju [16:23] dimitern: ok will do. thanks! [16:25] katco, np! after going through the code you'll probably understand better what I'm trying (and obviously failing :)) to explain [16:25] dimitern: no worries; i'm sure you're right :) [16:43] hey, just another quick centos-userdata question for you guys: considering that cloudinit only has very marginal support for [serious] yum-related work, would anyone consider it bad to run all other the packaging-related operations as {boot,run}cmds? [17:16] I'd appreciate a review on http://reviews.vapour.ws/r/946/ which fixes the critical 1.21 release blocker bug 1416928 [17:16] Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents [17:16] gnah, my local git repo dislikes me. thankfully e'thing is pushed [17:16] dimitern: *click* [17:17] TheMue, ta! [17:30] if proxies are defined within juju are they exported to the charm's environment as well? [17:30] for things like wget to utilize [17:37] dimitern: you've got a review [17:41] TheMue, thanks! [17:41] stokachu, yes they are [17:41] dimitern: yw [17:42] dimitern: I'll push mine when I fixed my git troubles :D [17:43] TheMue, ok [18:05] sinzui: what's the bug situation? Anything blocking us that I should be looking into? [18:06] natefinch, I think dimitern and wwitzel3 are finishing up. [18:06] natefinch, there is this issue been in 1.22 that needs someone to investigate and maybe fix bug 1420049 [18:06] Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") [18:07] natefinch, my fix has a review and I'll be setting it to land before I go today [18:08] dimitern: cool === tvansteenburgh is now known as tvan-lunch === kadams54 is now known as kadams54-away [18:49] dimitern: i think i see what you're saying? auto-generating the client doesn't save any time because i have to write all the mock endpoints anyway? [18:49] right EOD [18:49] tc voidspace [18:50] dimitern: I'll post my self evaluation later (nearly done) - and email you about my branch [18:50] dimitern: what's still to be done (not much - just one bit of code to be moved and maybe another test I think) [18:50] but later [18:50] gotta go now [18:50] katco: bye o/ [18:50] voidspace: ciao [18:51] katco, yep [18:51] :) [18:53] dimitern: i might have to auto-generate those too :) [18:56] katco, now that will be awesome! :) === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === _thumper_ is now known as thumper === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === menn0_ is now known as menn0 [21:52] thumper: ping [21:53] pong [21:53] thumper: quick hangout [21:53] sure [21:54] thumper: https://plus.google.com/hangouts/_/canonical.com/moonstone?v=1423613698&clid=BF4AF0604617145E&authuser=0 === kadams54 is now known as kadams54-away === thumper is now known as thumper-dogwalk [22:47] wallyworld, xwwt good news of sorts. the job failed without lxc. Looks like an apt issue [22:48] oh, interesting [22:48] sinzui, so this might not be the br0 error? [22:48] xwwt, yep [22:48] wallyworld, What is this [22:48] 2015-02-17 22:45:18 ERROR juju.cmd supercommand.go:323 failed to stop mongo: exec ["stop" "--system" "juju-db"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist) [22:49] I think the dbus package got removed when I removed the lxc? [22:49] yep it was missing [22:49] retesting now [22:49] fingers crossed [23:11] wallyworld, xwwt The bug is fixed, we are unblocked. The false failure was cause by a mongod being left behind by the broken juju. I had to clean the machine to let the test run cleanly. [23:11] sinzui: awesome [23:11] wallyworld, we have two passes in a row, so I an sure working juju cleans up [23:21] wallyworld, CI has blessed the 1.21 rev. I will send packages of to the builds now [23:21] whiihii [23:21] whoohoo [23:40] wallyworld, do you have a moment to review this formality http://reviews.vapour.ws/r/948/ [23:40] sure [23:41] sinzui: i love your optimism :-) === thumper-dogwalk is now known as thumper === kadams54-away is now known as kadams54