19:00:19 <briancurtin> #startmeeting python-openstacksdk
19:00:20 <openstack> Meeting started Tue Feb 10 19:00:19 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:23 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:07 <briancurtin> #topic Roll Call - say hi if you're here for the SDK meeting
19:01:09 <briancurtin> Brian Curtin
19:01:29 <terrylhowe> Terry Howe, HP
19:02:31 <briancurtin> i wrote up a small agenda at https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-02-10_1900_UTC
19:03:08 <briancurtin> i know everett won't be here, ian might, not sure about anyone else, so i guess let's go and maybe more will come in
19:03:24 <briancurtin> #topic auth plugins work!
19:03:52 <redrobot> o/
19:03:53 <briancurtin> I already had this working in tree, and it was as simple as just taking it out, but as you probably guessed, auth plugins simply work
19:04:18 <briancurtin> hey redrobot - i don't recognize your handle
19:04:41 <redrobot> hi briancurtin, I'm Douglas Mendizábal, Racker and PTL for Barbican
19:04:59 <briancurtin> ah cool, welcome (i think i even saw you earlier today)
19:05:08 * sigmavirus24 is late
19:05:13 * sigmavirus24 apologizes
19:05:25 <briancurtin> apology denied
19:06:33 <briancurtin> anyway, https://github.com/briancurtin/rackspace-sdk-plugin works - it's not on PyPI and that's just a temporary repo, but installing the SDK and then installing that will work perfectly fine. i'm going to write up a simple rackspace-only service and see how that works, and then write up a user guide on how to implement custom plugins. probably won't get to
19:06:33 <briancurtin> that immediately, but soon
19:06:58 <terrylhowe> I’m surprise you have an auth_url
19:07:51 <briancurtin> terrylhowe: that's something i just noticed as i was about to copy/paste an example...i need to get handle more directly. right now i do "connection.Connection(preference=pref, auth_plugin="rackspace", auth_url="https://identity.api.rackspacecloud.com/v2.0/", user_name="curtin", api_key="key")" and i can work with the existing object_store stuff
19:08:26 <terrylhowe> cool
19:09:29 <briancurtin> i'll just move that auth_url inside and then it's good, i think. assuming that's all we need, in the process of writing up the user guide i will put a cookie-cutter plugin somewhere so anyone can get started for their provider
19:10:24 <briancurtin> not a whole lot else going on directly with this right now - it's more a part of a greater thing with supporting the CDN service and an internal task i have, but it was cool that it just worked so easil
19:11:17 <briancurtin> #topic split up of cinder review
19:12:13 <briancurtin> so at least terry saw this, but i put a pretty large review of cinder out there to follow up on what i started going into that mid-cycle meetup. i'm going to split it up probably as follows, which is a guideline we should probably follow going forward: one change for all Resources, then one change for each resource's addition to the connection level, then
19:12:13 <briancurtin> docs
19:13:13 <briancurtin> i prefer docs alongside changes so it becomes a fluid part of the process, but for this cinder one i actually need help with that along with it depending on some compute work to be truly useful in the docs
19:14:36 <briancurtin> within that change there were a few comments from terry that i'll address with changes in those subsequent review
19:16:03 <briancurtin> the topic of naming came up in https://review.openstack.org/#/c/150979/5/openstack/volume/v2/_proxy.py and i would just like to make a general comment (which is in there, but i'll summarize here): i think right now this is the time to experiment with APIs and try different names and things and see how this all works. nothing is locked down yet, and we
19:16:03 <briancurtin> haven't really built enough on top of this to know how we or other users are going to want to use it
19:17:35 <redrobot> briancurtin interesting... that's kinda why I joined the meeting today...
19:18:55 <redrobot> briancurtin not cinder, but renaming things in general
19:20:27 <terrylhowe> the keystore stuff has a very generic proxy redrobot
19:20:37 <terrylhowe> or were you thinking about another part of the sdk
19:20:49 <briancurtin> redrobot: i'd love to get other perspectives involved in building out a nice high-level interface to work with this stuff. right now there are basically two approaches or conventions. eventually we'll converge on one after things have seen more use
19:23:06 <briancurtin> that does mean we're going to break anyone who may be an early adopter, but i think that's expected, or it will be made to be an expectation. we do have some releases on PyPI but they're not very advertised. as we get more completed and can build nice demos, i think we'll be more public about the releases to show them off
19:23:07 <redrobot> cool... I'm still spinning up on the client work
19:23:41 <redrobot> I've been spending a lot of time on our client, and was curious about what (if any) work had been done here for barbican
19:24:14 <terrylhowe> I was in Paris at the barbican presentation and added it to the sdk
19:24:40 <redrobot> terrylhowe nice!
19:24:45 <briancurtin> redrobot: i dont know how discoverable this at the moment, but our current docs are at http://python-openstacksdk.readthedocs.org/en/latest/
19:25:10 <terrylhowe> https://github.com/stackforge/python-openstacksdk/tree/master/openstack/keystore
19:26:19 <redrobot> So one thing we did a while back was rebrand to "key-manager" instead of "keystore"
19:26:35 <redrobot> I was wondering if it would be feasible to rename the module in the client?
19:26:38 <briancurtin> right now none of the keystore things show up in docs though, but i'll add some docstrings and add them to the resource docs. would be nice to work together on a high-level (proxy) interface for that, would be helpful in coming up with some docs
19:27:40 <briancurtin> redrobot: we'd have to name it key_manager, but yeah it can change
19:27:49 <redrobot> I would love to help out with that... we have our hackathon mid-cycle coming up next week, and we'll be talking about clients a lot...
19:27:57 <briancurtin> redrobot: where at?
19:28:12 <redrobot> briancurtin It'll be in Austin at the Capital Factory
19:28:42 <briancurtin> redrobot: mind if i crash the party? i did the same for the cinder meetup at IBM in austin
19:30:40 <redrobot> briancurtin the more the merrier! :) You can get all the details here: https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint
19:31:49 <briancurtin> cool, i'll be there. at the cinder one they just gave me the floor for a bit to introduce the project and then it was around an hour discussion on what we do, how we do it, how it'll fit into cinder, who wanted to work on it, stuff like that. their mid-cycle was more planning than hacking, but one guy wrote up some cinder resources like an hour later
19:32:21 <briancurtin> anyway, back to the topic since we're halfway through
19:32:24 <sigmavirus24> Yeah, the glance midcycle sounded a lot like planning/demos instead of hacking
19:32:42 <briancurtin> i'll follow up with probably 4-5 smaller reviews on cinder and go from there
19:32:51 <briancurtin> #topic Resource.list consistency update
19:33:39 <terrylhowe> I marked one of my patches related to this WIP
19:33:56 <terrylhowe> not sure when I’ll get back to it
19:34:13 <briancurtin> back when britt pointed out that something wasn't responding to pagination because it was disabled (neutron?), i went off and hacked up Resource.list to be a catch-all list call. it ended up doing way too much and is not really a usable solution in real life. it's fine against devstack with tiny responses, but doing a double  request for 10,000 containers is
19:34:13 <briancurtin> not acceptable
19:34:26 <briancurtin> terrylhowe's Resource.page actually solves this, or starts to
19:34:49 <briancurtin> individual resources that return lists, but not paginated ones, should probably override list and use page directly
19:35:23 <briancurtin> they would essentially look like the get_types method at the top of this module: https://review.openstack.org/#/c/150979/5/openstack/volume/v2/_proxy.py
19:35:24 <terrylhowe> oh we sent that on through, I just have a task card to review resources that override list
19:36:20 <briancurtin> terrylhowe: at first i didn't really get Resource.page except for being an organizational thing, but when it clicked that it will solve that non-paginated but still a list calls...i fell in love
19:38:35 <terrylhowe> yeh, I think that would be a good model what you have there
19:39:46 <briancurtin> so that's all on that, just wanted to note that i think we can avoid that crazy catch-all Resource.list
19:40:18 <briancurtin> other than that stuff, i'm probably going to kick off some smaller resource changes to build out some sample apps for an internal talk i have in a few weeks
19:40:37 <briancurtin> and then terry and i submitted a proposal for teh summit to talk about building applications on the SDK
19:41:27 <briancurtin> anything else going on?
19:42:03 <terrylhowe> sort of back to the naming thing, I’m not necessarily opposed to volume.types over volume.list_types, the only concern I can think of is if there is some name conflict
19:42:26 <terrylhowe> we get some very generic resource names like object and type sometimes
19:42:35 <terrylhowe> is there anything to be concerned about there?
19:43:29 <stevelle> that is a hurdle throughout openstack
19:44:09 <terrylhowe> I see brian has a long comment there I hadn’t seen before in the volume patch.  I’ll have to look at that
19:44:15 <briancurtin> yeah, object and type are kind of hard to work with, but the majority of names are far away from those and i'd rather code to the majority
19:45:21 <briancurtin> terrylhowe: yeah that comment is pretty long...i have sort of strong opinions on naming. some way will win in the end, but i'd like to stick with the names in there at least for now
19:46:20 <briancurtin> terrylhowe: and im going to be doing some work on compute soon, where i'll probably just leave those names as-is and see how they feel
19:48:51 <terrylhowe> redrobot: https://bugs.launchpad.net/python-openstacksdk/+bug/1420461
19:48:51 <openstack> Launchpad bug 1420461 in OpenStack SDK "keystore renamed key-manager" [Undecided,New]
19:49:28 <terrylhowe> should we have a ticket to rename all list_ proxy methods?
19:50:28 <briancurtin> terrylhowe: i dont think we should rename them yet. i would just leave everything as-is, work with it, build stuff, and find out what really is best. i could very well be wrong that the methods should just be a plural version of the resource type, e.g., volumes, containers, etc
19:50:44 <terrylhowe> k
19:53:18 <briancurtin> anything else to add?
19:53:59 <redrobot> terrylhowe thanks!  I'll try to get a patch up in the next few days
19:54:13 <terrylhowe> cool, thanks
19:54:19 <terrylhowe> nothing else here
19:54:51 <briancurtin> i guess that's it. thanks everyone!
19:56:00 <briancurtin> #endmeeting