19:00:50 <briancurtin> #startmeeting python-openstacksdk
19:00:51 <openstack> Meeting started Tue Sep  9 19:00:50 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:54 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:32 <briancurtin> Brian Curtin, Rackspace
19:01:40 <dtroyer> Dean Troyer, Nebula
19:01:47 <geography76> Dana Bauer, Rackspace
19:02:03 <jamielennox> Jamie Lennox, Red Hat
19:04:37 <terrylhowe> Terry Howe, HP
19:04:48 <terrylhowe> sorry I was late, got all caught up in v3 identity reviews there
19:04:53 <dhellmann> Doug Hellmann, HP
19:05:42 <briancurtin> from me, i really don't have anything to add myself other than toying around high-level and not having much to show for it. terry seems to have pushed a bunch of work, so what's up terrylhowe?
19:06:09 <briancurtin> and that summary email went out - thanks for taking a look everyone
19:06:33 <terrylhowe> well, it is an awful dependecy list of reviews, but maybe a start to something
19:07:21 <terrylhowe> since dhellmann is here, I just wonder how plugins are loaded from other packages
19:07:27 <terrylhowe> can the namespace be the same?
19:07:40 <terrylhowe> if so, I can kill the namespace parsing
19:08:13 <dhellmann> terrylhowe: yes, the plugin namespace is a completely different set of namespaces from the package namespace
19:08:36 <dhellmann> any package can add something to "openstack.auth" or whatever and it can be found, no matter what package it's in
19:08:45 <terrylhowe> cool
19:09:24 <terrylhowe> so, I was kind of hoping this connection class would be the main entry point.  It would have a compute, volume, network, etc
19:10:00 <terrylhowe> earlier, people were calling it client, but connection seems to fit better to me
19:10:13 <briancurtin> agreed on connection naming
19:10:34 <dtroyer> I'm all in favor of putting 'client' as a class description on the shelf with 'core'
19:10:42 <dhellmann> +1
19:12:01 <terrylhowe> well, I was thinking that connection class would load another bunch of entry points for services
19:12:12 <terrylhowe> and maybe those services would load another set for versions
19:12:17 <terrylhowe> not sure how that would work out
19:12:59 <dhellmann> you could do that, and you can also scan the available entry points without loading them all
19:13:14 <dhellmann> so you could look for which versions are available, then load only the one you need based on some criteria
19:13:33 <terrylhowe> some kind of lazy load would be good
19:13:49 <dhellmann> I'm not sure if stevedore has a class that would do that already, but it would be easy enough to add
19:14:32 <terrylhowe> cool
19:15:21 <terrylhowe> when we get to that point, we can deal better with the version discovery issue I think
19:16:08 <dhellmann> sure
19:16:43 <terrylhowe> any thoughts briancurtin or dtroyer ?
19:17:46 <dtroyer> that sounds a little like OSC's ClientManager, am I reading right?
19:17:50 <briancurtin> terrylhowe: i like the general idea of lazy loading the available entries. i don't really have much else to add at the moment - i guess id have to maybe see more of it
19:18:11 <terrylhowe> yeh, dtroyer
19:20:45 <terrylhowe> I’m not sure how it will actually work, but I was hoping it would look to the user like we discussed in previous meetings.
19:22:15 <terrylhowe> I’m just not sure what object would be passed when we get to the resource type level
19:22:40 <terrylhowe> obj = connection.identity.user
19:22:53 <terrylhowe> I’m not sure what that should be or look like
19:23:43 <terrylhowe> maybe it would just be a reference to the User resource class
19:24:58 <terrylhowe> anyway, that is all I have on that subject
19:25:23 <briancurtin> yeah, perhaps that could work (ref to user resource)
19:25:36 <jamielennox> a versioned resource?
19:25:58 <terrylhowe> yeh, it would point to identtiy.v3.user.User
19:26:46 <jamielennox> so if we are not allowing things from outside the repo - whats the point of stevedore? why not just import?
19:27:06 <dhellmann> good question
19:27:47 <terrylhowe> I thought we would allow things from outside the repo
19:28:43 <briancurtin> i dont know that we 100% decided on that. there was a thought that it would all be inside, some thought some things might be outside, some didn't know/care
19:29:18 <jamielennox> there was a decision at least that we shouldn't be reliant on other libraries
19:29:19 <briancurtin> however, we shouldn't *restrict* outside things, i dont think
19:29:31 <briancurtin> ah yeah there was that
19:29:53 <jamielennox> i guess it depends at what point you consider that we would 'depend' on behaviour found via entrypoint
19:31:50 <dhellmann> would entry points be useful for allowing non-integrated projects to add connection code?
19:31:55 <dtroyer> I'm not certain I know what would need to be loaded either.  What I've found is that sort of thing comes from the app side, wanting to extend a libraries' behaviour.  The only thing I see is wanting to replace something underneath, like changing the session used
19:33:18 <jamielennox> we have always talked about sdk as layers, from a middle layer i don't see this being a problem
19:33:50 <jamielennox> from the most upper, simple case i think we should be way more opinionated than just let any old module provide new functions
19:34:05 <dhellmann> that makes sense
19:34:25 <dhellmann> for the auth case, I could see allowing plugins to load auth settings from different places than we might imagine on our own
19:34:42 <dhellmann> from the rest API servicing side, maybe we don't want those to be as dynamic
19:37:03 <terrylhowe> okay, so only from in the repo it is.  Makes things easier.
19:37:09 <jamielennox> so yes, auth absolutely - but i don't think our core case is as general as OSC where anyone is accepted
19:37:34 <dtroyer> jamielennox: right…looking up the stack is different than looking down
19:37:52 <dtroyer> so, speaking of layers, when we're ready to move on…
19:38:12 <jamielennox> yep
19:38:35 <terrylhowe> go dtroyer
19:39:25 <dtroyer> I've continued the POC of a low-layer API and have gotten close to usable code.  prototyping it in OSC so I can use the KSC Session/Auth bits.
19:40:06 <dtroyer> the object-store API is as far done as OSC has, I want to do a few other APIs and at least one multi-version.  hopefully ready to look at next week.
19:40:27 <dtroyer> just wanted to let y'all know that was Coming Soon To An IRC Meeting Near You
19:41:45 <dtroyer> it is a simple object tree of 1 class per API/version combination, and inherits from previous versions so unchanged methods don't need to be copied
19:42:38 <dtroyer> in OSC it is able to replace the client/manager objects with the single instance
19:43:05 <dtroyer> the Resources can easily be built on top to support the upper layers
19:43:47 <dhellmann> nice
19:43:49 <dtroyer> </description>
19:44:15 <jamielennox> sounds good
19:45:12 <terrylhowe> maybe if it was put in a requests directory in the SDK Dean?
19:45:27 <briancurtin> yep, sounds cool to me
19:45:30 <terrylhowe> Fog has a similar thing where it has a resource model and a request model
19:46:50 <dtroyer> yeah, this isn't unique, my problem was every time I got close I thought I was re-inventing the manager classes and threw it away.
19:47:45 * briancurtin has had similar thoughts a bunch of times
19:48:01 <dtroyer> TBH, I first saw this pattern in Anaconda about six years ago…
19:48:29 <dtroyer> and then promptly forgot it because I was a 'Perl Guy'(TM) then
19:50:24 <jamielennox> dtroyer: i think that's going to scale better than the current classmethods
19:50:58 <jamielennox> there are just too many edge cases, the common functions would become a mess
19:51:34 <dtroyer> there is still room for some common functions, but the freedon to skip those is there too
19:54:30 <jamielennox> so i want to let people know i'm away for the next 4 weeks
19:54:46 <jamielennox> i'll probably answer email that's sent to me, but i won't see -dev lists
19:55:22 <briancurtin> cool. enjoy your time away
19:55:28 <jamielennox> before i go i'll try and put down some of my ideas for the highest level interface and email you all, just so it's not a complete surprise when i bring it up again at summit
19:57:29 <terrylhowe> thanks jamielennox have a great holiday
19:57:39 <dhellmann> yeah, have a good break
19:58:15 <jamielennox> i will :)
19:59:51 <briancurtin> thanks all!
19:59:55 <briancurtin> #endmeeting