19:00:19 #startmeeting python-openstacksdk 19:00:20 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:23 The meeting name has been set to 'python_openstacksdk' 19:01:07 #topic Roll Call - say hi if you're here for the SDK meeting 19:01:09 Brian Curtin 19:01:29 Terry Howe, HP 19:02:31 i wrote up a small agenda at https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-02-10_1900_UTC 19:03:08 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 #topic auth plugins work! 19:03:52 o/ 19:03:53 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 hey redrobot - i don't recognize your handle 19:04:41 hi briancurtin, I'm Douglas Mendizábal, Racker and PTL for Barbican 19:04:59 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 apology denied 19:06:33 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 that immediately, but soon 19:06:58 I’m surprise you have an auth_url 19:07:51 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 cool 19:09:29 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 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 #topic split up of cinder review 19:12:13 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 docs 19:13:13 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 within that change there were a few comments from terry that i'll address with changes in those subsequent review 19:16:03 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 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 briancurtin interesting... that's kinda why I joined the meeting today... 19:18:55 briancurtin not cinder, but renaming things in general 19:20:27 the keystore stuff has a very generic proxy redrobot 19:20:37 or were you thinking about another part of the sdk 19:20:49 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 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 cool... I'm still spinning up on the client work 19:23:41 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 I was in Paris at the barbican presentation and added it to the sdk 19:24:40 terrylhowe nice! 19:24:45 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 https://github.com/stackforge/python-openstacksdk/tree/master/openstack/keystore 19:26:19 So one thing we did a while back was rebrand to "key-manager" instead of "keystore" 19:26:35 I was wondering if it would be feasible to rename the module in the client? 19:26:38 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 redrobot: we'd have to name it key_manager, but yeah it can change 19:27:49 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 redrobot: where at? 19:28:12 briancurtin It'll be in Austin at the Capital Factory 19:28:42 redrobot: mind if i crash the party? i did the same for the cinder meetup at IBM in austin 19:30:40 briancurtin the more the merrier! :) You can get all the details here: https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint 19:31:49 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 anyway, back to the topic since we're halfway through 19:32:24 Yeah, the glance midcycle sounded a lot like planning/demos instead of hacking 19:32:42 i'll follow up with probably 4-5 smaller reviews on cinder and go from there 19:32:51 #topic Resource.list consistency update 19:33:39 I marked one of my patches related to this WIP 19:33:56 not sure when I’ll get back to it 19:34:13 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 not acceptable 19:34:26 terrylhowe's Resource.page actually solves this, or starts to 19:34:49 individual resources that return lists, but not paginated ones, should probably override list and use page directly 19:35:23 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 oh we sent that on through, I just have a task card to review resources that override list 19:36:20 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 yeh, I think that would be a good model what you have there 19:39:46 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 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 and then terry and i submitted a proposal for teh summit to talk about building applications on the SDK 19:41:27 anything else going on? 19:42:03 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 we get some very generic resource names like object and type sometimes 19:42:35 is there anything to be concerned about there? 19:43:29 that is a hurdle throughout openstack 19:44:09 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 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 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 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 redrobot: https://bugs.launchpad.net/python-openstacksdk/+bug/1420461 19:48:51 Launchpad bug 1420461 in OpenStack SDK "keystore renamed key-manager" [Undecided,New] 19:49:28 should we have a ticket to rename all list_ proxy methods? 19:50:28 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 k 19:53:18 anything else to add? 19:53:59 terrylhowe thanks! I'll try to get a patch up in the next few days 19:54:13 cool, thanks 19:54:19 nothing else here 19:54:51 i guess that's it. thanks everyone! 19:56:00 #endmeeting