19:01:17 <briancurtin> #startmeeting python-openstacksdk
19:01:18 <openstack> Meeting started Tue May 27 19:01:17 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:21 <openstack> The meeting name has been set to 'python_openstacksdk'
19:02:47 <briancurtin> if you're here for the python-openstacksdk meeting, there's a little agenda at https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-05-27_1900_UTC - it's just the open reviews to talk about so we can move on, if you need the links
19:03:00 <briancurtin> and with that, who's here?
19:03:02 <briancurtin> Brian Curtin, Rackspace
19:03:08 <edleafe> Ed Leafe, Rackspace
19:03:19 <bknudson> Brant Knudson, IBM
19:03:34 <jamielennox> Jamie Lennox, Red Hat
19:03:49 <Alex_Gaynor> Alex Gaynor, Rackspace
19:05:13 <briancurtin> #topic https://review.openstack.org/#/c/91889/ -- Authentication from keystoneclient
19:05:50 <briancurtin> has anyone looked at the big auth review and have any comments? terry made a bunch of changes, and i have a few small comments on the last set, but anyone else?
19:06:29 <briancurtin> jamie had some comments, most of which were addressed, but a few things potentially outstanding (the factory functions are one off the top of my head)
19:06:54 <jamielennox> regarding the _factory for plugins, the reason i made it private in keystoneclient and advocate for it's removal here is that we should expect that there are going to be way more plugins and that loading them manually from a factory like that won't work
19:07:24 <jamielennox> you should never be in the position that you have a bunch of arguments and you need to figure out which plugin to use - the plugin should always be explicit
19:07:42 <Alex_Gaynor> +1
19:09:15 <terrylhowe> Terry Howe HP running late
19:09:16 <briancurtin> yep, agreed there
19:12:29 <briancurtin> outside of the factories, anything else going on in the change that people like/dont like?
19:13:31 <jamielennox> just looking auth/service.py has been removed - how does that affect get_token etc
19:13:53 <terrylhowe> I renamed it service_filter
19:14:06 <terrylhowe> I think there is some doc cleanup that needs to happen in other files
19:14:53 <terrylhowe> some things I'm reluctant to change because of other outstanding changes in the pipeline
19:17:40 <briancurtin> terrylhowe: overall i'm good with this, and i think we can go back and change things if we need, in the interest of just moving on so we can build something
19:18:22 <briancurtin> does anyone have anything with this change that is a hard blocker?
19:18:24 <terrylhowe> I'd definitely like some feedback on it from jamielennox
19:18:31 <briancurtin> certainly
19:18:36 <jamielennox_> stupid vpn
19:20:04 <jamielennox> terrylhowe: i'm ok with coming back to fix things
19:20:14 <jamielennox> i would like the factories gone up front though
19:20:17 <terrylhowe> cool, that'll work
19:20:27 <jamielennox> people tend to look at them and assume that's how you should be creating things otherwise
19:20:41 <terrylhowe> okay
19:21:25 <briancurtin> if anyone else who hasn't reviewed can try to give it a look after this, that would be great, and then we'll be rolling on
19:22:19 <briancurtin> #action remove factory methods, should be good to go
19:22:43 <briancurtin> #topic https://review.openstack.org/#/c/94887 -- Clean up transport stuff out of the resource class
19:23:15 <terrylhowe> dtroyer needs to look at that, is he afk?
19:23:23 <briancurtin> i thought this looked fine and +2'ed, could use another look
19:23:32 <briancurtin> and yeah, from dtroyer
19:24:12 <briancurtin> not sure if he's around, but i just added him as a reviewer on the change
19:25:46 <terrylhowe> I think I've minimized the changes and Dean might be able to live with it based on offline discussions I've had with him
19:26:00 <briancurtin> sounds good
19:26:58 <briancurtin> #action needs a dtroyer review, seems like it should be workable given minimized changes
19:27:02 <briancurtin> #topic https://review.openstack.org/#/c/94707 -- Add command structure to example code
19:27:07 <briancurtin> this one is really small
19:28:26 <jamielennox> sure, that's fine
19:29:09 <jamielennox> so long as no-one ever thinks it should be pulled out and make into a proper CLI tool :)
19:29:28 <terrylhowe> it is hill billy, but it should do
19:31:09 <briancurtin> #topic what's next?
19:31:41 <briancurtin> so if we think the auth change is basically good to go, what do we want our next step to be?
19:32:40 <terrylhowe> I'd like to implement some resource class and get a feel for everything
19:33:35 <jamielennox> terrylhowe: i agree, i had a play with some resource classes a while ago and i think there will be some pain points to get through, but i don't think we'll know what they are until we try it
19:34:41 <briancurtin> is there any particularly good starting point on that? edleafe - from having implemented a lot of them via pyrax, any thought there?
19:35:13 <edleafe> Not sure given the reverse nature of the current design
19:36:30 <edleafe> if you have endpoints, you need a way to create the desired URLs for retrieving objects. Pyrax created them from the JSON response, but you've indicated that you want to pre-define the attributes, so that's another sticking point.
19:39:47 <terrylhowe> I was kind of thinking with starting with something simple like some basic glance thing and then pick a complicated one after that
19:40:07 <Alex_Gaynor> sounds good
19:42:35 <briancurtin> i'll be traveling for a bit to pittsburgh and russia, but i guess i know the most about swift of anything, so maybe looking there myself
19:43:23 <terrylhowe> swift would be a good one to try early since it is a bit oddball
19:45:30 <jamielennox> i'll try to have a crack at a few of the basic keystone classes, a little swamped currently though
19:46:22 <briancurtin> besides starting to play with those, is there anything else to talk about? 15 minutes left, and it seems like we're slowing down
19:47:16 <terrylhowe> more example code
19:48:35 <briancurtin> should start making docs a hard requirement at this point as well
19:49:08 <briancurtin> (touched on that at the summit, havent had it come up though)
19:49:49 <terrylhowe> docs would be especially useful on the resource implementations
19:50:30 <terrylhowe> if users are using it at that level
19:50:49 <jamielennox> are we ok to have those docs inline or should they be in a folder?
19:51:01 <jamielennox> inline as in docstrings
19:51:10 <Alex_Gaynor> Docstrings and the docs/ dir are for different things IMO
19:51:41 <edleafe> +1 on not relying on docstrings
19:51:49 <Alex_Gaynor> docs/ dir is for prose, for anyone using the public API for the SDK. docstrings are reference material (not always prose) for someone who is (usually) reading the code itself
19:52:11 <edleafe> People working on the SDK use the docstrings. Developers *using* the SDK need higher-level docs
19:52:30 <terrylhowe> sounds good
19:52:34 <jamielennox> ok
19:52:35 <briancurtin> agreed. i think we need to be on top of both, and make sure we're starting to build up user docs as we're developing
19:53:15 <edleafe> You should probably write the usability docs *before* implementing the SDK
19:56:29 <briancurtin> i sketch things out locally like that from time to time, but i dont particularly care about doc driven as a process or anything like that
19:57:12 <edleafe> I just mean figure out how you would expect an SDK to work, and then implement it that way
19:57:38 <edleafe> It's too easy for technical folks to get tied up in the details of the implementation
19:57:49 <edleafe> And forget how devs need this to work
19:59:12 <briancurtin> two minutes left, anything to squeeze in?
20:00:28 <briancurtin> #endmeeting