19:00:28 <briancurtin> #startmeeting python-openstacksdk
19:00:30 <openstack> Meeting started Tue May 20 19:00:28 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:35 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:15 <briancurtin> If anyone's around for the sdk meeting, i threw together a small agenda, mostly just making sure to cover the outstanding reviews in teh way: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-05-20_1900_UTC
19:01:27 <briancurtin> and if you're here, roll call
19:01:30 <briancurtin> Brian Curtin, Rackspace
19:03:13 <dtroyer> antihistamine-soaked Dean Troyer, Nebula
19:05:10 <jamielennox> Jamie Lennox, Red Hat
19:05:39 <dtroyer> it's really quiet, right?  it isn't that I just can't see the text?  ok, good, I see jamie
19:05:51 <Alex_Gaynor> Alex Gaynor, Rackspace
19:06:17 <briancurtin> i'm guessing it'll be quiet as people probably catch up from last week, so maybe a quick meeting
19:06:32 <jamielennox> dtroyer: your message was the first thing i saw - i only assume we're doing the roll call from that
19:06:38 <dtroyer> yes
19:06:55 <dtroyer> I'm full of allergy drugs so a little slow today
19:07:05 <briancurtin> may as well get started
19:07:07 <Alex_Gaynor> Thanks to everyone who came out to the session at the summit; it felt super productive and nice to sync with folks in person
19:07:48 <briancurtin> not really anything to discuss on this point, but i noticed coverage is broken, and we need a yet-to-be-released pbr to get it working
19:08:00 <Alex_Gaynor> Was that always broken?
19:08:02 <briancurtin> (or you can change the name in setup.cfg to be "openstack" if you need)
19:08:14 <briancurtin> Alex_Gaynor: i'm guessing it was, i only tried to run it last week or the week before
19:08:19 <Alex_Gaynor> k
19:08:52 <briancurtin> pbr did some magic where if the name starts with python-, it strips that off and uses it, but our package is called openstack instead of openstacksdk, so it was testing nothing and collecting nothing
19:08:54 <briancurtin> anyway
19:09:26 <briancurtin> there's an open review for example code which depends on the presentation layer, but it just needs to be rebased. seems probably uncontroversial: https://review.openstack.org/#/c/91448/
19:09:41 <briancurtin> what it depends on, though, could use some love: https://review.openstack.org/#/c/90538/
19:10:52 <jamielennox> is there a decision on that either way? I don't know if we need presentation but what's the plan for right now?
19:11:04 <dtroyer> sigh…I don't care for the presentation layer, and if it would ever stop screwing around with Transport I could ignore it…
19:12:11 <jamielennox> i'd like to get passed this point - is the best way to +2 or -2 the presentation?
19:12:59 <dtroyer> I just renewed my −1, but if that still doesn't get the point across I'm willing to be forceful about it
19:13:41 <Alex_Gaynor> I have very little opinion about the presentation stuff; I'll hapilly defer to folks who feel they are blocked on it
19:14:17 <jamielennox> ok,  given that from dtroyer i'm going to ignore it for now and if it ever passes it can be hacked in
19:14:32 <Alex_Gaynor> Sounsd good :-)
19:15:08 <briancurtin> with that being said, moving onto the auth change https://review.openstack.org/#/c/91889/
19:15:21 <briancurtin> terry isn't here, but i know he had more work to do there, so i dont believe it's review ready
19:15:38 <dtroyer> that is also my understanding
19:15:38 <terrylhowe> I have another patch on that, I'm almost ready to update
19:15:41 <briancurtin> he made a pass to address some of the early concerns, but still a TODO
19:15:45 <briancurtin> oh, there he is - cool
19:15:52 <terrylhowe> sorry I'm late
19:15:57 <briancurtin> no prob
19:17:16 <briancurtin> and now that he's here, terrylhowe: not sure if you saw, but we just talked about the presentation layer change. it seems like it's probably going to sit for now
19:17:58 <terrylhowe> I'll look at the logs I guess
19:19:06 <terrylhowe> The biggest advantage of it is it cleaned up the resource class
19:19:39 <briancurtin> quick summary - dean doesn't want it to muck with Transport, jamie wants to move on +2/-2 either way, alex deferred, i'm more with alex/jamie
19:20:19 <briancurtin> (my +2 was that i'm somewhat fine with the change, strong on moving forward)
19:23:51 <briancurtin> so i guess other than that, and whenever the updated auth change comes in - anything else at the moment to discuss?
19:24:32 <terrylhowe> I'm a little confused on Dean's comment on JSON support being removed from transport since it is in there still
19:24:58 <terrylhowe> Not sure if he realized I uploaded a new patch
19:26:06 <briancurtin> dtroyer^
19:27:10 <dtroyer> moving it from Transport to PResentation now adds another requirement/dependency for Transport that I don't see any gain for.
19:27:33 <terrylhowe> How about I just put the decode code into transport as well?
19:27:43 <dtroyer> I prefer to balance the JSON encoding/decoding in Trnasport as half of it is already in Requests
19:28:45 <terrylhowe> Fine, I just don't like it split over transport and resource
19:29:13 <dtroyer> I don't see the split.  Right now Transport does both JSON encoding and decoding.
19:29:16 <dtroyer> what am I missing?
19:29:42 <terrylhowe> everything the resource class does
19:30:05 <terrylhowe> https://review.openstack.org/#/c/90538/6/openstack/resource.py
19:32:27 <dtroyer> there is certainly noting to prevent there being another encoding/decoding layer higher up in the stack…the actual duplication would be small if they both use the same lib.   But I need it for things that are not resource-based.
19:33:18 <terrylhowe> right, I moved the json encoding and decoding in transport
19:33:59 <dtroyer> how about this: don't change transport.py and I'll be able to let the rest go.
19:34:54 <dtroyer> Conceptually, something called Presentation should not be a dependency of something called Transport.  It's upside down
19:36:42 <terrylhowe> okay
19:41:14 <briancurtin> question: was looking at Resource.list and potentially making it a generator rather than list/marker (jamie's comment) - however, is there any general purpose way to do that? for example, swift's marker is a string container name, but i've seen others that are IDs
19:41:37 <briancurtin> er, limit/marker, not list/marker
19:42:45 <terrylhowe> container name is pretty much an id
19:42:59 <jamielennox> so i don't even remember what's currently in resource - if you want to switch it out then do it
19:43:12 <jamielennox> i had thought previously as to whether we could almost cache on a list call
19:43:28 <jamielennox> so return an object that was a generator that stored everything and could essentially be scrolled through
19:43:50 <briancurtin> yep, i'll look further into that (i love generators, so the comment stuck out)
19:44:14 <terrylhowe> sounds good to me
19:44:53 <briancurtin> anything else to cover with these last 15 minutes?
19:45:20 <jamielennox> there has been some discussion on the server sides about u sing next/previous in the response for how to access more data so a generator makes sense there
19:46:40 <briancurtin> jamielennox: that probably does make sense there, then i wouldn't have to worry about a marker at all, just give a limit, keep going with next, stop when there isn't one
19:50:49 <briancurtin> i take it that's probably the end. anything else in these last 10 min?
19:51:10 <terrylhowe> nope
19:52:20 <briancurtin> #endmeeting