19:00:37 <briancurtin> #startmeeting python-openstacksdk
19:00:37 <openstack> Meeting started Tue Jul 29 19:00:37 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:40 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:52 <briancurtin> https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-07-29_1900_UTC
19:01:06 <briancurtin> if you're around for the python-openstacksdk meeting, say hi
19:01:08 <briancurtin> Brian Curtin, Rackspace
19:07:04 <dtroyer> dean troyer, nebula
19:08:52 <jamielennox> Jamie Lennox, Red Hat
19:10:05 <briancurtin> was hoping terry would be around, but maybe he'll show up
19:10:43 <briancurtin> his https://review.openstack.org/#/c/104948/ just needs a comment and then it's ready to go, per last week
19:11:00 <briancurtin> #topic swift status
19:11:45 <briancurtin> I have some of that alternate approach to swift done, but getting the container into the object resource is proving to be a bit difficult this way. the old way was injecting it into the dictionary, which is bad
19:12:13 <briancurtin> it's the first resource we have that depends on additional information, not from a "/" base path
19:12:23 <briancurtin> or something that can be hardcoded, really
19:15:11 <jamielennox> briancurtin: i had a try a while ago and came across similar problems doing a user/roles relationship
19:15:51 <jamielennox> that doesn't mean i have an answer for you, i think it means we might need to revisit some of the assumptions made in the base object
19:16:12 <briancurtin> it feels like so much of resource being classmethods makes it a little harder to build on top of
19:17:04 <briancurtin> so im going to poke around a bit in teh base and see what else can be done
19:18:03 <jamielennox> briancurtin: sounds good
19:18:14 <briancurtin> #topic summit talk proposal
19:18:47 <briancurtin> Terry submitted a summit talk to introduce and show off the SDK and i'm going to co-present with him - let me know if anyone wants to see hte abstract since it's not public yet
19:19:56 <briancurtin> #topic lower level API
19:19:58 <jamielennox> briancurtin: awesome
19:20:19 <briancurtin> jamielennox: i figure as we get into it and see if it's accepted and all of that, we can all work together on it really
19:21:17 <briancurtin> dtroyer: a few weeks ago you were interested in talking about some lower level details and we haven't gotten back to that. what's up?
19:21:55 <dtroyer> at some point I realized that the resource-level stuff you guys have been working on is what you are considering to be the low-level API, not at all what I imagined
19:22:37 <dtroyer> what I had done for the onbject stuff in OSC what more like what I imagined, so I threw together https://github.com/dtroyer/python-openstacksdk/tree/low-level-api/openstack to demonstrate
19:22:54 <dtroyer> I get the feeling, though, that I'm the only one interested in doing something like that
19:23:48 <dtroyer> the intersting bits are in openstack/sdk/compute and openstack/sdk/objectstore
19:24:08 <dtroyer> the openstack/sdk is left over from an earlier POC about the namespace
19:26:45 <jamielennox> dtroyer: i think there is going to be a difference in what we make public facing to what we are doing now
19:27:09 <jamielennox> i don't think what we are doing with the explicit session handling is necessarily the best from a UX perspective
19:27:24 <jamielennox> particularly when we start trying to abstract across multiple API versions
19:28:13 <dtroyer> for most app developers, that's probably true, but there are cases where I think it should be a public supported stable API, similar to the Win32 level in windows, few use it directly but its there if you know how to drive it
19:28:51 <briancurtin> jamielennox:  yeah i dont think the end-userish, high-level, will be explicltly passing in session or calling any of those *_by_id
19:29:07 <dtroyer> because frankly, 90% of OSC doesn't need the high-level bits
19:29:50 <dtroyer> I'm including the Resource-level stuff in that FWIW
19:30:08 <jamielennox> dtroyer: yes the Resource stuff will still be considered a public api
19:30:29 <dtroyer> my point is that its too high-level
19:30:33 <briancurtin> dtroyer: so im guessing your end goal is to have this level be all json?
19:30:39 <briancurtin> *this low level
19:31:25 <dtroyer> no, the JSON is in the session/transoirt stuff.  I really want a pythonic REST API.  this is just below where you take the dict from session and make a resource
19:31:39 <jamielennox> that might be a solution to the *_by_id stuff being all class methods
19:31:48 <jamielennox> put the JSON based calls somewhere in there own file
19:31:55 <jamielennox> have the resource use that
19:31:58 <briancurtin> ah
19:32:37 <jamielennox> which is nice actually because i'm not a fan that the _by_id returns a dict and not the Resource object
19:32:49 <briancurtin> yeah that has made me think a couple of times
19:36:02 <dtroyer> so anyway, that's what I was talking about.  I'm planning to keep going in that direction for the objectstore bits in OSC, and maybe some of the others where they are stupidly broken
19:36:56 <briancurtin> i like jamielennox's idea of separating out those *by_id - dtroyer would that be helpful?
19:38:21 <dtroyer> without knowing it to too well, I think that is a start
19:40:39 <dtroyer> in general, I think having an object know too much about its surroundings is a mistake, it limits how it can be used.  but that's old-school object pascal-stle thinking
19:40:44 <jamielennox> i think it'd be pretty much what you are wanting, just a function call, takes a session and some info and returns the raw json
19:41:16 <jamielennox> dtroyer: no that makes sense, it's the same problem with the user/roles or object/container relationships
19:41:20 <dtroyer> jamielennox: basically, yes.  but for the entire REST API.  it doesn't have to necessarily be a 1:1 mapping, but close
19:41:50 <jamielennox> they should know there own information but not where they came from or who they are related to
19:41:59 <dtroyer> exactly
19:44:55 <briancurtin> i think what i might do is checkin this swift container part since it works now, then dig into some of this resource splitting to maybe make the object part easier (or even possible)
19:47:03 <jamielennox> briancurtin: sure, we're not worried about compatability yet
19:47:50 <dtroyer> jamielennox: what is the "comp-a-table-ity" of which you speak?
19:49:02 <jamielennox> dtroyer: it's the reason people hate writing/maintaining libraries in python
19:49:30 <dtroyer> s/in python/that are public/  ;)
19:53:03 <briancurtin> anything else to cover while we're here?
19:53:35 <jamielennox> i'm good
19:54:24 <dtroyer> nothing sdk on my mind…jamielennox I didn't get to the ksc.session patch for OSC over the weekend, but when I do I many need some clarification, I don't think I fully grok the right (non-deprecated) way to set it up for a sinle session for everything
19:54:49 <briancurtin> cool. i'll bring the tests over and push the non-object bits of swift up and then move on to resource
19:54:57 <jamielennox> dtroyer: sure we can discuss that over in -sdk
19:57:37 <briancurtin> thanks guys
19:57:39 <briancurtin> #endmeeting