19:00:39 <briancurtin> #startmeeting python-openstacksdk
19:00:40 <openstack> Meeting started Tue Jan 13 19:00:39 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:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:44 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:46 <briancurtin> (sorry, typo'ed the name)
19:01:11 <briancurtin> if you're here for the python-openstacksdk meeting, say hi
19:01:14 <briancurtin> Brian Curtin, Rackspace
19:01:19 <terrylhowe> Terry Howe, HP
19:01:40 <stevelle> Steve Lewis, Rackspace
19:02:36 <jamielennox> Jamie Lennox, Red Hat
19:03:06 <sigmavirus24> Ian Cordasco, Rackspace
19:04:20 <briancurtin> so from last time, a couple of reviews that had been hanging went through for some doc stuff. could still use some thoughts on the swift proxy - https://review.openstack.org/#/c/132100/
19:05:35 <briancurtin> one thing i said i was going to do, that i sort of started on - building out compute/network proxies - i'm thinking about holding off on in favor of potentially building out resource and proxy for the Poppy CDN project. it's new and currently has zero client support, so a good chance to get in before they go off and add to the pile of -client projects
19:06:29 <sigmavirus24> That sounds interesting
19:07:02 <briancurtin> that also has the potential added bonus of gaining some real world users if we build that out, because Rackspace is planning to ship Poppy as "Rackspace CDN", so having the openstack lib available and then having the rackspace plugins for auth and whatnot ready, could get the project into users hands
19:08:10 <briancurtin> i dont expect it to be any significant workload as the API didn't look too large, but it'll also put the plugin stuff through a few rounds as well as seeing how to work with provider-specifc things
19:08:18 <stevelle> solid plan
19:08:23 <sigmavirus24> +1
19:08:42 <sigmavirus24> Might be able to get some Poppy developers interested in helping out too
19:09:16 <briancurtin> do any of the non-rackspace people like that? there's a clear rackspace benefit there, but i think doing this now versus later will provide benefit to this project as well
19:09:32 <briancurtin> (and to openstack in general)
19:10:30 <jamielennox> sure, only concern is what precedent it sets in terms of non-incubated projects being in the sdk
19:11:23 <jamielennox> but i don't really mind at this early point
19:11:38 <sigmavirus24> ^ is a good question
19:12:22 <briancurtin> jamielennox: i'd have to look back through logs to figure out what we decided, but i seem to remember that we didn't want the barrier to be all that high in the interests of building *the* place to consume openstack and associated services
19:12:24 <stevelle> I don't recall, was keeping to integrated and/or incubated part of the scope?
19:13:22 <jamielennox> my objection from summit was allowing everyone to play via setuptools entrypoints and things getting out of hand and inconsistent
19:13:23 <briancurtin> i think there was some talk about namespacing them, such that official projects are just in, and perhaps things like poppy go in some other namespace for projects like that (however you define it)
19:13:52 <jamielennox> if we have too many projects that want to be in the SDK then cross that bridge when we get there
19:13:55 <terrylhowe> if the sdk supported extensions for this kind of thing, I think that would be great
19:14:17 <terrylhowe> using entry points so the vendor specific stuff could come from another project
19:14:31 <terrylhowe> there was some discussion about how to do this, but I forget all the details
19:15:11 <briancurtin> yeah i forget some of the details, but i know vendor things in-tree are strongly frowned upon or not even allowed, so extensions for them seem like the way
19:15:58 <terrylhowe> should probably have some standard like ‘rax-cdn’ or something for the name
19:16:41 <briancurtin> sort of side note: i do want to try at some point to make an installer that can unify those vendor extensions, so you can really just install one thing and be able to work with multiple clouds, but that's for another time
19:18:03 <briancurtin> anyway, it sounds like doing this CDN thing now and going through some of this work has support, so i'm going to go on with it
19:21:21 <terrylhowe> awesome, I look forward to seeing it.  I’d like to do something similar
19:22:22 <briancurtin> anything else going on to chat about?
19:24:32 <terrylhowe> nothing here
19:24:42 <stevelle> same
19:24:50 <sigmavirus24> briancurtin: last week you had added some test coverage to a class
19:24:57 <sigmavirus24> I rebased it carefully for you
19:25:10 <sigmavirus24> I think the tests are failing but at least they're being run
19:25:35 <briancurtin> sigmavirus24: yeah i had done that as well locally but that's where the tests started going haywire. maybe i'll pull from your rebase and try to fix from there
19:26:35 <briancurtin> sigmavirus24: even given the same hashseed, so the same test ordering, completely random failures...which is scary for a project like this. i could never nail it down, but i'll try again and see what happens
19:27:02 <briancurtin> rather, not completely random - the same handful of tests would fail on different versions during different runs
19:27:23 <sigmavirus24> Yeah I didn't have a chance to see if I could nail down the failures
19:27:57 <briancurtin> i'll take a look in the next day or so i think
19:29:43 <briancurtin> #endmeeting