16:00:37 <jgriffith> #startmeeting cinder
16:00:37 <openstack> Meeting started Wed Sep 11 16:00:37 2013 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:40 <openstack> The meeting name has been set to 'cinder'
16:00:54 <jgriffith> hey everone
16:01:01 <avishay> hola
16:01:06 <xyang_> hi
16:01:07 <zhiyan> hello
16:01:07 <eharney> hi
16:01:08 <jjacob512> hi
16:01:13 <joel-coffman> hey
16:01:19 <bswartz> hi
16:01:23 <jgriffith> We've got a number of things on the agenday so we should probably get to it
16:01:26 <jgriffith> https://wiki.openstack.org/wiki/CinderMeetings
16:02:03 <jgriffith> avishay: you wanna start with the topics you've listed?
16:02:12 <avishay> sure
16:02:26 <jgriffith> #topic fix list of bp's
16:02:35 <avishay> first, some blueprints that were implemented aren't listed for havana-3
16:02:59 <avishay> jgriffith: i assume you control that
16:03:00 <jgriffith> avishay: examples?
16:03:15 <avishay> volume migration, TSM driver
16:03:51 <avishay> do you want me to go through the blueprints and give you a list offline?
16:04:09 <jgriffith> avishay: so to be clear here
16:04:31 <jgriffith> avishay: if they weren't targetted and folks wanted them targetted they should have checked in before the milestone closed :)
16:04:56 <avishay> ah ok, so too late now, no problem
16:04:58 <jgriffith> avishay: I've also pointed out that there is some issues with jenkins not updating the status on the BP's for some reason
16:05:07 <jgriffith> avishay: no, not at all
16:05:23 <jgriffith> avishay: so everything that has been implemented will eventually get updated to reflect as implemented in H
16:05:31 <avishay> OK awesome
16:05:43 <jgriffith> avishay: things can get implemented (and often are) without being targetted
16:06:01 <avishay> just wanted to make sure it would make it to some list because people asked me
16:06:12 <avishay> weren't sure what got in and what didn't
16:06:17 <jgriffith> avishay: the tricky ones are the ones that go in but because of commit messages or whatever reason their status doesn't get updated and the submitter doesn't address it
16:06:21 <jgriffith> avishay: understood
16:06:26 <jgriffith> avishay: thanks for pointing it out
16:06:30 <avishay> cool
16:06:31 <jgriffith> I'll work on cleaning it up
16:06:36 <avishay> thanks :)
16:06:51 <jgriffith> #topic nova hypervisor support
16:07:07 <jgriffith> this one's yours as well
16:07:10 <avishay> yep :)
16:07:42 <avishay> so basically libvirt/KVM supports pretty much everything, but other hypervisors don't
16:07:56 <avishay> CHAP authentication, volume swap (migration), rate limiting, etc.
16:08:15 <jgriffith> not quite accurate but point taken
16:08:24 <avishay> recommendations for the best way to let them know?  mailing list, summit?
16:08:41 <jgriffith> not sure what you mean?
16:08:52 <jgriffith> YOu mean let the Nova team know?
16:08:58 <hemna> morning
16:09:03 <avishay> yes, or more specifically the hypervisor maintainers
16:09:05 <jgriffith> They're pretty aware of the deltas if that's what you mean
16:09:10 <avishay> hypervisor driver maintainers
16:09:21 <jgriffith> avishay: so there's a matrix of hypervisor feature support
16:09:32 <avishay> OK, wasn't aware, will check that out
16:09:35 <jgriffith> avishay: and they're battling with the same thing that I have been pushing in Cidner
16:09:38 <jgriffith> Cidner
16:09:44 <jungleboyj> Sorry I am late.  Another meeting ran over.
16:09:54 <jgriffith> Cinder... geesh, 3 times to spell cinder
16:10:07 <avishay> haha
16:10:07 <kmartin> avishay: https://wiki.openstack.org/wiki/HypervisorSupportMatrix
16:10:10 <jgriffith> :)
16:10:25 <avishay> OK so it's a matter of updating this list
16:10:43 <jgriffith> so FYI there has been interest expressed in going more of the direction of base api in all hypervisors
16:10:57 <jgriffith> avishay: curious what's out of date?
16:11:27 <jgriffith> Oh... never mind
16:11:46 <avishay> OK, so I will email the mailing list to see how to get this updated
16:11:54 <winston-d_> jgriffith: i guess like adding volume swap/online migration/rate-limit to that hypervisor matrix?
16:12:00 <avishay> yep
16:12:04 <jgriffith> winston-d_: yeah... I got it :)
16:12:19 <avishay> OK cool, will do that
16:12:22 <bswartz> avishay: it's a wiki, you can just edit it
16:12:40 <jgriffith> might be best to just ping russellb or some of the nova core folks when you want to start tackling this
16:12:46 <avishay> bswartz: but i want people to look at it too :)
16:12:53 <avishay> jgriffith: OK will do
16:13:05 <jgriffith> bswartz: +1
16:13:14 <kmartin> should probably add FC support to the list
16:13:16 <jgriffith> assuming you put accurate info in there :)
16:13:34 <jgriffith> avishay: anything else?
16:13:35 * DuncanT- appologises for being late to the party
16:13:38 <avishay> not for this topic
16:13:49 <jgriffith> DuncanT-: that's alright, you have to clean up
16:13:50 <bswartz> avishay: add the ones you know about personally and leave blanks for the rest, then send out pings
16:13:58 <jgriffith> avishay: another topic?
16:14:00 <avishay> bswartz: yep good idea
16:14:03 <winston-d_> kmartin: +1 for adding FC support to the list
16:14:11 <avishay> jgriffith: yes, next topic
16:14:21 <jgriffith> avishay: I mean, do you have another topic?
16:14:48 <avishay> Status of driver qualification tests - was wondering how that was going?
16:14:52 <jgriffith> ok...
16:14:54 <hemna> :)
16:14:57 <jgriffith> #topic status of driver qualification
16:15:09 <jgriffith> so first... I'm a little concerned
16:15:25 <jgriffith> I would *assume* that all of you are running the tempest suite against your driver/backend already :)
16:15:36 <jgriffith> so there shouldn't be any big surprises here :)
16:15:37 <avishay> (at least) :)
16:15:42 <jgriffith> avishay: +1
16:15:50 <jgriffith> anyway...
16:16:17 * dosaboy is currently trying to fix some tempest gaps
16:16:24 <dosaboy> i think they could defo do with soem more love
16:16:54 <jgriffith> I need to get back to this this week: https://github.com/j-griffith/cinder-cert
16:17:04 <jgriffith> dosaboy: for sure
16:17:18 <avishay> OK cool
16:17:21 <jgriffith> dosaboy: we all have a tendency to drop our patch and not update QA tests for our new features
16:17:33 <dosaboy> yep, guilty here too
16:17:38 <dosaboy> trying to redeem
16:17:51 <jgriffith> avishay: I'm still not exactly sure where I think the best place for this to live is
16:17:57 <jgriffith> dosaboy: we're all guilty
16:18:13 <hemna> why not tempest ?
16:18:24 <jgriffith> avishay: or if this is even the absolute best approach
16:18:40 <avishay> would it make sense in the future to add some way to query the storage to see if tests pass?  for example, add an interface somewhere to stat a volume on the backend?
16:18:47 <caitlin-nexenta> What's the desired timeline for adding new features to the QA tests for drivers? Obviously there is a period where the new feature is *being* implemented by various drivers.
16:18:55 <avishay> so tempest test would call 'extend_volume', then check to make sure the backend size is correct
16:19:23 <jgriffith> caitlin-nexenta: no strict timeline, but we have a tendency to just ignore tempest unfortunately
16:19:43 <jgriffith> avishay: exactly
16:19:52 <jgriffith> avishay: but that's not really how tempest is set up
16:19:58 <dosaboy> catlin-nexenta: probably best to write tests as you write features and submit once feature is merged
16:20:07 <DuncanT-> There is an argument for not merging until we have at least minimal tempest tests for the new feature
16:20:07 <kmartin> what's tempest? .....just kidding
16:20:07 <jgriffith> avishay: which is why I wonder if something deeper and more focused in cidner might be useful
16:20:09 <avishay> jgriffith: i know, but in the future
16:20:23 <jgriffith> avishay: and checking with the backend is tricky to do
16:20:29 <jgriffith> avishay: everybody is different :)
16:20:35 <hemna> couldn't we just put it in cinder itself?
16:20:47 <jgriffith> DuncanT-: there is, but the converse is true as well
16:20:47 <hemna> and require folks to submit the output of the test along w/ the patch ?
16:20:49 <caitlin-nexenta> DuncanT: that would result in new features being close to invisible.
16:20:52 <jgriffith> DuncanT-: chicken/egg
16:21:03 <hemna> (for new drivers)
16:21:14 <jgriffith> hemna: yes
16:21:23 <avishay> if the new feature isn't merged the test won't pass :)
16:21:33 <jgriffith> hemna: that was one of the options I threw out a few weeks ago
16:21:45 <jgriffith> avishay: thus chicken/egg :)
16:21:46 <hemna> but it would be nice if every milestone this was run automatically against existing drivers and a report was up somewhere for us to look at
16:21:57 <jgriffith> hemna: how ???
16:22:06 <jgriffith> hemna: you want to send me a 3par and a lefthand
16:22:13 <hemna> I'll get on that
16:22:14 <hemna> :P
16:22:20 <jgriffith> avishay: you send me each of the IBM devs
16:22:28 <jgriffith> bswartz: I'll need one of every NetApp
16:22:32 <avishay> jgriffith: how much room do you have in your house?  and do i pay for electricity?
16:22:41 <jgriffith> avishay: hehe
16:22:49 <caitlin-nexenta> We need to recognize that there is a difference between not yet supporting a new feature and failing an existing test.
16:22:50 <jungleboyj> :-)
16:22:55 <winston-d_> guys, i'll take the burden of doing such test, pls send me your back-ends.
16:22:59 <jungleboyj> jgriffith: Won't have to pay for heat anymore.
16:23:07 <jgriffith> jungleboyj: indeed
16:23:08 <avishay> jungleboyj: haha
16:23:09 <jgriffith> winston-d_: :)
16:23:17 <jgriffith> winston-d_: I volunteered first
16:23:24 <jgriffith> Ok... seriously though
16:23:31 <hemna> just call one of those solar leasing companies...they'll install solar for you for your power needs.
16:23:33 <jgriffith> first pass logic here:
16:23:46 <jgriffith> we just use existing tempest tests
16:23:47 <avishay> So I think in the future - maybe Icehouse, maybe after - we change the definition of "supporting a feature" from code merged to tests passing
16:23:59 <jgriffith> the existing tempest volume tests are core API functions that should work for everybody
16:24:09 <jgriffith> avishay: +1
16:24:13 <jgriffith> that's exactly the idea
16:24:37 <avishay> we should talk to QA core team
16:24:48 <avishay> about finding this poor guy a home
16:24:49 <jgriffith> avishay: about?
16:24:53 <jungleboyj> avishay: +1
16:24:55 <bswartz> jgriffith: if there was someplace we could send some netapp boxes and to have ongoing qualification tests done for us we would absolutely do it
16:24:58 <jgriffith> avishay: I'll just submit it
16:24:59 <kmartin> maybe require that the driver owners to run the test at the end of each milestone and submit the results, if they don't start -2 all their patches
16:25:01 <jgriffith> avishay: it's fine
16:25:04 <avishay> jgriffith: ok
16:25:07 <jgriffith> avishay: we can tweak as we go
16:25:18 <jgriffith> kmartin: that was the idea
16:25:23 <winston-d_> jgriffith: tempest tests only cover core apis?
16:25:24 <jgriffith> kmartin: remember we said something like:
16:25:27 <avishay> sounds good, i'm all for this
16:25:41 <jgriffith> log a bug against each driver at the beginning of each milestone
16:25:57 <jgriffith> the bugs get addressed at the end of the mileston by running this test and submitting results file
16:26:07 <caitlin-nexenta> Having storage vendors run tests each milestone is probably necessary, but we need realistic time schedules.
16:26:17 <jgriffith> caitlin-nexenta: what do you mean?
16:26:30 <jgriffith> caitlin-nexenta: all this is doing is "show me that you do what you say you do"
16:26:40 <jgriffith> because sadly we've found that is not always the case
16:26:52 <caitlin-nexenta> The tests need to be stable by T-X, you need to run them after that, and then have time to fix minor errors without missing the release.
16:27:10 <jgriffith> to be clear...
16:27:15 <jgriffith> this isn't about new features
16:27:25 <jgriffith> this is about base core functionality
16:27:27 <caitlin-nexenta> Basically, there needs to be an "acceptance test freeze" before code freeze.
16:27:45 <jgriffith> I think this is being overthought a bit
16:27:50 <caitlin-nexenta> ok, so how will non-core functionality be validated?
16:27:59 <jgriffith> it's not yet
16:28:01 <avishay> let's just start and see how it goes
16:28:07 <DuncanT-> avishay: +2
16:28:08 <jgriffith> avishay: exactly
16:28:09 <kmartin> avishay: +1
16:28:31 <jgriffith> all I want for a first pass is to require that drivers pass the SAME tests that every patch is gated on today
16:28:43 <jgriffith> I don't think that's at all unreaonable
16:28:47 <jgriffith> unreasonable
16:29:14 <jgriffith> ok with everyone?
16:29:17 <DuncanT-> caitlin-nexenta: We're not going to immediately pillory anybody who doesn't submit immediately, we will, like the core features this release, start a dialogue and work with people to make progress
16:29:20 <avishay> +8
16:29:20 <jgriffith> For sure it will be a learning process
16:29:31 <jungleboyj> jgriffith: Makes sense.
16:29:34 <jgriffith> and I'm not saying anybody is kept out of release or anything
16:29:49 <hemna> sounds good to me
16:29:52 <jgriffith> this is almost like a non-voting deal to start just to have documentation/tracking etc
16:30:32 <jgriffith> caitlin-nexenta: I think I see some of your points, but we're not even remotely there yet so I don't think you need to worry much about it
16:30:39 <jgriffith> we'll work through it as we go
16:30:59 <jgriffith> by I we'll have a better idea of how to institute a process
16:31:05 <jgriffith> Ok...
16:31:10 <jgriffith> #topic read only volumes
16:31:19 <jgriffith> who posted that one?
16:31:25 <avishay> jgriffith: guilty :(
16:31:32 <jgriffith> geesh!
16:31:43 <avishay> so read-only didn't make it to nova
16:31:48 <jgriffith> avishay: you're hogging all the topics today
16:32:00 <avishay> i love the attention
16:32:05 <jgriffith> :)
16:32:06 <hemna> :P
16:32:11 <avishay> what do we do with the cinder side?
16:32:13 <bswartz> let's make avishay honorary PTL
16:32:20 <avishay> bswartz: nooo!!! :)
16:32:23 <DuncanT-> If it didn't make it into nova, can we disable the API in the cinder release, since it is useless and misleading?
16:32:36 <avishay> DuncanT-: that's what i was thinking
16:32:41 <jgriffith> nothing
16:32:47 <jgriffith> no
16:32:52 <kmartin> bswartz: we'll fo that I-3 when things get fun
16:33:07 <DuncanT-> At least disabling it by default in policy.js seems sensible
16:33:18 <jgriffith> DuncanT-: that's fine
16:33:31 <jgriffith> DuncanT-: but there are other consumers besides nova
16:33:38 <DuncanT-> Oh?
16:33:46 <jgriffith> in fact a primary goal for R/O is glance
16:33:47 <winston-d_> glance?
16:33:50 <jgriffith> winston-d_: :)
16:33:59 <avishay> oh, right
16:33:59 <DuncanT-> Fair enough
16:33:59 <zhiyan> jgriffith: i don't think so TBH
16:34:05 <jgriffith> zhiyan: oh?
16:34:22 <zhiyan> jgriffith: r/o-attach is worth thing for nova also IMO
16:34:31 <winston-d_> oh, that's cinder faking glance back-end, but actually nova has to attach cinder volume
16:34:32 <zhiyan> and multi-attach will base on it
16:34:35 <winston-d_> so
16:34:50 <zhiyan> winston-d_: correct
16:35:08 <zhiyan> winston-d_: even glance attach it also (via multi-attach), such as uploading bits
16:35:19 <zhiyan> winston-d_: and download image
16:35:36 <winston-d_> zhiyan: so are you ok that we disable R/O related API for H?
16:36:05 <zhiyan> winston-d_: that's sooo bad to me, but i have no other idea...since we miss h
16:36:46 <jgriffith> I'm not sure this is such a big deal TBH
16:36:47 <winston-d_> zhiyan: so you are ok
16:36:49 <caitlin-nexenta> What would we be enabling if we did not disable it?
16:37:03 <zhiyan> winston-d_: you know a lot of discussion on design.. and slow review progress.. :)
16:37:11 <DuncanT-> I'd suggest just disabling it in policy.js with a big fat warning might be enough
16:37:24 <winston-d_> zhiyan: yeah, i understand. been there.
16:37:28 <hemna> ugh that's just ugly IMO
16:37:31 <DuncanT-> Advanced users are likely to be editing policy.js anyway
16:37:31 <hemna> bleh
16:37:31 <avishay> yea it sucks that it didn't make it
16:37:40 <jgriffith> the default policy is disabled. no biggy
16:38:35 <winston-d_> caitlin-nexenta: so R/O will allow owner of volume/admin to set a read_only flag for a volume
16:38:57 <jgriffith> K, we'll just update etc/policy.json to disable the update_readonly_flag by default
16:38:57 <avishay> winston-d_: which nobody will honor :)
16:39:01 <jgriffith> everyody good with that?
16:39:20 <zhiyan> zhiyan: is ok
16:39:25 <bswartz> no complaints
16:39:25 <DuncanT-> jgriffith: +1
16:39:28 <avishay> OK
16:39:28 <hemna> it's probably the only thing we can do at this point
16:39:48 <jgriffith> K... I'll work on that later today
16:39:58 <caitlin-nexenta> Rolling the code out sounds worse, so it sounds good to me.
16:40:01 <avishay> jgriffith: i think that's it for my topics :)
16:40:12 <jgriffith> TBC the code is still there
16:40:18 <jgriffith> avishay: haha!
16:40:29 <hemna> jgriffith, brick ?
16:40:31 <jgriffith> I'm not taking the code out of cinder (absolutely not)
16:40:39 <jgriffith> #topic brick
16:40:49 <jgriffith> not going in to nova yet
16:40:50 <hemna> so brick isn't making it into nova
16:40:55 <jgriffith> :(
16:40:58 <hemna> we decided to punt for H
16:40:59 <avishay> damn nova ruining all our fun
16:41:04 <jgriffith> hehe
16:41:17 <hemna> serious lack of reviews on the nova side left me w/o any time to respond quick enough
16:41:21 <jgriffith> TBH it's probably better anyway
16:41:32 <hemna> but I'd like to see if we can come up with a plan for I
16:41:34 <jgriffith> we need to make it a true lib and go that route
16:41:38 <hemna> where should it live
16:41:45 <jgriffith> synching is going to suck too bad
16:41:46 <hemna> oslo ?
16:41:48 <hemna> pypi ?
16:41:56 <jgriffith> hemna: I think pypi
16:41:58 <hemna> yah the syncing was killing me
16:42:03 <bswartz> not everything can go into oslo
16:42:05 <winston-d__> +1 for brick lib
16:42:06 <jgriffith> hemna: owned by cinder, published to pypi
16:42:12 <jgriffith> bswartz: +10000
16:42:23 <jgriffith> the whole idea initially was a lib anyway
16:42:33 <jgriffith> so I plan to work on that early Icehouse
16:42:35 <DuncanT-> gerrit etc through the openstack infrastructure?
16:42:35 <caitlin-nexenta> Is there a mission statement / definition of "Brick" anywhere?
16:42:36 <avishay> yes, i we need to stay in control of reviews
16:42:45 <jgriffith> and it will make the integration in to Nova MUCH easier as well
16:42:56 <hemna> I was watching the reviews and folks were putting lots of cinder deps in there.
16:43:00 <jgriffith> DuncanT-: yeah
16:43:03 <hemna> and database objects, etc
16:43:26 <avishay> caitlin-nexenta raises a good point - not everyone knows what Brick is
16:43:33 <hemna> if it's a standalone lib, it needs to have it's own docs, unit tests, etc
16:44:04 <hemna> I'm not sure how the development process will work w/ putting it in pypi from cinder
16:44:14 <jgriffith> avishay: caitlin-nexenta I'll fix that up
16:44:17 <caitlin-nexenta> hemna: having doc doesn't do much good if you don't know why you shoul read them.
16:44:20 <bswartz> why pypi and not simply an new openstack project? last time I checked there were close to 50 openstack projects -- one more can't hurt
16:44:21 <zhiyan> avishay: can we make some doc or wiki pages to explain brick?
16:44:27 <jgriffith> hemna: it'll work just like cinderclient
16:44:29 <hemna> cinder has it's own framework for unit tests, etc but brick in pypi will needs it's own
16:44:39 <avishay> zhiyan: that is a job for hemna or jgriffith :)
16:44:52 <jgriffith> I'll be working on it after we get H out
16:44:58 <jgriffith> I'll keep you all updated
16:45:04 <zhiyan> hemna: indeed, probably you are a good candidate..
16:45:04 <bswartz> and we can make avishay the PTL for that project
16:45:14 <dosaboy> I might as well ask since we're talking brick,
16:45:15 <winston-d_> jgriffith: like a sub-project under cinder?
16:45:19 <avishay> bswartz: stop making me PTL...i don't need the abuse that jgriffith gets :)
16:45:22 <hemna> hehe
16:45:23 <jgriffith> winston-d_: yes
16:45:29 <jgriffith> winston-d_: just like cinderclient
16:45:40 <winston-d_> jgriffith: nice
16:45:42 <dosaboy> i'm gonna add rbd stuff  to brick and was wondering if anyone had any particular use cases they want covered
16:45:48 <hemna> jgriffith, ok you'll have to fill me in on the details of cinderclient's dev process
16:45:55 <jgriffith> dosaboy: I think you need to hold off
16:45:56 <hemna> I'd like to get started on the lib work soon
16:46:07 <dosaboy> jgriffith: it will be for I
16:46:10 <jgriffith> dosaboy: I think there's some confusion on mission/purpose etc
16:46:16 <dosaboy> ah ok
16:46:25 <jgriffith> everyobdy just wants to dump their driver in brick now
16:46:40 <jgriffith> granted for RBD there's going to be a lot of things that this is useful for
16:46:41 <hemna> jgriffith, we should add the mission statement to the README
16:47:06 <jgriffith> hemna: yeah, at a bare minimum
16:47:09 <dosaboy> jgriffith: so was unclear myself but am going along the lines of adding code that is currently used in multiple places
16:47:15 <jgriffith> I need to clean up the focus on that whole thing
16:47:35 <xyang_> hemna: so does copy volume <-> image use brick code now?
16:47:36 <dosaboy> so only common code/functionality goes in
16:47:40 <jgriffith> dosaboy: yeah... and that's cool.  I just don't want everybody distracted with brick submissions right now
16:47:44 <hemna> xyang_, yes
16:47:45 <dosaboy> sure sure
16:48:25 <jgriffith> which brings me to the next topic :)
16:48:33 <jgriffith> #topic feature patch submissions
16:48:48 <jgriffith> Please please please stop submitting new feature patches
16:49:09 <jgriffith> after we open up I in a few more weeks you can have a ball
16:49:18 <dosaboy> :)
16:49:20 <jgriffith> but right now I'm just going to -2 anything I see anyway
16:49:38 <jgriffith> we're supposed to be testing/bug-fixing and doing docs right now
16:49:51 <eharney> when do we branch between Havana and Icehouse?
16:50:03 <jgriffith> eharney: that sort of depends
16:50:05 <hemna> jgriffith, +1
16:50:14 <jgriffith> eharney: it comes down to how many rc's we need
16:50:27 <jgriffith> once we get through rc's and feel stable then we'll open up I
16:50:27 <kmartin> jgriffith: I have a new driver, is it to late to submit for H?
16:50:35 <eharney> ok
16:50:44 * jgriffith slaps kmartin twice
16:50:52 <winston-d_> :)
16:50:59 <avishay> haha
16:51:15 <avishay> kmartin: might as well backport to grizzly while you're at it
16:51:24 <jgriffith> ha!!!
16:51:26 <hemna> ooh good idea, I'll -1 him and ask him to do that
16:51:33 <kmartin> sure that was the plan
16:51:38 <avishay> haha
16:51:40 <jgriffith> #topic design summit
16:51:55 <jgriffith> Nov will be here before we know it
16:51:59 <kmartin> every submit should have an associated bug id
16:52:05 <jgriffith> http://summit.openstack.org/
16:52:13 <jgriffith> kmartin: +1
16:52:20 <jgriffith> else it gets rejected
16:52:29 <jgriffith> or just ignored
16:52:37 <avishay> kmartin: "cinder does not support driver X" is not a valid bug!
16:52:37 <dosaboy> kmartin: +1 I've seen a few commits getting approvied without associated bug/bp id in commit message
16:52:38 <bswartz> summit is 8 weeks from yesterday
16:52:49 <jgriffith> there are exceptions but generally yes
16:52:56 <jgriffith> avishay: :)
16:53:10 <kmartin> avishay: lol
16:53:21 <jgriffith> so everybody feel free to start proposing session topics
16:53:32 <hemna> I have a few :P
16:53:36 <hemna> GO
16:53:36 <caitlin-nexenta> jgriffith: URL for submitting proposals?
16:53:37 <avishay> as do i
16:53:40 <bswartz> jgriffith: do you have a link to the place where we propose them?
16:53:48 <avishay> http://summit.openstack.org/
16:53:51 <winston-d_> http://summit.openstack.org
16:54:09 <bswartz> oh that was a shorter URL than expeted
16:54:37 <caitlin-nexenta> Is there still a distinction between public sessions and developer sessions?
16:54:47 <jgriffith> caitlin-nexenta: oh yes
16:54:56 <jgriffith> caitlin-nexenta: this is developer/design summit sessions
16:54:56 <winston-d_> caitlin-nexenta: yes
16:55:07 <jgriffith> has nothing to do with general marketing/sales stuff
16:55:08 <jgriffith> :)
16:55:29 <bswartz> the public ones are "conference sessions" the developer ones are "design summit sessions"
16:55:31 <caitlin-nexenta> just wanted to be sure this was the right half of the submissions.
16:55:40 <jgriffith> :)
16:55:41 <kmartin> caitlin-nexenta: public has came and gone, this is the like for the design sessions
16:55:52 <kmartin> s/like/link
16:56:12 <winston-d_> caitlin-nexenta: yes, summit.openstack.org is the right place for design summit
16:56:53 <avishay> jgriffith: how many slots do we have this time?
16:57:04 <jgriffith> about the same as last time
16:57:17 <jgriffith> we tend to juggle around a bit after we see how things start to turn out
16:57:25 <avishay> cool
16:57:38 <jgriffith> I think 11 was the initial proposal
16:58:05 <kmartin> jgriffith: did I miss the "Consistent implementation of qos-spec in drivers" topic?
16:58:05 <jgriffith> I guess that's about all I have
16:58:15 <jgriffith> I can't remember what I wanted to talk about WRT QoS :)
16:58:21 <jgriffith> kmartin: haha
16:58:33 <jgriffith> kmartin: you did not, but I don't remember what the heck I had in mind there TBH
16:58:42 <jgriffith> and it's a bit late now anyway in the release :)
16:58:57 <winston-d_> 00:44 < jgriffith> avishay: caitlin-nexenta I'll fix that up
16:59:15 <hemna> do we have a "hey lets argue about standardization" session yet?
16:59:16 <kmartin> i think it was rolling to winston-d_ solution for QoS?
16:59:25 <avishay> hemna: haha
16:59:26 <jgriffith> hemna: no but we will :)
16:59:35 <hemna> :)
16:59:37 <bswartz> hemna: I just proposed it
16:59:42 <bswartz> :-p
16:59:44 <jgriffith> bswartz: :)
16:59:49 <winston-d_> jgriffith: so that'll become a design summit session
16:59:53 <hemna> excellent, didn't want to miss that one.
16:59:57 <jgriffith> so FYI, we can't punt on that one again this time
17:00:11 <jgriffith> we really need to start using the capabilities reporting in a standard way
17:01:06 <avishay> maybe we can start an etherpad on it ASAP and not leave it for the summit?
17:01:17 <winston-d_> standardization, best part of design summit...
17:01:29 <winston-d_> avishay: +100
17:01:30 <bswartz> I plan to make some proposals in writing well in advance of the summit
17:01:33 <avishay> maybe if we have THREE sessions on it this time...
17:01:36 <jgriffith> avishay: probably will be a good idea, at least have a better focus going in that way
17:01:43 <jgriffith> bswartz: perfect
17:01:46 <bswartz> and if my topic gets picked, the proposals will be REQUIRED READING before we let you in the room
17:01:58 <jgriffith> avishay: NONO... not the 3 sessions part
17:02:04 <jgriffith> avishay: the advanced effort part :)
17:02:04 <avishay> jgriffith: hahah
17:02:05 <kmartin> ok lets all watch jgriffith  end the meeting
17:02:12 <jgriffith> kmartin: ha!!!
17:02:17 <jgriffith> #endmeeting