19:00:36 <briancurtin> #startmeeting python-openstacksdk
19:00:37 <openstack> Meeting started Tue Sep 16 19:00:36 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:01:00 <dhellmann> o/
19:01:11 <briancurtin> Brian Curtin, Rackspace
19:01:32 <stevelle> Steve Lewis, Rackspace
19:01:36 <dtroyer> Dean Troyer, Nebula
19:01:41 <dhellmann> Doug Hellmann, HP
19:02:19 <terrylhowe> Terry Howe, HP
19:03:05 <briancurtin> i think there's two main things to talk about: dtroyer mentioned last week progress on the lower-level and feeding into OSC. dtroyer anything to report there?
19:03:42 <briancurtin> (i forgot to put an agenda together, but it's dean's lower level stuff, and then the higher level from terry and associated changes + jamie's etherpad)
19:03:58 <dtroyer> yup.  I pasted a couple of links into the -sdks channel yesterday as an advance peek…
19:04:08 <dtroyer> The actual commit: https://github.com/dtroyer/python-openstackclient/commit/dbdbc4a2f6e07b3ecb9e2413aaeb0b3b25731cd3
19:04:31 <dtroyer> A short write-up: http://hackstack.org/x/blog/2014/09/15/openstack-low-level-api/
19:05:12 <dtroyer> Basically, I've stripped the API into a two-layers object hierarchy, the root has common methods and a child class for each API/version
19:05:54 <dtroyer> the only class data carried around is a session, the endpoint for that API and the service type in the service catalog
19:06:28 <dtroyer> the commit also has the requited changes for OSC to use it directly
19:07:03 <dtroyer> what I am most interested in is if this is something the SDK project wants to include
19:08:09 <dhellmann> it feels a little like the way sqlalchemy has several layers
19:08:11 <dhellmann> I like it
19:10:45 <briancurtin> dtroyer: i think this is going the right direction per the post, flipping through code now
19:12:02 <dtroyer> the biggest drawback I see ATM is the sheer size of api.compute.py once all calls are implemented…
19:15:15 <dtroyer> ok, that's what I had to show, we can talk some more once folk have had some time to digest it...
19:15:15 <stevelle> that does seem significant
19:15:56 <terrylhowe> the effort to write all that code seems huge.  I’d be tempted to write some script to generate it all
19:16:19 * dhellmann doesn't bring up SOAP
19:18:30 <dtroyer> it is a lot of work…and I plan to keep at it for a while…
19:21:59 <briancurtin> while we digest more of that, maybe we chat here and there throughout the week about that and move on for right now? or does any have something for dtroyer right now?
19:23:47 <briancurtin> #topic higher level
19:24:29 <briancurtin> terrylhowe: where you went with the jenkins script is really close to what i had been up to, but you're much quicker at building the plumbing to make it happen :)
19:24:54 <briancurtin> i also prefer your direction to jamie's, which would be creating a mega namespace of all types of API calls
19:25:30 <terrylhowe> I left out some plumbing in the middle, but it is close.  The missing piece is the version discovery
19:25:45 <terrylhowe> it is definitely a WIP, but good for discussion
19:26:17 <terrylhowe> https://review.openstack.org/#/c/121660/
19:26:37 <terrylhowe> https://review.openstack.org/#/c/121660/1/jenkins.py
19:26:48 <terrylhowe> ^ what the higher level looks like in use
19:27:11 <briancurtin> one minor discussion point...where did "potentate" come from? i had never even heard that word before, but after looking it up i kind of get it
19:27:12 <terrylhowe> what I wasn’t sure about is were people expecting the higher level calls to return a resource class or some wrapper class
19:27:45 <briancurtin> terrylhowe: that's one thing i went back and forth on. returning the resource is probably fine for now, can shift into some wrapper if needed later on if we think it's necessary
19:28:02 <terrylhowe> yeh, too rare a word, but there is is.  We should probably come up with something better.
19:28:42 <briancurtin> can bikeshed on that later on, works for now though, and it actually works
19:29:18 <stevelle> really nice to see use cases laid out
19:29:42 <terrylhowe> the only other quest I have is should the methods take dicts or **dicts
19:29:54 <terrylhowe> seems like people would rather **dicts
19:30:19 <briancurtin> i think i would rather **
19:30:20 <sigmavirus24> speaking from personal experience **dicts are generally nicer
19:32:12 <briancurtin> terrylhowe: since this is generally the direction i was headed anyway and you have more plumbing done, where can i jump in? you mentioned versioning - is that something you want right now or anything else higher priority?
19:33:51 <terrylhowe> well, somehow there needs to be some mediation between UserPreferences, service catalog versions, SDK valid_versions and maybe what is in the versions API for the service
19:34:24 <terrylhowe> I am distracted with another project, so it may be a while until I get to that
19:34:35 <briancurtin> terrylhowe: i'll take a look
19:34:45 <terrylhowe> cool
19:38:47 <terrylhowe> is dtroyer done looking at https://review.openstack.org/#/c/119579/7
19:39:13 <terrylhowe> I think I’ve satisfied your concerns over changing the api to Transport
19:39:49 <terrylhowe> the other SME available woudl be dhellmann on https://review.openstack.org/#/c/119628/
19:40:05 <terrylhowe> I think I addressed Doug’s concerns on that one
19:41:03 <dtroyer> terrylhowe: yeah, transport is good, I haven't been over the rest of it yet
19:42:24 <terrylhowe> unfortunately, jamie is gone for 4 weeks and probably didn’t have a chance to look at the auth plugin changes
19:42:50 <briancurtin> terrylhowe: about those inconsistencies?
19:43:09 <briancurtin> oh, well and of course your other changes
19:43:34 <terrylhowe> which inconsistencies briancurtin ?
19:44:03 <briancurtin> terrylhowe: i was thinking of something else, his identity changes where you had found stuff like email property was missing
19:44:33 <terrylhowe> we could probably patch on those to fix those minor issues
19:46:14 <dhellmann> terrylhowe: I'll put that on my review list
19:48:01 <terrylhowe> thanks dhellmann
19:49:31 <briancurtin> anything else to cover in teh next 10 min?
19:50:03 <stevelle> I'm looking for recommendations for things I can poke at
19:51:34 <stevelle> I was looking at https://bugs.launchpad.net/unifiedsdk/+bug/1365724 but wasn't sure if we should pull stuff to openstack/common or roll something short or maybe put it off for now
19:53:37 <terrylhowe> there is a utils.py but I’m not sure why that isn’t in common
19:54:11 <briancurtin> i think it could go either way. i dont actually see that bit of code needing to be commonly used, but it wouldnt hurt for it to live there in implementation and then be applied within the prop class
19:56:29 <terrylhowe> on my list of todos here I have image/metadata and identy/v2/roles special cases
19:57:14 <terrylhowe> there is also that bug about trying to parse the version off auth_url, but that might get stacked behind all the reviews out there already
19:57:32 <terrylhowe> because whatever you find would select an identity plugin
19:57:51 <stevelle> saw that snare lying it wait so haven't picked that up
19:58:53 <terrylhowe> would be thrilled if you reviewed anything out there that might interest you stevelle
19:59:11 <terrylhowe> I should have time to patch that stuff here and there
19:59:21 <stevelle> terrylhowe: will do on the reviews
19:59:35 <briancurtin> i'm catching up on reviews myself, was out of town for a bit late last week
20:01:28 <briancurtin> #endmeeting