16:00:55 #startmeeting cinder 16:00:56 Meeting started Wed Mar 18 16:00:55 2015 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:58 hi! 16:00:59 o/ 16:00:59 The meeting name has been set to 'cinder' 16:01:02 Hi 16:01:02 hi 16:01:03 Hi 16:01:05 Hi 16:01:05 o/ 16:01:09 \o 16:01:11 hi 16:01:12 hello all! 16:01:14 hi 16:01:16 o/ 16:01:19 hi 16:01:29 0/ 16:01:31 some usual announcements 16:01:34 mep 16:01:39 Third party ci 16:01:42 #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html 16:01:42 hello 16:01:47 hi 16:01:51 Tomorrow is the last day 16:02:02 hi 16:02:02 hellop 16:02:05 hello 16:02:08 hi 16:02:12 o/ 16:02:12 I will begin WIP patches that remove drivers out that have not responded back to me 16:02:21 boom 16:02:37 I think my favorite part is the 32 links included for reference :) 16:02:40 Ok. 16:02:54 jgriffith: just to cover my ass more or less 16:02:58 ;) 16:03:01 :) 16:03:02 thingee: roger that 16:03:11 so please talk to me 16:03:20 it's better to talk to me than be silent about the ci deadline 16:03:23 I will work with people 16:03:33 looks like a few CIs are missing from the wiki page 16:03:42 I will also be posting later today on the dev ML my report of all drivers of who is reporting 16:03:48 some that are already reporting 16:03:58 thingee, do you have a page of the drivers that haven't replied yet ? 16:04:09 page/doc/public list ? 16:04:11 thingee: #infra will take care about opensource drivers, is that still correct? 16:04:21 hemna: I have a spread sheet, but it's out of date from eight emails I recieved just this week ;) 16:04:30 hemna: would like to update that before people get all up in arms about it 16:04:43 probably should make that public ? 16:04:50 hemna: +1 16:04:54 hemna: I just said that earlier 16:04:57 ok sorry 16:05:05 09:03:42 thingee | I will also be posting later today on the dev ML my report of all drivers │ andreykurilin 16:05:07 still ingesting coffee this a.m. 16:05:07 | of who is reporting 16:05:13 my bad 16:05:29 ok, also deadlines 16:05:37 #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056964.html 16:05:41 we're past new proposals 16:05:52 thingee: ? 16:05:55 Been still getting them. I've been giving them a -2 and I recommend everyone else to do the same 16:06:03 andreykurilin: my mistake in copy/paste 16:06:09 andreykurilin: sorry 16:06:13 np:) 16:06:25 we're just accepting bug fixes at this point 16:06:46 If you need to know what to review 16:06:49 go here https://wiki.openstack.org/wiki/Cinder#Review_Links 16:06:58 click the cinder review inbox link 16:07:05 and review the group that is bug fixes 16:07:18 should greatly help in filtering what to review 16:07:23 alright lets get started! 16:07:24 is tomorrow the last day for bug fixes? 16:07:35 rhe00: oh yes thanks for reminding me 16:07:55 so I have a question about a patch that really seems like a continuation of the new objects feature 16:08:00 https://review.openstack.org/#/c/161077/ 16:08:01 that guy 16:08:07 rhe00: so I will be doing a cut at some point tomorrow. Hoping to not be late. Please lets work together on get our bug fixes through. 16:08:20 I'm not sure that should get in 16:08:22 I'm really relying on folks to help because I got a few security issues on my plate atm 16:08:26 unless something is broken w/o it 16:08:31 hemna: good question 16:08:54 I think it should get -2 unless others object 16:08:55 hemna: I don't think it should go in either 16:09:01 ok 16:09:01 hemna: it's just finishing the snapshot api 16:09:21 ok lets get started! 16:09:30 ok done. 16:09:30 :P 16:09:37 agenda! 16:09:40 #link https://wiki.openstack.org/wiki/CinderMeetings#Weekly_Cinder_team_meeting 16:09:54 hemna: thingee WRT to the objects.... 16:10:06 hemna: thingee I'd like to at least think about it if we could 16:10:18 thingee: Sorry, jsut want to clarify. We are taking bug fixes beyond tomorrow. Correct. 16:10:22 hemna: thingee we're in a funky place right now with a bunch of 1/2 in 1/2 out stuff 16:10:34 jgriffith, well yah that's why I was questioning it 16:10:42 if stuff is broken w/o this getting in.... 16:10:45 I can remove the -2 16:10:48 hemna: thingee some object, some taskflow etc 16:10:54 but it seems like a significant change at this point 16:10:58 hemna: well I don't think there's anyting "broken" 16:11:09 jgriffith: my only concern is how many bugs have been popping up with the object stuff. Just worried about stuff getting in the release. 16:11:10 hemna: but I hate having such inconsistency in our code base 16:11:19 hemna: and blocking progress for a month or so 16:11:22 sounds like we might have to revert back entirely? that might be sad though. 16:11:29 thingee: only a couple right? 16:11:32 bugs that is 16:11:36 jgriffith, yah I get that too. 16:11:51 and actually I think the default getter solved any issues I've seen 16:11:57 jgriffith: have they been mostly in drivers? Accept my apologies, I have been just observing the surface of what's reported. 16:11:58 anyway... just wanted to throw it out there 16:12:17 I can remove the -2 if you want 16:12:21 thingee: yeah, just drivers but I think my add will keep that from happening 16:12:26 I'm just concerned about the changes it makes now 16:12:34 thingee: so it's up to you all... I just wanted to throw it out there 16:12:42 thingee: hemna if you guys think there's risk no worries 16:12:44 jgriffith: ok, that's fair 16:12:45 we can wait 16:13:13 I was under the impression we were hitting problems left and right, but if it's just drivers, we should be paying attention to the CI's right? 16:13:20 Which I think erlon brought up on the ML 16:13:33 thingee: well, maybe I'm misinformed 16:13:49 thangp: can you comment on the number of bugs that have been reported :P 16:13:53 ok... ignore what I said :) 16:14:02 thingee: I think we fixed mose of them 16:14:18 thingee: and it was minor stuff, like getattr 16:14:30 which jgriffith said his patch would take care of 16:14:37 thangp: I have not seen anything major 16:14:38 from preventing future problems 16:15:01 thingee: correct, jgriffith patch fixed that 16:15:11 fixed or is going to fix? did it already land? 16:15:21 thingee: landed 16:15:22 thingee: already landed and fixed it 16:15:24 while ago 16:15:28 jgriffith: oh ok 16:15:47 thingee: which other bugs have there been? 16:16:21 thingee: maybe we should tag them under "objects" or something to make it more identifiable 16:16:23 hemna, jgriffith: If it leaves us in a half state and makes things bad for us that we would have to revert everything that's already merged, perhaps we can consider letting this merge if we're certain we won't have regression in drivers. 16:16:42 hemna, jgriffith: do you mind if I leave it to you two for merge consideration today/tomorrow? 16:16:43 thingee, yah 16:16:52 it has a dep patch that needs to land first 16:17:39 jgriffith: ? 16:17:52 the dep patch looks like a bug fix 16:17:53 thingee: yeah, that's fine 16:17:55 I can review it today 16:18:20 #action hemna and jgriffith to consider merging snapshot object patch 16:18:23 thanks guys 16:18:26 ok cool 16:18:32 #topic Modifying existing migrations 16:18:34 DuncanT: hi 16:18:41 #link https://review.openstack.org/#/c/159854/ 16:18:42 Hi 16:19:07 So we've had a long standing policy of not changing old migrations 16:19:20 For the simple reason that some people might have run them 16:19:21 DuncanT: is that the right link in the agenda? 16:19:34 this looks like the utc change 16:19:51 The UTC change makes some functional changes to migrations 16:20:10 3 of them 16:20:27 DuncanT: got it 16:20:28 we could leave as is, but need to add a comment why it is not changed 16:20:49 and do not allow using not utc time in future migrations 16:20:56 e0ne: Makes sense. '#noqa' should stop the hacking check from puking too 16:21:12 DuncanT: +1 16:21:21 patch needs a rebase at least 16:21:37 #info DuncanT thinks this looks fine, but needs more eyes 16:21:38 i prefer to change only functional parts in migration 16:21:46 I'm not sure it actually causes any functional problems, but certainly we've been bitten by this sort of 'safe' change before, so I'd prefer to err on the side of safety 16:21:59 we should not allow to chage data format in old migrations 16:22:02 we don't need to land this in k3 right? 16:22:11 can we let this sit in gate l-1? 16:22:21 It would be better to land it 16:22:24 It is a real bug 16:22:28 i thought it was volume migration... 16:22:31 DuncanT: we don't store timezone so it shouln'd break anything 16:23:41 e0ne: I *think* the change is safe, I'm just not sure 16:24:14 winston-d_: :) 16:24:14 DuncanT: i've got your point. if it's not, we definatly should fix granade job 16:24:33 * thingee is going to say anything with schema migrations and time change this late is scary. 16:25:07 e0ne: So leave it and #noqa in the migrations? 16:25:25 DuncanT: that is my point 16:25:55 https://review.openstack.org/#/c/159854/12/cinder/db/sqlalchemy/api.py should be landed, I think, it solves a real bug 16:26:12 e0ne: Ok, I'll update the review 16:26:37 DuncanT: can we just have that piece then? This will look weird after upgrade? 16:27:02 separate patch just for that guy ? 16:27:13 DuncanT, is there a bug for that one specifically ? 16:27:14 thingee: If we drop the 3 migration changes, the rest are just unit test cleanups - I'd rather merge them and get the hacking check in 16:27:16 hemna: just of the sqlalchemy/api.py part 16:27:22 thingee, yah 16:27:51 sounds fine to me. 16:27:52 https://review.openstack.org/#/c/159854/12/cinder/volume/drivers/zfssa/zfssanfs.py might or might not result in a real bug, I haven't looked 16:28:06 DuncanT: still curious on upgrades though 16:28:07 Any reason not to fix up the unit tests too? 16:28:18 should be ok no ? 16:28:36 I'm asking because I think you'll have some entries wit UTC and others aren't 16:28:41 thingee: On upgrades, you just get a weird value in the the db... harmless I think 16:29:04 thingee: The timezone doesn't seem to be stored in the db 16:29:16 anyone else have concerns? 16:29:46 DuncanT: you're rigth. and the default value for datetime fields is datetime.utcnow() 16:29:49 So, entries in the DB would not be UTC before the upgrade? 16:29:53 thingee: not yet :) 16:30:06 I would prefer this not go in K-3, mostly because there are unknowns it seems and would like this to sit in gate. 16:30:36 Missing k-3 is fine, missing the release is not IMO 16:30:49 We've had this bug for a while, so it can't be /that/ major 16:30:53 DuncanT: by definition you miss K3 you miss release 16:30:54 thingee: +1 16:30:56 DuncanT: can't promise an RC though. 16:31:13 If we get it in now we have plenty of soak time no? 16:31:31 especially if we're "looking" at it 16:31:45 I suppose this would be a reason to do an RC if we notice issues :) 16:31:54 I just really want to know what happens with upgrades. 16:32:27 is there a possibility there will be no RC ? 16:32:42 jbernard: sure in a perfect world. 16:32:42 thingee: by default, our models use utc timezone. current migrations use just datetime.now() 16:32:44 jbernard: not really. :) 16:32:51 jbernard: There's always one I think 16:33:06 jbernard: the real question is can you have "only one" :) 16:33:20 ok lets go ahead and merge it today. soak, revisit in RC. 16:33:41 I'll update it not to change the migrations and rebase 16:33:49 Should be done shortly 16:34:01 DuncanT: anything else? 16:34:30 Nope, thanks 16:34:32 #topic Non-eventlet WSGI endpoint for cinder-api 16:34:34 e0ne: hi! 16:34:37 e0ne: +1000 16:34:42 thingee: hi 16:34:46 #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/057359.html 16:34:54 #link https://review.openstack.org/#/c/142659/ 16:34:59 one comment form my side 16:35:16 it is not about _removing_ eventlet from cinder-api 16:35:35 it's about addine one more option how could we deploy it 16:36:05 #info this is not about removing eventlet from cinder-api, this is adding another option for deploying 16:36:07 DuncanT: pointed to me that it requires more tests for CI. I think we could do it in infra 16:36:20 e0ne: I can understand why keystone choose not to use eventlet, given the history 16:36:26 thingee: do we need more options :) 16:36:42 thingee: especially ones we won't test? 16:37:00 this makes sense for keystone, they have a different problem to solve 16:37:07 jgriffith: we will test it on gates, i hope 16:37:12 trying to figure out what's in it for us, so to speak 16:37:14 e0ne: but any real benefit adopting apache? 16:37:31 e0ne: I dunno... look at ZMQ and other things like that 16:37:38 morganfainberg: ^ 16:37:39 e0ne: test cinder with apache? 16:37:45 winston-d_: we've got process launcher now 16:37:59 wouldn't be so sure it'll get tested... but still leaves the main question from me: "What's in it for us" 16:38:04 winston-d_: and we need to use haproxy or something else 16:38:26 e0ne: yes, i am well aware of that, so you were saying we should test multi Cinder workers in gate? 16:38:29 winston-d_: apache/nginx + wsgi could be an option for deployment 16:39:04 e0ne: is it a *better* option? 16:39:06 winston-d_: it could be configured by devstack and we'll add new dsvm job 16:39:39 jgriffith: we could test performance in our case 16:39:39 e0ne: you want apache/nginx option 'cos it works better with haproxy? 16:39:42 e0ne: don't get me wrong, I wouldn't be sad to see eventlet replaced, but that's if it can be replaced :) 16:40:09 winston-d_: ahhh.... that's the kind of thing I'm looking for 16:40:16 jgriffith: i'm talking only for wsgi app for cinder-api 16:40:41 e0ne: yes, i'd like understand the pros/cons 16:40:43 e0ne: hehe.. yeah, you prefaced the conversation with that and I ignored you :) sorry 16:41:18 either way this is after L opens up right... so I think we can talk more later or try some stuff 16:41:32 probably not wort me rat holing on the details today :) 16:41:36 wort 16:41:45 #info have apache/nginx so cinder-api works better with haproxy 16:41:55 ARRRR H key popped out again!! 16:42:01 * jgriffith needs to get a new keyboard today 16:42:01 :) 16:42:04 jgriffith: +1 16:42:10 thingee: well, that's a question from me... 16:42:18 e0ne: is that true or not? 16:42:30 jgriffith: vim without an "h" is _ard, right? 16:42:32 winston-d_, thingee: it depends 16:43:00 flip214, :) 16:43:05 apache/nginx has more users than haproxy 16:43:11 e0ne: so i need some education here, i appreciate if you can give me some pointers 16:43:14 flip214: Exactly!!! 16:43:20 thingee: I need to step away. Just a quick question. 16:43:37 I'm going to assume that e0ne will have give a better arguement of why he wants to see this option in the spec. 16:43:41 so we could get more happy users to deploy it 16:44:04 there doesn't seem to be a reason give atm 16:44:09 given* 16:44:11 thingee: sure, i'll do it. could you please crate an action itom? 16:44:14 *item 16:44:48 #action e0ne will create a spec that gives the actual reasons why a user would want another option for deploying cinder-api 16:44:59 thingee: thanks 16:45:06 e0ne: anything else? 16:45:27 jungleboyj: I'll circle back to your topic 16:45:32 thingee: thants all. i've got early feedback and could continue to work on it 16:45:43 #topic Bugs triage 16:45:45 e0ne: hi 16:45:47 thingee: Ok, I actually need to leave. So if you can just discuss it and I will catch up later. 16:45:53 Thanks. 16:45:53 jungleboyj: k! 16:46:01 thingee: hi :) 16:46:11 i want just to remind all to do it 16:46:25 so bug triage. I've been behind actually all this month. my bad 16:46:25 i'm going to spend next day for it 16:46:27 did anybody else see the "quick question" ? 16:47:04 Oh.. guess it's the question that he posed on agenda.... or thingee is psychic :) 16:47:07 no, only the remark about the question 16:47:12 physic 16:47:14 BAHHHH 16:47:17 imo, 135 new bugs is too big number 16:47:23 thingee: theres one more bug we would like to get in in this release, have created a bug, but not sure if it falls in any criteria to get it reviewed: https://bugs.launchpad.net/cinder/+bug/1430782 16:47:24 Launchpad bug 1430782 in Cinder "Error on LUN creation on HNAS iSCSI driver" [Undecided,In progress] - Assigned to Erlon R. Cruz (sombrafam) 16:47:47 e0ne: agreed. I was on top of this, but I had to step away earlier this month and do some reviews here and there. Had some personal issues that came up. 16:47:49 jgriffith, now the h key has moved? 16:47:55 jgriffith: psychic was correct, wasn't it? 16:47:56 although bug triaging shouldn't just be me :) 16:47:58 kmartin: LOL 16:48:02 flip214: yes 16:48:09 thingee: sure 16:48:27 sorry, gotta go. 16:48:36 thingee: whats about send notification to openstack-dev? 16:49:09 thingee: oh? 16:49:12 e0ne: if you want to send something to the ML, that's fine, but I don't think it's necessary. We're already full alert on bugs. I think I just need to get back to it, and maybe others can pitch in 16:49:24 thingee: a lot of newcomers should be imformed:) 16:49:35 So do we have to get all of those bugs fixed by K-3? 16:49:43 hemna: haha 16:49:51 or do we have leeway after for RC. 16:50:01 hemna: we never have in any release 16:50:07 I have one on my plate that I'm not sure I can get in by tomorrow. 16:50:14 ok, I just wanted to be clear :) 16:50:17 hemna: after RC we should fix onli high/critical bugs, shouldn't we? 16:50:18 hemna: I think what's important is at least triaging and understanding if we blockers 16:50:33 thingee: +1 16:50:35 if we have blockers, bring it up in #openstack-cinder 16:50:44 if we have blockers* 16:51:24 btw, i have nothing to add to this topic. 16:51:31 e0ne: heh ok 16:51:52 so sure, I'll be doing some triaginag later in RC time frame. 16:52:00 bugs are always fair game 16:52:08 e0ne: you can send somethign out if you like 16:52:15 up to thingee and core to weigh impact of the fix 16:52:16 thingee: ok, i'll do 16:52:21 but never stop working on bugs 16:52:30 just right now top priority to me are issues bugs in k3 we know about and security bugs 16:52:32 * jgriffith thinks maybe that's why we have so many bugs 16:52:55 jgriffith: i know few openstack newcomers that don't now anything about bugs triage. 16:53:09 #action e0ne to email ML about bug triage in cinder 16:53:15 e0ne: o/ 16:53:23 #topic Liberty Specs 16:53:30 jungleboyj original proposed this 16:53:46 I really want us to have a use case section in sepcs 16:53:48 https://review.openstack.org/#/c/149449/ 16:53:48 Just say NO 16:54:07 not regarding use cases... regarding L specs until we get to RC 16:54:08 :) 16:54:19 Not accepting Liberty specs right now. Would like to get through the K release atm 16:54:19 jgriffith: +1 16:54:21 jgriffith: +1 16:54:22 jgriffith: RC or K-3? 16:54:23 jgriffith, you know what happened to that drug campaign, everyone ended up doing them. 16:54:23 heh 16:54:27 thingee: :) 16:54:29 thingee : about heirarchical multitenany do we have any plan for L release 16:54:41 jgriffith, +1 16:54:55 vilobhmm: if it's not security bugs in k-3, I don't know 16:54:57 jgriffith: I thought you were saying "No" to Liberty. :) 16:55:01 vivek-ebay: thingee I would like to work on that in L, or at least get it going 16:55:02 people could start working on it, but we'll give -2 without review 16:55:05 vilobhmm: sec bugs are top priority right now 16:55:13 thingee : sure 16:55:25 oops... vilobhmm ^^ 16:55:37 but we have other issues to iron out in L as well, replication, extra specs, nova -> cinder api issues, etc. 16:55:38 as you mentioned few weeks back got it 16:55:45 sure jgriffith 16:55:47 I'd like to get those solved before we start working on new cinder features 16:56:01 we seem to always churn on the new w/o solving some of our white elephants 16:56:04 hemna: agree 16:56:08 hemna: :) 16:56:11 hemna : +1 16:56:13 #topic Open discussion 16:56:22 I don't understand how there could be no RC 16:56:22 thingee: (a bit delayed) if you need help with wsgi (mod_wsgi etc) I can help or at least point you guys to resources in devstack and in the keystone tree for making it happen. 16:56:26 but that's just my take on it. 16:56:30 it's like ground hog day (the movie) 16:56:30 (12:30:56 PM) thingee: DuncanT: can't promise an RC though. 16:56:36 jgriffith, yup 16:56:38 bswartz: :) 16:56:39 "white elephants"? 16:56:39 Let me know when you're looking at it (or whomever is). 16:56:42 hemna: but i would like to get state machine or at least fault tolerance for all services in L 16:57:00 morganfainberg: I think we were trying to understand why Cinder would need. while it's understood for keystone's use case. 16:57:19 eone : +1 for fault tolerance; need to have it before adding more features i feel 16:57:22 morganfainberg: e0ne is proposing this right now, so he may reach out to you 16:57:26 e0ne, I would like a lot of stuff for L. it's up to the PTL really to help set the agenda...dunno. 16:57:41 I just would like to see others step up and help fix some of our existing known issues first. 16:57:43 hemna: agree, it's fair 16:57:56 but I'm one to talk....mr. multiattach. bleh 16:58:02 So for the api surface area, it allows Apache to manage the workers - and Apache does a good job of ssl termination. I can provide more details for e0ne when ready (down the line) 16:58:19 morganfainberg: thanks 16:58:23 (Also no greenlet bugs in Apache wsgi mode) 16:58:35 morganfainberg: thanks! i'll ping you 16:59:54 thanks everyone! 17:00:01 #endmeeting