[12:23]  * bac has new super-secure pypi password
[12:44]  * frankban remembers to change his pypi password, thanks to bac
[13:09]  * gary_poster too
[14:17] <bac> Makyo: 2nd review done
[14:57] <benji> gary_poster: is the API sketch in http://paste.ubuntu.com/1628460/ still applicable?
[14:58] <gary_poster> benji, yes, though I've given better links lately. Getting...
[14:58] <benji> I ask because it does not take a command-centric approach, but invents an entirely new vocabulary.
[14:59] <gary_poster> benji  http://bazaar.launchpad.net/~rogpeppe/juju-core/212-api-doc/view/head:/doc/draft/api.txt (comments or concerns about the doc can go here, btw: https://codereview.appspot.com/7314085/diff/1/doc/draft/api.txt)
[14:59] <gary_poster> benji, the Client object is for commands
[15:00] <gary_poster> benji, the new vocabulary is for Roger's other responsibility: letting Juju components talk/listen among themselves
[15:00] <benji> ah, ok
[15:01] <benji> gary_poster: nope, no ok (i.e., I do not understand): is https://codereview.appspot.com/7314085/diff/1/doc/draft/api.txt about "commands" or this internal juju-juju communication?
[15:01] <gary_poster> over the same socket, but on the different objects benji.  As described now, we will never talk to anything other than the Admin object (only to log in) and the Client object.  I've proposed subdividing the Client object into read-only and mutation but that might be for later
[15:01] <gary_poster> benji, call on juju gui
[15:02] <benji> k
[15:03] <bac> gary_poster: may i join?
[15:03] <gary_poster> of course bac
[15:03]  * bac getting headset
[15:04] <hazmat> i swear every day this week i get some internal interupt juju support request
[15:04] <hazmat> today its gui with local provider
[15:05] <hazmat> therve, when you said you had gui working with local provider was that including being able to deploy services with the gui?
[15:09] <hazmat> so the issue is that the local provider storage is read only, which prevents deploys in the gui
[15:13] <therve> hazmat, I didn't try that
[15:28] <gary_poster> jujugui call in 2
[15:30] <gary_poster> goodspud call
[15:33] <Makyo> lp:~makyo/juju-gui/ghost-minors-1125506-1124414 
[15:33] <Makyo> https://codereview.appspot.com/7317046/
[16:02] <bac> benji, gary_poster: when were we going to talk?
[16:02] <gary_poster> bac soon will ping
[16:02] <bac> gary_poster: ok, if not let me know so i can grab lunch
[16:03] <gary_poster> ack bac
[16:03]  * bac grabs a healthy snack
[16:04] <gary_poster> bac go get lunch.  we'll talk in 56 minutes bac & benji?
[16:14] <bac> gary_poster: ok
[17:23] <hazmat> jujugui  .. sprint confirmed, ticket booking begins, email to follow
[17:23] <gary_poster> awesome
[17:23] <bac> hazmat: to ATL
[17:31] <hazmat> bac, yes
[17:31] <hazmat> as soon as the call is done i'll fire off some emails
[18:20] <gary_poster> bcsaller, finally finished my first review.  I have so many questions that I'd like to maybe talk about it, and I'd like to see the changes you make before landing, but I don't think it will be a big deal
[18:28] <bcsaller> gary_poster: let me read over what you wrote and then we can do a call when you have time
[18:28] <gary_poster> cool thanks bcsaller 
[19:07] <gary_poster> bcsaller can talk whenever you are avail.  no rush
[19:18] <bcsaller> gary_poster: I'm attempting to resolve a few minors that came from looking at your review, maybe we can wait till our scheduled call in 40 minutes?
[19:18] <gary_poster> bcsaller, sounds good, talk to you then
[19:27] <benji> bac: so, how are we going to get a foothold on this project?
[19:28] <bac> benji: pick a cmd and forge on, learn from mistakes, repeat smarterly
[19:28] <benji> bac: sounds good; pairing?
[19:29] <bac> benji: sure.  we can get the ball rolling today and then i'll run with it monday
[19:29] <bac> benji: g+?
[19:29] <benji> sure
[20:48] <gary_poster> hazmat do you know offhand if we can stuff annotations in the .json files for improv?
[20:49] <hazmat> gary_poster, we can of course, drop me a sample.json via email and i'll take care of it
[20:49] <hazmat> gary_poster, at the moment its not done, but its trivial to do so
[20:50] <gary_poster> awesome thanks hazmat.
[20:50] <Makyo> hazmat, gary_poster, this is re: testing landscape annotations.
[21:05] <hazmat> ack
[21:06] <hazmat> gary_poster, Makyo do we have such a sample?
[21:06] <gary_poster> hazmat, no, we would throw one together by tacking an "annotations" key in to the objects
[21:07] <hazmat> gary_poster, sure but we know all the keys from therve's email on the subject?
[21:07] <hazmat> ie. they haven't changed form/value?
[21:07] <gary_poster> yes hazmat
[21:07] <gary_poster> no hazmat
[21:07] <hazmat> okay.. i'll add it in.. no need for the sample
[21:08] <gary_poster> thank you
[21:17] <hazmat> therve, not sure if this is up to date, (looking at thread from ls annotations january) i don't think we need to be passing the env around in annotations, it would be the env uuid, and we'd be attaching that as param to all links i think
[21:19]  * gary_poster hopes he isn't part of allowing handoff hell yet again :-)
[21:20] <gary_poster> that's what we're working with on the gui side hazmat, fwiw.  progress already made.  hope it doesn't change too much.
[21:20] <gary_poster> probably small waste, but don't like egregious waste
[21:20] <hazmat> gary_poster, its a simple url change, not a big deal
[21:20] <gary_poster> cool
[21:21] <hazmat> effectively i'm thinking we attach env=$env_uuid to all links outbound from the gui
[21:22] <hazmat> the sample has that environment=env0 in the annotation.. but that seems a bit silly, unless landscape wants to ref a different id for the env
[21:23] <gary_poster> hazmat, ah I see.  ok, simple, yeah.  let us know how it works out. :-)
[21:23] <gary_poster> thanks again
[21:23] <hazmat> np
[21:28]  * hazmat pauses to book flights
[21:32] <Makyo> Oh yeah, got those all booked.  Do we have a page to drop that info/with hotel info/etc?
[21:35] <therve> hazmat, sorry I don't get everything
[21:36] <therve> hazmat, by env you mean the Landscape env name?
[21:40] <hazmat> therve, yes the ones in the annotation urls
[21:41] <hazmat> therve, was wondering if the gui could just add the env uuid there or if its a value that landscape is generating
[21:41] <therve> hazmat, afaiu if it should be opaque to the gui
[21:41] <therve> I don't really see the point of it manipulating the value
[21:41] <therve> although using the uuid could be a good idea, we would do in on the landscape side
[21:51] <hazmat> gary_poster, are there any US folks around on monday?
[21:54] <benji> hazmat: I believe Gary and Brad will be.
[21:54] <hazmat> benji, thanks
[21:55] <hazmat> therve, yeah.. that would save repeating that value quite alot in the annotations
[21:55] <therve> hazmat, you mean, if landscape doesn't put it by default?
[21:56] <hazmat> therve, right.. the gui can just append env=$uuid to query string urls
[21:56] <therve> hum...
[21:57] <therve> hazmat, yeah I don't want to put too much logic on the gui side though
[21:57] <therve> but I guess we could do something like the alert url, where you can concat stuff to build the final URL
[21:57] <hazmat> therve, the gui is already complex, this is simple ;-)
[21:58] <hazmat> therve, sure if you want to keep a landscape specific value for the env instead of the uuid that would also work
[21:58] <therve> hazmat, it's not so much about complexity rather than control
[21:59] <therve> to not have to change things in 2 places if landscape needs a change
[21:59] <hazmat> therve, thats the nature of integration and apis..
[22:00] <hazmat> we're already constructing the url in other places as you noted
[22:00]  * Makyo dogwalkinates
[22:01] <hazmat> therve, i'm happy to deferring to whatever you'd prefer
[22:02] <hazmat> lost network connectivy, just wanted to make a suggestion that would keep things short
[22:02] <hazmat> and remove redundancy from the annotations
[22:02] <therve> hazmat, let me think about it, I'll send an email
[22:03] <hazmat> ack
[22:06] <gary_poster> hazmat, benji, not I
[22:06] <gary_poster> bac will be