19:00:21 <briancurtin> #startmeeting python-openstacksdk
19:00:22 <openstack> Meeting started Tue May  6 19:00:21 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:26 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:48 <briancurtin> I setup an agenda at https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-05-06_1900_UTC
19:01:33 <briancurtin> starts by just going through reviews, least contentions to most, so we can get a few small things out of the way and off the plate
19:01:47 <briancurtin> anyway, can anyone here for python-openstacksdk meeting state their name and affiliation?
19:02:16 <briancurtin> Brian Curtin, Rackspace
19:02:35 <dtroyer> Dean Troyer, Nebula
19:03:34 <jamielennox> Jamie Lennox, Red Hat
19:04:34 <briancurtin> potentially light meeting i guess, but may as well get started
19:04:53 <briancurtin> #topic https://review.openstack.org/#/c/90301/ - Resource properties (Jamie)
19:05:32 <briancurtin> jamielennox: this had two +1s and just that AttributeError question - i looked around and it seems like AttributeError is the way to go. the descriptor tutorial also does it
19:06:11 <jamielennox> ok, i guess that makes as much sense as anything
19:06:41 <jamielennox> i had missed that comment
19:06:55 <edleafe-> Ed Leafe, Rackspace
19:07:45 <briancurtin> #topic https://review.openstack.org/#/c/91448/ - Example code for presentation (Terry)
19:08:27 <dtroyer> I'm still trying to get caught up but this looks fine to me so far.  Terry's comment thought brings up something that I don't know if we have talked about in general.
19:08:49 <dtroyer> That being if attribute names must match the names used in the REST API
19:08:53 <briancurtin> this change depends on a later one that doesn't work, but it's an easy fix for that - so this and its dependency are close
19:09:12 <dtroyer> I'll answer no in the hopes that we can set come consistency here, ie, all resources have a 'name'
19:09:40 <jamielennox> dtroyer: related to which patch?
19:10:10 <dtroyer> The resource properties.  Terry has a coment in resource.py that made me think of this.
19:10:34 <dtroyer> We don't need to answer it now but I'd like to eventually come to a consensus
19:11:48 <briancurtin> setting consistency here seems like a good goal to me
19:11:50 <dtroyer> My canonical example of this is using 'project' vs 'tenant', which is what I did in OSC
19:12:16 <edleafe-> All resources should have a name and id attribute. When the service doesn't supply one or the other, make them properties.
19:12:52 <jamielennox> dtroyer: right, so the way descriptors work in general it's easier to specify a name in the constructor
19:12:56 <jamielennox> so name = prop('name')
19:13:04 <jamielennox> but it has the side effect that you could easily do:
19:13:12 <jamielennox> project = prop('project')
19:13:17 <jamielennox> tenant = prop('tenant')
19:13:20 <jamielennox> bah
19:13:25 <jamielennox> tenant = prop('project')
19:13:39 <jamielennox> and have them set the same value in the underlying message
19:14:00 <terrylhowe> or in cinder name = prop('display_name')
19:14:13 <dtroyer> I was thinking at a layer or two up, as in what names we choose for properties/attributes to document and expose to SDK users
19:14:40 <dtroyer> I like this way of handling it
19:14:44 <briancurtin> since we have a few reviews to cover, is the usage of prop important to figure out now, or is the code in that review fine to go in?
19:14:50 <wchrisj_> jamielennox: dtroyer: won't that sort of thing be handled properly once we version services on the SDK side, or not?
19:15:20 <dtroyer> we don't need to answer this now…  let's get back to reviews
19:15:33 <dtroyer> can talk in #-sdks later
19:16:06 <briancurtin> now that terrylhowe is here, https://review.openstack.org/#/c/91448/ - Example code for presentation
19:16:18 <jamielennox> wchrisj_: propably - either way
19:16:19 <briancurtin> pending the dep change working, seems fine to me
19:16:31 <briancurtin> (and the dep has a comment on how to fix)
19:17:48 <terrylhowe> excellent, thanks briancurtin I was having py33 on my dev box and couldn't recreate
19:18:37 <briancurtin> i dont think there's much there to discuss, and it's pretty quiet, so moving on to the two bigger reviews
19:18:45 <briancurtin> #topic https://review.openstack.org/#/c/90538/ - Add presentation layer
19:19:03 <dtroyer> I would like to not remove lower-level examples… if they need to be moved, fine.  I like the idea of building in a series of scripts, not  a single massive sample
19:19:28 <dtroyer> again, I may just be behind here
19:20:17 <jamielennox> dtroyer: right, i like keeping the lower levels accessible
19:21:30 <terrylhowe> dtroyer, I did have this kind of CLI command like thing going, but I removed it to simplify
19:21:39 <terrylhowe> I could bring it back into the example
19:22:39 <dtroyer> I was thinking about the make_transport() being removed from common.py.  I may have not added the bits that use it yet, so I can then if necessary,
19:23:14 <jamielennox> uploaded https://review.openstack.org/#/c/90301 with AttributeError fixes
19:23:36 <terrylhowe> make_transport got moved into the connection class dtroyer
19:24:29 <dtroyer> I'll dig into it more, but IIRC that breaks the lower-layer stuff I had going…again, I may not have included it all yet
19:25:14 <terrylhowe> the connection class could maybe be changed to just create a transport for some commands
19:25:45 <dtroyer> maybe, but then to do a transport/session example we need the next layer up?
19:26:18 <terrylhowe> yeh
19:26:34 <jamielennox> i have a general question about how we represent nested resources when we get a chance, i have User and Roles as top level, but with a Resource class how do we specify a User's Roles, eg /user/xxx/roles
19:27:02 <dtroyer> jamielennox: according to the reviews in OSC right now, Assignments!
19:27:22 <dtroyer> that's too general for my tastes, but I don't have a better suggestion yet
19:27:33 <jamielennox> dtroyer: i haven't seen that yet
19:27:45 <dtroyer> https://review.openstack.org/91634
19:27:59 <jamielennox> i spent a while on it directly after the last meeting and otherwise haven't looked at sdk much since
19:29:30 <jamielennox> dtroyer: i can't even tell what that's trying to do
19:29:59 <dtroyer> apparently it's for a new v3 API to get the mapping info between users/groups/domains/project/roles
19:30:06 <dtroyer> it's all new to me too
19:30:29 <dtroyer> looks like a special case of 'role list' to me
19:30:38 <dtroyer> but that's off-topic here
19:31:00 <terrylhowe> Where are we on the presentation https://review.openstack.org/#/c/90538 ?
19:31:05 <jamielennox> dtroyer: oh yea, i didn't realize we were exposing that
19:31:22 <jamielennox> terrylhowe: sorry, we should finish talking about that first
19:32:18 <dtroyer> terrylhowe: how is the Json class different from the JSON encoding/decoding already in Transport?
19:32:46 <terrylhowe> Well, it pulls all that out of the transport class so the one class controls encode/decode
19:32:52 <terrylhowe> OSI model style
19:33:03 <dtroyer> I'm −2 on that
19:33:24 <terrylhowe> why the hate :)
19:33:49 <dtroyer> Realistically, what other encoding is going to be usable here?  Maybe XML.
19:34:02 <terrylhowe> xml and maybe plain text
19:34:04 <dtroyer> That forces me up another layer or two to do things like API discovery
19:34:55 <terrylhowe> api discovery is a bit different kind of like authentication because you don't have a session
19:35:08 <dtroyer> exactly, I dont' always want a session
19:35:47 <terrylhowe> well, you have have a presentation, session and you still could use the transport
19:36:50 <jamielennox> the only problem i have with presentation is the assumption that you can always change between them
19:37:06 <dtroyer> but I lose JSON, or I have to do another subclass to put it back?
19:37:19 <jamielennox> it works if JSON or XML or plain text is available and interchangable for every interface on every services
19:37:45 <jamielennox> but if i pass the JSON presentation to the whichever cinder API that makes plain text requests what does it do?
19:38:52 <terrylhowe> failure
19:39:38 <terrylhowe> we could also create some sort of no authenticate session if we wanted presentation with no session
19:40:28 <dtroyer> why is having this layer be distinct important?
19:41:03 <terrylhowe> only for xml support
19:41:25 <jamielennox> terrylhowe: in which case then the user of the resource/operation needs to know which presentation layer to pass?
19:41:27 <dtroyer> where do we see needing XML support?
19:41:57 <terrylhowe> I'm not a big xml fan, but if developers want to test that API it would be handy
19:42:37 <dtroyer> IIRc only Nova really has usable (?) XML API, does novalicent have it today?  (I should know that but I don't...)
19:42:55 <terrylhowe> neutron has xml
19:43:05 <terrylhowe> I think nova has gaps in xml support
19:43:09 <dtroyer> and it's tested on par with JSON?
19:43:49 <edleafe-> Am I the only one who gets the feeling that we are making things overly complex? All the services speak JSON, and we are taking that and creating Python objects, no?
19:44:38 <dtroyer> edhall: no you are not...
19:44:52 <terrylhowe> could be, it also may be that neutron, nova, etc devs might lend more support if they could use the sdk for testing
19:45:39 <dtroyer> So to get a bit more pragmatic, what about Presentation is there that couldn't be retro-fitted into Session later if necessary?
19:46:27 <dtroyer> class XML_Session(Session):
19:47:26 <jamielennox> dtroyer: the reason i made original session take a json= parameter rather than a body= parameter is to distinguish them
19:47:37 <jamielennox> you can add an xml= if you wanted
19:48:06 <dtroyer> jamielennox: right, and that's why I'm trying to understand why another wrapper above Session is necessary to do this.
19:48:11 <terrylhowe> my first patch on the presentation, the session just had one
19:48:35 <terrylhowe> https://review.openstack.org/#/c/90538/1/openstack/session.py
19:49:50 <terrylhowe> it is kind of less pure, but maybe less complicated at the same time
19:50:30 <jamielennox> i'm not opposed to the layer, just the assumption that it should be passed
19:51:00 <jamielennox> if the Resource creates the wrapper then that makes sense because the resource knows what it needs to talk
19:51:07 <dtroyer> I'm not convinced we need the layer…not necessarily opposed to it (I'll linkely never use it), but want to understand what it's value-add is
19:51:56 <edleafe-> I would prefer keeping things simple at first, and adding complexity only where it turns out we really need it.
19:52:20 <dtroyer> IOW, right now I can't defend it to someone outside this room…
19:55:11 <jamielennox> terrylhowe: having the prenstation embeded in there doesn't solve the issue because you still can't differentiate for when a resource needs to use a different format
19:56:07 <terrylhowe> If presentation was an argument to _request, they could specify a one off presentation
19:57:49 <briancurtin> (couple minutes left, then probably continue in -sdks)
19:59:04 <terrylhowe> authentication is still out there
19:59:36 <terrylhowe> there are a lot of comments there I need to address
19:59:40 <briancurtin> terrylhowe: yeah, with that one, i think it's generally fine given some cleanup to not bring in a lot of that deprecated stuff
19:59:44 <dtroyer> re: auth, I'd like to see the backeard-compat stuff gone before we commit it
19:59:57 <terrylhowe> cool
20:00:24 <briancurtin> and i believe jamie got most of them, i think i caught one or two possible areas. other than that, seemed cool
20:00:40 <jamielennox> terrylhowe: yea, for my comments anything not marked as deprecated is fine to bring in
20:00:55 <briancurtin> time to head back to -sdks
20:00:56 <briancurtin> #endmeeting