19:01:35 <briancurtin> #startmeeting python-openstacksdk
19:01:36 <openstack> Meeting started Tue Feb 24 19:01:35 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:39 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:52 <briancurtin> if you're here for the SDK meeting, say hi
19:01:54 <briancurtin> Brian Curtin
19:01:59 <sigmavirus24> Ian Cordasco, Rackspace
19:02:00 <sigmavirus24> hi
19:04:42 <sigmavirus24> stevelle: ping
19:04:55 <stevelle> Steve Lewis, Rackspace
19:05:09 <sigmavirus24> o/ terrylhowe
19:05:14 <terrylhowe> Terry Howe, HP
19:05:24 <terrylhowe> sorry I’m late
19:06:52 <briancurtin> here's a little agenda https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-02-24_1900_UTC
19:07:02 <briancurtin> #topic What to do with Resource.page?
19:08:30 <briancurtin> i wrote up some thoughts at https://bugs.launchpad.net/python-openstacksdk/+bug/1424211 on where page/list/find all fit together. i think page, being in the middle of it, should either just return teh body of the page, or create the resources contained in the body. we've had a few proposals over the last few weeks
19:08:30 <openstack> Launchpad bug 1424211 in OpenStack SDK "Change how page, find, and list work together" [Critical,New]
19:09:05 <briancurtin> i really think the only one we can't do is the intermediate list. i think one way or another - body or yielded objects - we should just pick one and go
19:09:56 <stevelle> I think I like the factoring of having page provide the body
19:10:05 <stevelle> but tough call
19:11:10 <stevelle> that should keep page as a fairly thin abstraction that helps find do it's job easier
19:11:32 <briancurtin> since we're now expecting consumers to get a list of objects from list(paginate=bool), i think page giving the body probably makes sense so we're not providing two different ways to get the same thing. if we go that route, i wonder if page should then become private, since it's an implementation detail of how list is built
19:12:02 <sigmavirus24> briancurtin: so personally I like generators everywhere =P
19:12:13 <sigmavirus24> but if we're going with page providing just the body, then I agree it should be private
19:12:45 <stevelle> agreed private
19:13:34 <briancurtin> terrylhowe: since find has to use list, did you have a use case for page providing that list?
19:13:51 <briancurtin> *"that list" meaning litearlly a list type
19:15:44 <terrylhowe> find could use a list, it was just complicating find to use list, so I created page
19:16:05 <terrylhowe> I think some of the changes out there will make page less important as a public method
19:19:27 <briancurtin> while find could use a list, i think it breaks the chain of involving generators. are we ok with page moving to _page and just staying-as is to return the body? and then we go to work on making find nice?
19:20:05 <terrylhowe> yes, I think so
19:20:52 <briancurtin> #topic https://review.openstack.org/#/c/155362/ - auth plugins
19:21:25 <briancurtin> terrylhowe: i haven't adjusted my rackspace plugin yet to move over to this, but i'm going to do that within the next few days and try it out
19:21:51 <briancurtin> terrylhowe: does any of that have to change with the KSC stuff or is it fine as-is?
19:22:10 <briancurtin> KSC stuff as in these recent resynchronization changes
19:22:20 <terrylhowe> the dynamic service load stuff is similar, but unrelated to auth plugins
19:23:21 <terrylhowe> he ksc stuff should be fine as is
19:23:41 <briancurtin> ok cool
19:26:10 <briancurtin> and speaking of KSC stuff, im wondering what we should do purely for auth plugins since we're currently staying in sync with KSC but doing our own thing...so i have a plugin to fall in line with http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/ and it's basically just the same thing here for SDK
19:26:48 <briancurtin> like for right now, a plugin (as i understand, or as i previously implemented) provides both auth and services
19:30:15 <terrylhowe> well, the plugin authenticates and parses the service catalog
19:30:38 <terrylhowe> user preferences defines the service you can work with
19:31:50 <briancurtin> so, i think i write an auth plugin that works with KSC directly and it also works for SDK, and then i have a plugin that provides our services/preferences, which depends on that auth plugin?
19:33:23 <terrylhowe> I would think a plugin that works for us would also work for KSC, but I haven’t tried it
19:33:52 <terrylhowe> the biggest difference is KSC plugins out there depend on oslo-config and have command line args in them
19:34:03 <briancurtin> (which i hate)
19:34:30 <terrylhowe> where we have valid_options instead
19:34:50 <terrylhowe> yeh, I don’t like putting command line args down that low
19:35:42 <terrylhowe> and the dependency on oslo config there is inconvenient, not sure which point you hate
19:35:59 <briancurtin> having to provide a config file with the auth args to load and use a plugin is quite low on the usability scale
19:36:48 <briancurtin> it's really just the whole experience. if my app is built on top of that, i'll have my own config and then a config just for auth of a service it's using. that feels really bad but i guess i need to work more with it
19:37:13 <briancurtin> eh getting off on a tangent anyway
19:37:47 <briancurtin> #topic making another release?
19:39:36 <terrylhowe> are there any issues outstanding that need to be fixed before a release?
19:39:37 <briancurtin> i think find will probably take some iteration and time to get right, but we pushed a lot of stuff through in the last ~2 weeks that would be nice to toy with in a package and start writing about and whatnot. i've been messing with a few compute things and we made some things easier there, but would be nice to get https://review.openstack.org/#/c/158191/ in
19:39:37 <briancurtin> so it works the same as flavor
19:41:20 <terrylhowe> yes, I’d like to give an OSC integration another shot, I normally learn a lot from that
19:42:05 <briancurtin> yeah i need to start looking more at that (been saying that for a while i guess...)
19:43:20 <stevelle> no strong opinion but I'd rather see the plugin topic resolved prior
19:45:08 <briancurtin> stevelle: since plugin work could take some time since we haven't fully dug into it, i dont want to get into a situation where we wait for it and then we get deep into all sorts of other stuff like the last two weeks. the more often we release, the better, imo
19:46:05 <briancurtin> makes it easier to write about and talk about when i can just tell people to install it versus checkout certain branches since we're stuck in a point we can't release from due to nested dependencies
19:46:52 <stevelle> briancurtin: as I said, no strong opinion. So long as it's clear breaking changes are expected, especially at integration points like plugins.
19:47:38 <stevelle> I think that is clear enough already
19:48:37 <terrylhowe> so release away I guess
19:48:53 <terrylhowe> we could always cut another once we figure out service loading
19:49:03 <briancurtin> cool, i'm going to wait for https://review.openstack.org/#/c/158191/ to land and then tag a release
19:50:25 <briancurtin> releasing whenever we get through big changes or even big groups of changes is ideal to me, especially while we don't currently have the need to do formal release planning, just do it by what we're working on
19:50:34 <terrylhowe> that’s a relatively easy one, but it wasn’t a big priority for me
19:50:45 <terrylhowe> image details are important?
19:51:21 <briancurtin> terrylhowe: not super super important, but im working on a few compute things where it would be nice to just have the same info that we just added for flavor. it's the same thing as that change
19:51:47 <terrylhowe> okay
19:52:46 <briancurtin> anything else going on?
19:52:53 <terrylhowe> nothing here
19:55:51 <briancurtin> cool. thanks all!
19:56:15 <briancurtin> #endmeeting