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