19:00:23 <briancurtin> #startmeeting python-openstacksdk
19:00:24 <openstack> Meeting started Tue Oct  7 19:00:23 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:28 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:40 <briancurtin> Brian Curtin, Rackspace
19:01:26 <dtroyer> Dean Troyer, Nebula
19:01:40 <terrylhowe> Terry Howe, HP
19:02:42 <briancurtin> before getting into that issue, just wanted to mention that i started hacking on teh talk outline, as i get it more completed this afternoon/tomorrow morning i'll send it over terrylhowe
19:03:28 <briancurtin> anyway, terrylhowe brought up that we should probably talk about https://bugs.launchpad.net/unifiedsdk/+bug/1377424 - how plugins can/should state their valid arguments, as commented on in reviews by doug
19:03:30 <terrylhowe> awesome, looking forward to it briancurtin
19:04:19 <terrylhowe> I’ve collected all of Doug’s comments in the ticket there, I don’t have a clear vision how to proceed if we should just use a dict or some special set of classes
19:04:52 <briancurtin> so i guess not being really experienced with plugin systems, its probable that i dont know all of the angles here, but i had thought to just add a validate method in a base class somewhere that checks the list of valid args against what the plugin loader wants to create the plugin with
19:05:24 <briancurtin> which basically does what that loop in create is doing, just seeing that what you're about to try will actually work, then it returns/raises as appropriate
19:07:15 <terrylhowe> maybe we just need to add a member to the plugins that is required_arguments then
19:09:10 <briancurtin> i think that would probably do it, or it seems like it would
19:10:57 <terrylhowe> okay, well easy enough after I fix up the connection class though
19:11:16 <briancurtin> i dont know if we need to go the step that there's required arguments and valid arguments (where valid just includes required)
19:11:42 <dtroyer> FWIW, mhu's proposal fro OSC to do this queries the plugins to build the parser, assuming we know which plugin is requested, and relies on the plugin to kick it back if anything is wrong
19:12:14 <briancurtin> if you give something outside of required+valid, should probably say something - warning, log message, etc., perhaps raise an exception
19:13:28 <dtroyer> I'd think a super-set of required+valid would be ok in cases where you don't have a specific plugin requested and are searching for one that accepts the args.
19:14:14 <terrylhowe> yeh dtroyer, but it also seemed to me that it would be odd for an SDK to get involved in argparse stuff they way KSC does
19:14:52 <terrylhowe> if people want it that way, we could do that
19:15:07 <dtroyer> terrylhowe: we're not using ksc that way, OSC handles the actual parser bits, the ksc plugins only provide the list of what they want to see
19:15:45 <dtroyer> you're right about parser's being blow the sdk, at least outside a high-level comon use case bundle-type thing
19:15:52 <dtroyer> s/blow/outside/
19:20:43 * dhellmann apologizes for being late
19:21:15 <briancurtin> terrylhowe: so does it work that plugins should say what they expect, and then grow a validate classmethod that checks they're about to be created properly?
19:21:49 <terrylhowe> yeh, that sounds fine to me
19:22:53 <dhellmann> do we expect plugins with completely unique validation arguments, or is it just that we have different plugins each wanting a slightly different subset of some predictable whole?
19:23:55 <dtroyer> dhellmann: we are already in the former situation, password vs token auth args are disjoint
19:25:06 <dhellmann> ok, given that I think we need some more explicit querying ability so an app developer knows what to even pass to a constructor
19:25:16 <terrylhowe> Jamie would have a clearer picture what this might look like
19:25:37 <dhellmann> alternately, we could say that the app developer has to explicitly manaage the authenticator instead of doing fancy plugin handling
19:26:34 <dtroyer> jamie's plugins already have plugin.get_options() to get their requested args
19:27:10 <terrylhowe> I just renamed that to valid_arguments or something like that
19:27:11 <dhellmann> ok, I got mixed up with the centralized validation parts
19:28:39 <dhellmann> is the ultimate goal to have a single function that takes **kwds and creates a handle for talking to the cloud, including the authenticator?
19:29:40 <terrylhowe> I was moving the connection class in that direction dhellmann
19:30:05 <terrylhowe> I’m getting rid of all the ‘create’ methods and just making everything in the constructor
19:32:51 <dhellmann> ok
19:33:30 <dhellmann> do we expect people to provide their own auth plugins?
19:34:46 <dhellmann> I'm trying to figure out a reasonable way to document the variations of arguments that should be passed for different plugins
19:34:56 <dhellmann> if we can get it out of the plugins themselves, we can generate some tables in sphinx
19:34:59 <briancurtin> there's going to have to be some sort of rackspace auth plugin (though we're aiming toward actually being on keystone)
19:35:08 <dhellmann> makes sense
19:36:38 <terrylhowe> If we don’t want to support loading arbitrary plugins, we can at least allow the user to pass one in to the connection class
19:37:19 <dhellmann> yeah, that's sort of what I was thinking -- instead of using plugins to build the thing, just have the app developer pass an instance of it
19:37:38 <dhellmann> that doesn't make it as easy to support different authentication plugins in different apps, though
19:38:09 <dhellmann> of course, if they take different args anyway that is still potentially a challenge
19:43:51 <briancurtin> dtroyer: anything going on with your lower level looks in OSC? i haven't been following OSC
19:44:50 <dtroyer> he base class and object-store class merged last week.   I haven't added any more yet but network and image are next in the priority queue
19:47:55 <briancurtin> cool. i havent looked much at OSC in general, but i'll take a look soon and see what's up
19:52:23 <briancurtin> 8 min left - anything left to chat about?
19:52:59 <terrylhowe> nothing here
19:54:45 <briancurtin> thanks all!
19:54:49 <briancurtin> #endmeeting