16:01:55 #startmeeting cinder 16:01:55 Meeting started Wed Sep 18 16:01:55 2013 UTC and is due to finish in 60 minutes. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:58 The meeting name has been set to 'cinder' 16:02:06 hi 16:02:12 \o 16:02:16 \o/ 16:02:16 hi 16:02:21 o/ 16:02:24 hi 16:02:25 Hey there everyone 16:02:29 Looks like a good group 16:02:37 missing avishay and winston 16:02:45 but we'll move on and have a short meeting 16:02:59 I have a couple of things I wanted to remind everyone 16:02:59 A short meeting? Bwah ha ha! 16:03:02 caitlin-nexenta: ping 16:03:10 jungleboyj: hehe... well, we can always have goals 16:03:11 without those two it's possible! :D 16:03:15 jgriffth: yes? 16:03:21 jgriffith: +2 16:03:32 caitlin-nexenta: wanted to make sure you were here for this first topic since Victor doesn't do IRC 16:03:43 #topic Stop submitting your feature patches 16:04:01 As you've noticed if you submit a new feature patch I'm just going to -2 it anyway until we open up icehouse 16:04:16 Please refrain from continuing to propose new feature patches for the time being 16:04:19 jgriffith: when it will be open? 16:04:30 zhiyan: depends on when we get RC1 cut 16:04:31 jgriffith, shouldn't that go for anything that doesn't have a bug associated with it ? 16:04:37 hemna: yes 16:04:59 hemna: I should've specified but assumed process of elimination :) 16:05:02 I've seen a few reviews that are nothing more than code cleanups....no bugs associated 16:05:04 jgriffith: got it 16:05:09 jgriffith: so would now be a bad time to submit another file-shares patch? 16:05:23 jk 16:05:26 hemna: fell free to -2 them unless they're minimal and worth putting in 16:05:39 but at this point we want to try and limit any risk of regression/failures 16:05:56 bswartz: HA!!! 16:06:05 bswartz: you are funny this morning 16:06:15 bswartz: you're covering for kmartin ? 16:06:29 yes 16:06:30 ok 16:06:45 I'm here 16:06:46 that's what I was hoping you'd say. I'll -2 those now then. thanks 16:06:46 so anyway, just wanted to say. Please refrain for now as it just clutters the gates and the review dashboard 16:06:52 kmartin: you have help today :) 16:07:05 #topic testing 16:07:14 We need all hands on deck for testing 16:07:23 the more we find and fix now the better 16:07:36 I'd like to get the RC cut and move on to icehouse as soon as possible 16:07:43 +1 16:07:48 the only thing standing in the way for icehouse work is getting the RC cut 16:07:54 so you see the priority :) 16:07:58 when is the RC ? 16:08:04 hemna: depens on when we're ready 16:08:08 ok 16:08:08 nice, can I get help making PowerPoint slides? 16:08:17 hemna: the way it works is we close out the issues for RC1 16:08:19 wait we still have 7 weeks to the developer summit 16:08:19 we test 16:08:26 see how the bug trajectory goes 16:08:32 repeat until there are no bugs 16:08:38 rc1, 2, 3 16:08:45 if we go past 3 we're doing something wrong 16:08:53 that's bad mmmkay 16:08:57 what kind of icehouse work should be happening between now and then? what about havana DOCS etc? 16:09:11 kmartin: I can spell check for you. ;-) 16:09:12 bswartz: yes, docs as well 16:09:12 ew, that 4 letter word 16:09:24 bswartz: none right now 16:09:33 bswartz: and none depending on where we are in a couple weeks 16:09:52 bswartz: the window is there for an early start but that doesn't mean we'll be able to or should use it 16:10:13 bswartz: by the time we get H ready and get sessions set up I don't think 7 weeks is as long as some may think 16:10:44 worked with a deployer on getting cinder running. made me take notes on things I found missing in the docs. 16:10:58 thingee: nice! 16:11:06 thingee: publish it somewhere and we should all pitch in 16:11:40 it's not a big list, but it could probably be expanded once people see it and think about it. 16:12:19 thingee: yeah, hoping mind share will help 16:12:30 thingee: I'd really like to excel on the docs side if we could 16:12:47 G was a HUGE improvement 16:12:56 we can/should build on that momentum 16:12:58 jgriffith: I am happy to help with that as a relative newbie. 16:13:02 * med_ is hoping to do some doc-ing that gets approved 16:13:10 med_: :) 16:13:17 jgriffith: Can bring fresh eyes and questions to it. 16:13:31 coolness 16:13:36 speaking of summit.... 16:13:42 #topic design summit 16:13:44 http://summit.openstack.org/ 16:13:52 IMO this is a great list so far 16:14:37 I suspect all of these will be approved 16:14:44 thanks to folks for jumping on these early 16:14:58 with that... 16:15:00 I think I'm done 16:15:02 still room for a few more 16:15:14 kmartin: yes, still room which is great 16:15:15 jgriffith, we may have another BP and session proposal on the way 16:15:21 hemna: bring it on 16:15:41 Ok, anybody have anything they want to add/ask regarding sessions? 16:15:42 when is the cutoff date for submitting them? 16:15:44 i probably do too 16:16:02 kmartin: you've got some time, but I guess considering the legal process you should move quickly :) 16:16:09 heh 16:16:09 kmartin: I don't have a cut-off date right now 16:16:30 kmartin: typically we go up until the 11'th hour on session organization etc 16:16:40 I worked around those issues, I can do whatever I want for the next 3 releases 16:16:43 kmartin: although it would be nice to NOT do that this time 16:16:51 kmartin: Nice!!! 16:16:55 kmartin: buy me a pony! 16:17:09 or a free hpcs account? :P 16:17:22 hemna: Rax gave me one of those :) 16:17:27 hemna: or at least a credit 16:17:30 nice! 16:17:45 Ok... 16:17:45 jgriffith: more like a lottery ticket for the hoops I had to go though 16:17:52 kmartin: hehe 16:17:59 kmartin: I can only imagine 16:18:04 #topic open-discussion 16:18:12 anything on anybody's mind? 16:18:23 so the manager fix? 16:18:31 hemna: :) 16:18:36 heh 16:18:36 so the devref docs 16:18:43 if no one else wants the floor 16:18:45 is that doable for H or am I thinking I now? 16:18:55 med_: def H 16:18:58 nodz. 16:19:02 med_: docs are special category :) 16:19:09 hemna: take it 16:19:12 * med_ feels special 16:19:21 med_: *is* very special 16:19:24 ok, so I have https://review.openstack.org/#/c/46843/ outstanding 16:19:35 It tries to enforce the driver initialization flag 16:19:42 which the manager was basically all but ignoring 16:19:54 I have some jenkins issues to work out today 16:20:17 but the idea is to have the manager enforce the driver being initialized properly. 16:20:48 I need to look more at the backup manager as well and make sure it's being enforced there as well 16:21:25 jgriffith: Regarding the cinderclient changes for the qos support. Is that going to get in H? https://review.openstack.org/#/c/46979 16:22:05 jgriffith, you mentioned you had some feedback for me on this yesterday, you can ping me outside the meeting if you like 16:22:24 I presume we want this to make RC 16:23:31 ? 16:24:55 seems that jgriffith moved the meeting to the #openstack-cinder? 16:25:07 crickets 16:25:11 kmartin: yes 16:25:36 chirp 16:25:37 chirp 16:25:37 DERP!!! 16:25:48 I just started my rant in #cinder 16:25:50 and jgriffith is back 16:25:52 lol 16:26:01 sorry bout that 16:26:01 jgriffith, ok, so I'm on board w/ you on the manager not breaking 16:26:05 anyway 16:26:06 I think that's great 16:26:13 and I'm enforcing that in my patch 16:26:16 Ok, we'll get your patch looked at and move on 16:26:32 all I did is just add some logging of the caught exception. 16:26:33 hemna: I agree that there needs to be a second half to the change 16:26:41 hemna: perfecto 16:26:44 and then enforcing the initialized flag in the rest of the manager. 16:26:55 henma: could you save me a lot of reading, where are the QOS specs enforced? 16:27:04 jgriffith: Regarding the cinderclient changes for the qos support. Is that going to get in H? https://review.openstack.org/#/c/46979 16:27:25 kmartin: it has to :) 16:27:34 ok coolio. I'll fix the jenkins issues today and put up another patch on it. 16:27:42 kmartin: I'm waiting on that from winston and avishay's migration changes 16:27:44 caitlin-nexenta: Either at the hypervisor or the backend, depending on which you set when you create the limit 16:27:49 then I plan to push to PyPi 16:28:09 jgriffith: kind of needs land before I start making the changes in the driver 16:28:12 DuncanT: thanks. 16:28:17 kmartin: huh? 16:28:24 kmartin: you messin with me again? 16:28:37 That's something I have to check. It's not the most visible of constraints for backend implementers. 16:29:23 jgriffith: and what about cinderclient change for r/o-volume support, do you think we can landing it concurrently? https://review.openstack.org/#/c/44672/ and https://review.openstack.org/#/c/45171/ 16:29:23 kmartin: ?? chirp chirp chirp 16:29:31 zhiyan: oh about tht 16:29:32 that 16:29:53 jgriffith: sorry I was in the cinder room 16:29:54 I thought last week we all decided that since it wasn't supported in Nova we were going to disable it in the policy? 16:30:00 kmartin: HA! 16:30:23 zhiyan: in which case I don't want to put something in the client that can't actually be used yet 16:30:28 zhiyan: or am I missing something? 16:30:29 jgriffith: yes, i know. but those two are for cinderclient. 16:30:43 zhiyan: sure, but why expose them if you can't use them? 16:31:51 jgriffith: actually those be used by nova...humm, yes, actually i just want to try land them concurrently to save time, and nova server side change can be landing asap when FF finished.. 16:32:30 zhiyan: I'd prefer to see it as a WIP and as soon as we release RC we can update 16:32:51 jgriffith: it would be difficult to test qos feature if I can't set the qos_specs and relate them to volume types 16:32:54 jgriffith: ok. 16:32:54 zhiyan: makes it cleaner for pkg maintainers/builders for H IMO 16:33:25 kmartin: yeah, I've been using curl and tried to get postman workign again :) 16:33:33 jgriffith: make sense. thanks. will mark it wip until FF finish. 16:33:45 kmartin: the problem I see is that since we're well beyond FFE we're all kinda stuck WRT to the new stuff around QoS 16:33:52 zhiyan: thank you 16:34:22 kmartin: the onslaught of driver/bug's changes would be highly annoying and subject to all sorts of problems IMO 16:34:28 kmartin: but that being said 16:34:43 jgriffith: ok, it is pretty late so I can wait and do it in Icehouse 16:34:44 kmartin: let's get an update from winston or get it in our selves and go from there 16:34:53 jgriffith: ok 16:34:53 jgriffith: did you have any thoughts about brick? 16:35:02 dosaboy, what about brick ? 16:35:15 you mentioned you had spome concerns and wanetd to review where it was going? 16:35:16 kmartin: I'd like to get a gauge on everybody's needed activity on that once we have the client changes in 16:35:18 How about somebody defining it. 16:35:34 ah yes, that was my todo last week wasn't it. 16:35:35 d'oh 16:35:40 hemna: so i'm planning to add some rbd bits to brick 16:35:52 caitlin-nexenta: shared library of commone block storage related functions 16:35:54 sounds good, I think only a few drivers actually support QOS 16:36:07 but I understand that we want to avoid brick becoming a holdall for everybodies common driver code 16:36:12 jgriffith, initiator and target right ? 16:36:24 dosaboy: yeah, which is what people are rapidly trying to do 16:36:28 dosaboy, correct, it's not a driver repository 16:36:30 hemna: yes 16:36:37 hemna: and base LVM functionality 16:36:38 is brick part of cinder or a separate library (and is it used in other projects (nova, etc)) 16:36:46 jgriffith: that's a non-definition. *which* common functions? With that definition you should call it "kitchen sink" 16:36:50 part of cinder right now that will be a lib for I 16:36:58 nod 16:36:59 med_: afaik brick is intended to become an exportable lib 16:37:00 caitlin-nexenta: it is a definition, you just don't like it 16:37:10 everybody hold up for a second.. 16:37:18 So the idea was/is simply this: 16:37:26 * dosaboy digs out a bp 16:37:33 Currently there is a bunch of duplicate code between nova and cinder 16:37:55 This duplicate code I'm referring to is around handling initiators and targets in iscsi 16:38:03 as well as connection code for FibreChannel etc 16:38:18 In addition, both Nova and Cinder do a good deal with LVM 16:38:38 One aspect of Brick was intended to consolidate those things 16:38:49 NOT for everybody to put their driver in brick 16:39:00 jgriffith, hemna: so right now I have https://blueprints.launchpad.net/cinder/+spec/add-rbd-support-to-cinder-brick 16:39:07 it is looseluy defined 16:39:16 i see there is a ne task in there too 16:39:35 but basically, since rbd support is now in nova + glance + cinder 16:39:49 dosaboy: yes, that would make it a candidate here 16:39:54 i think there is defo scope for some common rbd code going int 16:39:59 good good 16:40:23 my eventual plan is to take the kvm libvirt volume driver code and put them all as connectors in brick 16:40:23 dosaboy: but this has become a bit muttled and we need clearer distinctions and long term goals 16:40:30 I have iscsi and FC now 16:40:34 * dosaboy has yet to actually find a chance to code it 16:40:44 i hope to have something proto'd by I 16:41:03 hemna: nod 16:41:25 We'll regroup on this at the summit by the way 16:41:34 Some drivers getting into brick will create an incentive for all drivers to get their code their as well. A utility library should be driver neutral. I'm seeing far too much about LVM and RBD. 16:41:52 caitlin-nexenta: do you have a copy of your driver in Cinder and in Nova? 16:42:22 caitlin-nexenta: I agree with you 16:42:33 caitlin-nexenta: rbd is actually a protocol not just a driver 16:42:34 The original would still be in nova, but we've been updating in Cinder. 16:42:46 caitlin-nexenta: original? 16:42:49 which is natively supported alongside iscsi in some hypervisors 16:42:53 caitlin-nexenta: what are you talking about there? 16:43:13 dosaboy: but there's a better/different way to handle that IMO 16:43:21 Actually I'm not sure if it is still there. There was a nexenta driver in nova-volume before Cinder. 16:43:25 jgriffith: pray tell 16:43:28 caitlin-nexenta: it's not 16:43:37 caitlin-nexenta: we did what was called a volume-ectomy 16:43:56 heh 16:43:59 ok, it would still work - but it's nice not to have to worry about it. 16:44:02 all of the block device drivers were removed from Nova 16:44:07 caitlin-nexenta: it woudl not 16:44:16 *sigh* 16:44:26 caitlin-nexenta: the Nova code has been completely redone 16:44:27 anyway 16:44:30 Ok... 16:44:36 Here's my take for now: 16:44:41 NO drivers go in brick 16:44:43 period 16:44:51 +2 16:44:52 jgriffith: +3 16:45:02 connectors, helpers etc we'll address as needed 16:45:12 agreed 16:45:21 And those should be defined in ways that are driver neutral. 16:45:50 caitlin-nexenta, they already are, so I'm not sure what your complaints are about at this point. 16:46:07 next topic ? 16:46:20 caitlin-nexenta: brick is not designed to be driver neutral... it is a place for useful common code, not a place that many drivers need to touch 16:47:19 ok I think we're done for now 16:47:22 THen why isthe title "Add RBD support to cinder brick" 16:47:23 no need to rat-hole 16:47:25 anngentle wanted us to see if anyone was going to write docs for volume encryption 16:47:38 caitlin-nexenta: who cares, it's not approved, it's not implemented 16:47:45 it is a bad title 16:47:47 caitlin-nexenta: let's not worry about things that don't currently exist 16:47:56 ok 16:48:06 DuncanT-: +1 by the way 16:48:07 Ok 16:48:13 let's adjurn 16:48:24 so much for the 15 minute meeting I had envisioned :( 16:48:30 #endmeeting cinder