19:00:17 <briancurtin> #startmeeting python-openstacksdk
19:00:18 <openstack> Meeting started Tue Jan 27 19:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:21 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:39 <etoews> o/
19:00:50 <briancurtin> FYI I'm double booked at this time so I'm here and also in a video conference, so I may be sort of slow
19:01:00 <stevelle> o/
19:01:00 <briancurtin> if you're here for the SDK meeting, say hi
19:01:03 <briancurtin> Brian Curtin, Rackspace
19:01:08 <terrylhowe> Terry Howe, HP
19:01:19 <etoews> Everett Toews, Rackspace
19:01:26 <stevelle> Steve Lewis, Rackspace
19:02:49 <briancurtin> i put together a small agenda at https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-01-27_1900_UTC
19:02:58 <briancurtin> first two things from me though
19:03:17 <briancurtin> since internal priorities changed, i'm holding off by a week or so on the CDN + rackspace auth plugin thing. probably getting back to that next week
19:03:56 <briancurtin> i'm going to the Cinder mid-cycle meetup tomorrow and am going to talk to a few people there about the SDK, so i've been building out cinder v2 support heading into that. should be in a review later today
19:04:46 <briancurtin> i mostly moved into that so i had something to talk with them about and demo. i also went to the keystone meetup last week, and there were a few small conversations around how to grow the project, which led to why im going to the cinder meetup
19:04:48 <terrylhowe> awesome on cinder
19:05:12 <etoews> did you start with cinder v1 or v2?
19:05:21 <etoews> nm
19:05:22 <etoews> v2
19:05:45 <briancurtin> it'll be easy enough to add v2, but it's more topical to what they're talking about so i went with that one
19:05:49 <briancurtin> er, add v1
19:06:35 <briancurtin> #topic Resource.page - how to represent this in the higher level
19:08:07 <briancurtin> terrylhowe: so Resource.page looks good, and save for one minor thing, the change to Resource.find also looks good. im wondering how to fit them into the higher level. for example, with the object_store, we return an iterator for everything with "containers()" - getting one could be get_container, but i'm not sure about one page at a time
19:08:31 <etoews> briancurtin: do you have a link for that?
19:09:00 <terrylhowe> https://review.openstack.org/#/c/149848/
19:09:08 <briancurtin> etoews: https://review.openstack.org/#/c/149848/ and https://review.openstack.org/#/c/149850/ are the changes
19:10:35 <terrylhowe> I guess I should maybe review what resources override Resource.list and see if there are changes needed
19:11:00 <terrylhowe> I just wanted something easier for Resource.find to use
19:11:41 <briancurtin> terrylhowe: so maybe it's not something we even expose to the higher level? i see teh benefit within Resource, just trying to think above it as well
19:13:49 <terrylhowe> I thought there might be other uses for it briancurtin but maybe we could make it private for now to simplify things.  I’d still need to look at resources that override Resource.list
19:13:52 <briancurtin> terrylhowe: like i'm thinking if you were filling out something like a template on a website with pages of containers/servers/networks, you might want just one page but not actually all of them. i guess you could handle that while consuming from the Resource.list and just bail out when you have what you want
19:14:15 <terrylhowe> yep
19:14:46 <briancurtin> i dont think it actually needs to be private in that it has a leading underscore. i think it's fine as a public API, just perhaps not fitting every case
19:15:47 <terrylhowe> okay
19:16:58 <briancurtin> #topic auth plugin refactor
19:17:43 <briancurtin> terrylhowe:  on the review (https://review.openstack.org/#/c/136933/) you mentioned potential growth into the UserPreference. any thoughts on where that's going?
19:18:22 <briancurtin> i had been thinking about some of the same with this rackspace auth plugin, but haven't touched UP yet
19:18:32 <terrylhowe> One thing I wanted to do was provide a list of plugins on the help for the command line example to make sure that worked
19:18:48 <terrylhowe> Doug H suggested that a while back
19:19:22 <terrylhowe> it is also about moving that code over for things like your cdn work so Connection doesn’t get cluttered
19:21:00 <terrylhowe> I would expect that module loader to be loading other extensions
19:21:03 <briancurtin> terrylhowe: one thought i had is that a Rackspace plugin provides its own UserPreference that exposes where in the Rackspace plugin some of our things live, like if i have something for our Cloud Monitoring (not a openstack project), it could still show up when i auth with rackspace
19:21:55 <etoews> briancurtin: +1
19:22:30 <terrylhowe> your own auth plugin, right?
19:22:39 <etoews> the user shouldn't even have to specify the endpoint when using a provider specific plugin
19:23:06 <terrylhowe> https://review.openstack.org/#/c/149848/ for refrence
19:23:42 <terrylhowe> ah, etoews I think the endpoint could be hardcoded in the plugin, that makes sense to me
19:24:07 <etoews> terrylhowe: that's what i'm thinking
19:24:10 <terrylhowe> I think that module loader would allow all that
19:24:11 <briancurtin> terrylhowe: yeah this would be Rackspace plugin as a whole - an auth provider, any necessary classes, its own UserPreference, etc. would make it easier to just say connection.Connection(auth_plugin="rackspace") and our rackspace plugin would figure it out
19:25:17 <terrylhowe> Yeh, I guess I’d need to look at UserPreferences now to see if is going to mess with you, but I think that sort of thing should be supported
19:27:45 <briancurtin> terrylhowe: i guess i'll know more next week once i move back to cdn/plugin stuff
19:28:51 <terrylhowe> yeh, I have a task card to add some plugins for proprietary stuff, so I’m curious to see how it works for you.  I think you’ll get started before I do at this rate.
19:31:32 <briancurtin> another thing i might want to do which came from giving etoews a walkthrough of the SDK is using os-client-config. the stuff in examples.setup() is nice for examples, but for setting up something real in a Connection it might be nice to pass in a config
19:32:41 <etoews> how far along is os-client-config integration with openstackclient?
19:33:23 <terrylhowe> I thought it was done or work-in-progress
19:33:46 <terrylhowe> there was a lot of chatter between Monty and Dean a while back on that
19:35:35 <briancurtin> terrylhowe: i guess i'll have to check on where it's at. i've just seen a bunch of movement on it lately and the idea of configuration to pass in came up
19:37:30 <terrylhowe> I like the idea of using os-client-config.  I’ve only looked at the project a little bit, but seems a good way to go
19:38:27 <etoews> at the very least use the same yaml format
19:39:27 <terrylhowe> yep
19:40:11 <briancurtin> i'll try to get the ears of client-config people and see where it's at and where it's going
19:42:01 <briancurtin> anything else going on?
19:42:52 <terrylhowe> not much, just actually pushing patches lately
19:43:06 <terrylhowe> thanks for all the feedback
19:43:23 <briancurtin> fun to see it moving quicker these last few weeks
19:43:46 <etoews> going back to pagination...wanna see something horrible?
19:44:03 <etoews> #link http://docs.openstack.org/developer/ceilometer/webapi/v2.html#complex-query
19:44:41 <etoews> ceilometer does a listing of samples and alarms with a POST
19:45:21 <etoews> should say, ceilometer *can do* a listing of samples and alarms with a POST
19:45:25 <terrylhowe> :)
19:46:27 <etoews> that page function won't be reusable on that monstrosity
19:47:26 <terrylhowe> I’m surprised you can’t post a python program to sort through the results as well
19:47:33 <etoews> lol
19:47:39 <briancurtin> etoews: that's a place we'll probably just have a ceilometer Resource provide its own page/list/whatever
19:47:54 <briancurtin> we do that in a small amount of places for custom GETs, i think
19:48:00 <stevelle> pretty much that
19:48:39 <etoews> ya. just burns me up they'd do something like that.
19:50:54 <terrylhowe> you converting to python etoews ?
19:51:16 <etoews> well...since you asked. yes.
19:51:53 <etoews> i'll be helping out on the openstack sdk.
19:51:59 <terrylhowe> really!  good news :)
19:52:26 <etoews> prepare yourself. rusty python is coming.
19:52:49 <etoews> in reviews that is. :P
19:53:37 <terrylhowe> bring it
19:56:06 <etoews> briancurtin: did you push that swift work you were showing me?
19:56:33 <briancurtin> etoews: not yet, one more test needs to pass and then it'll be out
19:56:43 <etoews> cool.
19:57:26 <etoews> is there anything in https://review.openstack.org/#/q/status:open+project:stackforge/python-openstacksdk,n,z that's mergable?
19:58:35 <etoews> wow. that's a lot of sec group rules to create a jenkins server.
19:58:38 <terrylhowe> ian’s image proxy
19:58:45 <briancurtin> etoews: "working script", "add the capability"
19:59:20 <terrylhowe> I’m not entirely suire all the rules are required, but sometimes it helps to be specific
19:59:23 <briancurtin> terrylhowe: i think ian is going to try and rework that into something like object_store and see what happens
20:00:04 <terrylhowe> well, there is definitely a higher level that could be added, but it would be nice to have the basics too
20:00:35 <etoews> is it common in python to put that much logic in an except?
20:01:40 <etoews> briancurtin: looks like we're at time.
20:01:49 <terrylhowe> even though I wrote that code, briancurtin could probably answer that better
20:04:30 <briancurtin> #endmeeting