19:00:23 #startmeeting python-openstacksdk 19:00:24 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:28 The meeting name has been set to 'python_openstacksdk' 19:00:40 Brian Curtin, Rackspace 19:01:26 Dean Troyer, Nebula 19:01:40 Terry Howe, HP 19:02:42 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 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 awesome, looking forward to it briancurtin 19:04:19 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 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 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 maybe we just need to add a member to the plugins that is required_arguments then 19:09:10 i think that would probably do it, or it seems like it would 19:10:57 okay, well easy enough after I fix up the connection class though 19:11:16 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 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 if you give something outside of required+valid, should probably say something - warning, log message, etc., perhaps raise an exception 19:13:28 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 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 if people want it that way, we could do that 19:15:07 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 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 s/blow/outside/ 19:20:43 * dhellmann apologizes for being late 19:21:15 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 yeh, that sounds fine to me 19:22:53 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 dhellmann: we are already in the former situation, password vs token auth args are disjoint 19:25:06 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 Jamie would have a clearer picture what this might look like 19:25:37 alternately, we could say that the app developer has to explicitly manaage the authenticator instead of doing fancy plugin handling 19:26:34 jamie's plugins already have plugin.get_options() to get their requested args 19:27:10 I just renamed that to valid_arguments or something like that 19:27:11 ok, I got mixed up with the centralized validation parts 19:28:39 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 I was moving the connection class in that direction dhellmann 19:30:05 I’m getting rid of all the ‘create’ methods and just making everything in the constructor 19:32:51 ok 19:33:30 do we expect people to provide their own auth plugins? 19:34:46 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 if we can get it out of the plugins themselves, we can generate some tables in sphinx 19:34:59 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 makes sense 19:36:38 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 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 that doesn't make it as easy to support different authentication plugins in different apps, though 19:38:09 of course, if they take different args anyway that is still potentially a challenge 19:43:51 dtroyer: anything going on with your lower level looks in OSC? i haven't been following OSC 19:44:50 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 cool. i havent looked much at OSC in general, but i'll take a look soon and see what's up 19:52:23 8 min left - anything left to chat about? 19:52:59 nothing here 19:54:45 thanks all! 19:54:49 #endmeeting