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