19:00:15 <briancurtin> #startmeeting python-openstacksdk
19:00:16 <openstack> Meeting started Tue Jan 20 19:00:15 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:20 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:44 <briancurtin> Brian Curtin, Rackspace
19:02:32 <stevelle> Steve Lewis, Rackspace
19:04:56 <terrylhowe> Terry Howe, HP
19:05:28 <briancurtin> sigmavirus24: here?
19:05:35 <sigmavirus24> sorry, yes
19:05:39 <sigmavirus24> Ian Cordasco, Rackspace
19:05:46 <briancurtin> anyway, i put together a smallish agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-01-20_1900_UTC
19:05:52 <briancurtin> #topic CDN progress
19:06:32 <briancurtin> so i put the resources up for the CDN service, but i can't test them just yet. that depends on having Rackspace auth done (which is in progress) since it's not installable in devstack. i left it as Workflow-1 for now, but i think it's complete
19:08:06 <briancurtin> i got the Rackspace auth plugin started, but it's inside the sdk repo while i figure it out. it seems to work fine, and allows me to use a connection to list compute servers, so i think it's working. just need to figure out how it will actually work living outside of the repo (https://github.com/briancurtin/python-openstacksdk/commit/2426aa925d9ecf875647d4a1903febd4ceb089a4 has a working copy)
19:08:08 <sigmavirus24> I haven't had the chance to look at the Poppy/CDN work yet but I will later this week probably
19:09:52 <briancurtin> i'm thinking one thing that should be in the SDK tree is that an entry_point will have to be listed in setup.cfg for this rackspace auth plugin, but actual code will live elsewhere. i think that's the way to do it
19:11:02 <briancurtin> then for starters, install SDK, install rackspace-auth, and then you can do some stuff. we've talked about this in the past, but it would be great (later on) to have the ability to package everything together
19:11:22 <briancurtin> also brings up the eventual topic of testing provider specific drivers and how that works
19:12:50 <briancurtin> i dont know if that falls under the third-party testing things i've read about with projects like neutron testing network vendors things
19:13:13 <stevelle> seems like it would to me
19:13:35 <sigmavirus24> I haven't looked into that much either, but that sounds right. terrylhowe might know more?
19:14:34 <terrylhowe> I thought some other folks were against have vendor specific stuff in the sdk
19:14:59 <terrylhowe> I’m not necessarily against it, but I thought some people didn’t want that
19:15:19 <briancurtin> terrylhowe: it wouldn't live inside the SDK, i just did it that way for now so i could test it easily and make sure it works. it'll eventually move it into some other repo
19:15:20 <terrylhowe> Fog is that way, where there is vendor specific stuff in the code
19:15:44 <terrylhowe> ah, okay
19:16:08 <briancurtin> i'm not opposed to it, but i remember some strong opposition. it would make it nice to keep everything together, but then people didn't like vendors polluting the upstream-ness of the project, etc
19:16:47 <terrylhowe> Well, the Fog project became a bit bloated and I think they split things up a bit
19:17:02 <sigmavirus24> briancurtin: poppy is a stackforge project still, right?
19:17:07 <briancurtin> sigmavirus24: yes
19:17:26 <stevelle> I think having vendor specifics separated will make things easier in the long term, but does incur a cost in the short term
19:18:13 <briancurtin> the major thing to me with vendor things living separately is still making it possible to bundle them all together and have (as an option) a way to get the SDK with plugins
19:18:22 <terrylhowe> I was thinking I’d put out some hp extension of some sort, but there would probably be changes to the SDK to support the integration
19:18:28 <terrylhowe> yes briancurtin
19:18:44 <sigmavirus24> so packaging can take care of all of that
19:18:54 <stevelle> what sigmavirus24 said
19:19:00 <sigmavirus24> it will make it confusing about where the right place to report a bug might be but I think we can package our way out of that
19:19:35 <sigmavirus24> What we probably need to avoid is another oslo.* problem though in which some pieces get installed as editable and that causes namespace problems
19:19:49 <sigmavirus24> But that would be the "easiest" way forward
19:20:03 <sigmavirus24> That's all tangential to the topic at hand though
19:20:25 <terrylhowe> openstack.hp openstack.rax something like that?
19:21:04 <terrylhowe> I haven’t given much thought to the namespace issues
19:21:08 <sigmavirus24> Might be better to continue this in #openstack-sdks since we're almost at half-time
19:21:32 <briancurtin> terrylhowe: i'll take a look at how to organize that once i get a little further along with this CDN stuff, since i think i'll hit this
19:22:01 <briancurtin> #topic object_store proxy
19:22:03 <terrylhowe> cool, briancurtin
19:22:52 <briancurtin> is there any strong objection to me pushing this on and then moving onto part 2, making it easier to work with header values and such, basically adding handling of kwargs from one of my big comments in teh review
19:23:19 <sigmavirus24> briancurtin: not sure I have the context for this discussion
19:24:35 <terrylhowe> https://review.openstack.org/#/c/132100/ this one?
19:24:45 <briancurtin> sigmavirus24: it's https://review.openstack.org/#/c/132100/ - mostly the discussion on https://review.openstack.org/#/c/132100/8/openstack/object_store/v1/_proxy.py
19:25:05 <sigmavirus24> ah
19:25:36 <terrylhowe> I thought we were done with that one
19:25:55 <terrylhowe> you created a couple tickets on some issues as I recall, wasn’t that for this one?
19:27:16 <briancurtin> terrylhowe: ah, that was pagination, which i need to finish tests for. also two smaller issues that should happen outside of this, specific to object_store, but not to the proxy
19:27:54 <sigmavirus24> Yeah, I thought https://review.openstack.org/#/c/147914/ was teh solution
19:29:27 <briancurtin> oh yeah, there's that one. if that's good, i already made that a dependency of the object_store change, so it'd be ready to go
19:31:01 <briancurtin> if not, will adjust accordingly...not trying to hold it hostage :)
19:32:01 <terrylhowe> seems like some of the approaches with swift are different than we do it elsewhere.  that being said swift is different.
19:32:19 * notmyname sees "swift"
19:32:47 <briancurtin> terrylhowe: what do you mean?
19:32:57 <terrylhowe> and I’d like to get this stuff through too
19:33:26 <terrylhowe> like the resource.from_id method, the examples are different too
19:33:44 <terrylhowe> the whole notion of supporting a class at the proxy level
19:35:07 <terrylhowe> I hate to keep brining up Fog, but they do that where you can pass in an id or a class
19:35:23 <terrylhowe> kind of cool feature, but we don’t do that for any of the other services I don’t think
19:36:05 <briancurtin> as far as i know they're all up in teh air. if the way we do the object_store proxy turns out to be a good idea, i'd love to apply it to everything else, or whichever turns out to be a good high-level view
19:36:55 <terrylhowe> I’d like consistency I’m flexible on the features we provide
19:38:23 <briancurtin> i'm looking at the object_store one as a test. i need to build out the example script a bit more and try to build someting real world and see how it works. a lot of the other proxies are very thin layers that just maintain your session, which i dont think go far enough, so we could play with any of them in order to figure this out
19:39:25 <terrylhowe> yeh, they are thin
19:41:06 <briancurtin> i think it's a good place to try and make things easier within the confines of one service. then there's the layer we talked about in the past like monty's Shade (i think it's called that), with the "give me a server with a floating ip attached and i dont care how"
19:41:45 <briancurtin> that's probably more of where we'll run into those vendor namespacing things, but anyway
19:42:43 <briancurtin> terrylhowe: i'd like to take a few cuts at another service's proxy to see how it can be shaped, so i might come out with another one. i think i mentioned compute/network in the past anyway, so i might go that route
19:44:01 <terrylhowe> yeh, in those areas, there is a lot of potential for higher level proxy methods than currently provided
19:45:56 <briancurtin> sigmavirus24: any interest in stretching your image proxy beyond what it is? if not, can be handled later
19:46:14 <sigmavirus24> briancurtin: No objections from me
19:47:00 <briancurtin> sigmavirus24: as in you are personally interested in toying with the interface, or you're cool with that being done to it?
19:47:20 <sigmavirus24> I'm interested in doing it
19:47:24 <briancurtin> awesome
19:47:33 <briancurtin> go for it
19:48:35 <briancurtin> anything else going on?
19:49:10 <terrylhowe> Nothing here.  I’ll have a fix out for that image version problem this week is all from me.
19:49:25 <terrylhowe> the endpoint with no version in the service catalog that is
19:49:38 <sigmavirus24> interesting
19:49:42 <briancurtin> cool, looking forward to that. have been thinking about it but havent written anything
19:52:51 <briancurtin> #endmeeting