15:00:17 #startmeeting manila 15:00:18 Meeting started Thu Jul 13 15:00:17 2017 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:21 The meeting name has been set to 'manila' 15:00:25 hi 15:00:26 Hi 15:00:27 hello all 15:00:28 hello 15:00:29 \o 15:00:31 @! 15:00:31 <_pewp_> jungleboyj (=゚ω゚)ノ 15:00:40 hi 15:00:42 omg the bot is here 15:00:42 hello 15:00:48 hello o/ 15:00:50 hi 15:00:52 hah! 15:00:56 @! 15:00:56 hi 15:00:56 <_pewp_> gouthamr (^-^*)/ 15:01:28 #topic announcements 15:01:49 first, a reminder that the Pike feature proposal freeze is TODAY 15:02:32 so anything new after today will automatically get punted to queens 15:02:47 we have more than enough work left to wrap up pike.... 15:03:12 and that's most of what I wanted to talk about today 15:03:18 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:03:28 #topic feature freeze 15:03:46 #link https://launchpad.net/manila/+milestone/pike-3 15:04:02 there's still a bunch of work that needs review for pike-3 15:04:12 I'm in the process of getting launchpad in shape 15:04:30 hi 15:04:38 o/ 15:04:40 if you see anything missing on launchpad pls notify me 15:05:25 I'm sure I didn't get everything yet, but I prefer using launchpad to track priorities so we know how close we are to being done 15:05:26 bswartz, can you change "Add messages resource for sending errors to users" to "needs code review"? 15:05:38 jprovazn: +1 15:05:42 done 15:05:45 thanks 15:05:56 IMO the IPv6 stuff looks good 15:06:24 I missed a flake8 check on my last patch but I'll sort that out shortly 15:06:39 I'd like to merge the LVM multi-IP patch, then the IPv6 core patches 15:06:56 there will be microversion conflicts of course 15:07:15 please stay on top of microversion-conflict-related rebases the next 2 weeks 15:07:23 yeah, agreeing on an order for stuff we expect to merge may help reduce thrash 15:07:28 they're annoying but unavoidable 15:07:37 I agree that the ipv6 stuff is very close 15:07:47 +1 15:07:59 tbarron: using constants makes rebase a lot easier 15:08:11 ganso: ack 15:08:14 ganso: what do you mean? 15:08:42 bswartz: define a constant with your change's microversion and use it everywhere you would put your microversion 15:08:55 ganso: for example? 15:09:14 bswartz: cknight did that with revert from snapshot patch 15:09:16 it sounds like a reasonable idea, but it would be tough to get it right for clients and tempest too 15:09:17 ganso: do you have a review with this "best practice" for us to look at 15:09:35 tbarron: I'll look for it 15:10:10 that said, if we merge the ipv6 stuff, then can we do the next one on the list next, etc. 15:10:19 it may help to co-ordinate efforts 15:10:49 of course if a reviewer has blocking objections, then we move the item to the end of the list 15:11:05 but for nits and small issues keep the order the same 15:11:23 reduce brownian motion 15:12:30 looks like we might need to add an agenda topic based on the channel discussion 15:13:08 so I'm going to make another pass at the launchpad milestone blueprints and bugs 15:13:17 tbarron: ganso Would like to see Cinder go that way too. 15:13:18 when I think it's complete I'll post something in the channel 15:13:29 Had a todo to push that but it fell off my plate. 15:13:48 Hi, we're writing the Infinidat driver. Is it realistic to push it to Pike or will it have to wait for Queens? 15:13:48 anything else related to the feature freeze? 15:14:35 amito-infinidat: where is the patch? 15:14:47 amito-infinidat: Could you give us a link? 15:14:57 tbarron, bswartz, jungleboyj: https://github.com/openstack/manila/blob/master/manila_tempest_tests/common/constants.py#L60 15:15:15 tbarron, bswartz, jungleboyj: although, my memory failed me, cknight did that only for tempest tests 15:15:33 we will create a review today or tomorrow 15:15:33 ganso: ty 15:15:45 amito-infinidat: in that case you missed this deadline: https://releases.openstack.org/pike/schedule.html#p-manila-nddeadline 15:15:47 ganso: with this change, you still need to update the patch though, but it will be just one place 15:15:56 tbarron, bswartz, jungleboyj: but the idea is great to be used in the server code and minimize rebase effort 15:16:14 amito-infinidat: we'll be happy to consider that driver for queens 15:16:14 bswartz: ok, so queens it is. 15:16:47 ganso: ++ 15:17:19 okay let's move on 15:17:34 #topic driverfixes 15:17:48 gouthamr created the new branches for us 15:18:00 bswartz: Could you tag two bps to pike-3 : link: https://blueprints.launchpad.net/manila/+spec/share-usage-size https://blueprints.launchpad.net/manila/+spec/ensure-share 15:18:02 but everything seems to be failing 15:18:07 https://review.openstack.org/#/c/482785/ needs to merge 15:19:16 gouthamr: looks like someone forgot to his the workflow button 15:19:24 maybe we should poke the infra team 15:19:51 bswartz: yep will do 15:20:03 bswartz: maybe they are waiting for you the PTL to +1 before +A? 15:20:43 xyang2: good point I added my +1 15:20:49 xyang2: no, it was required for branches creation 15:21:20 anyways once those branches are functioning we'll open them up to bug backports 15:21:33 gouthamr: as far as you know are any ACL changes needed? 15:21:49 who has power to +W stuff to driverfixes? 15:22:06 bswartz: not that i know about... all core reviewers have +2/+W : should it be only manila-stable-maint, or something like that? 15:22:22 well 15:22:33 it *should* just be manila-stable-maint, but we need to add people to that group 15:22:37 in cinder. all cores have +2/+w power on driver fixes branch 15:23:31 the theory is that the members of the stable-maint group have a good track record of approving appropriate backports and rejecting inappapropriate backports 15:23:44 the same logic would apply to driverfixes 15:24:42 gouthamr: do you want to push an ACL update or should I? 15:25:03 I can also take this as a reminder to add members to manila-stable-maint 15:25:03 bswartz: you can if you already know where it is 15:25:11 xyang2: Is it everyone? 15:25:16 #action bswartz add ppl to manila-stable-maint 15:25:24 #action bswartz update ACLs for driverfixes 15:25:24 xyang2: We didn't limit it to stable-maint? 15:25:44 jungleboyj: now you make me wonder. let me check.:) 15:25:50 bswartz: also, should third party CIs run on the driverfixes branches? 15:25:57 bswartz: devstack can likely be broken, so, i think not. 15:26:19 gouthamr: No, the shouldn't. 15:26:27 gouthamr: I think it would be recommended but not required 15:27:01 if you're not testing your changes then nobody will have confidence in them 15:27:12 afais, vendor driver fixes must be limited to their driver and they should attest that it's qualified downstream, because we don't run tempest tests upstream.. 15:27:21 but it's understood that testing obsolete branches is harder 15:28:31 anything else on driverfixes 15:28:32 ? 15:28:41 nope... nothing from me 15:28:44 gouthamr: thanks 15:28:54 once we fix the jenkins issues, i will update 15:29:11 #topic docs migration 15:29:32 so those of you reading the ML are aware of the effort to migrate docs 15:30:10 evidently it's related to the docs team having reduced resources 15:30:22 we were ahead of our time with our local docs :D 15:30:34 tbarron: You lucky dogs! 15:30:55 jungleboyj: well, we still have to move the official stuff 15:30:56 well isn't there anything left to do? 15:31:18 bswartz: I was (mostly) joking. 15:31:22 there is.. we have to move admin docs 15:31:24 I'm looking for a volunteer to work on this 15:31:26 and CLI docs 15:31:41 where would we move the CLI docs to? 15:31:48 to python-manilaclient? 15:31:50 and config ref (?) 15:32:06 and driver config docs? 15:32:22 bswartz: Yes, that is where the cli docs are supposed to go. 15:32:22 jungleboyj: didn't you do this for cinder? 15:32:33 tbarron: I am in the process of doing it. 15:33:10 #link: https://review.openstack.org/#/c/472275/ 15:33:36 what is the deadline? 15:33:41 tbarron: Trying to hint I could do it for Manila as well? 15:33:46 Needs to be done in Pike. 15:34:08 jungleboyj: maybe I can just look at each of your patches and make a corresponding one for manila then 15:34:19 it might happen very late in Pike for Manila 15:34:28 jungleboyj: Pike l3 or later? 15:34:42 bswartz: all NOTE that cinder has agreed that the 'move doc' patches don't have to *fix any content* 15:34:46 jungleboyj: if you don't want to work on it for manila maybe you can give advice to whoever does do it 15:34:58 zhongjun: Before code freeze. 15:35:04 so no -1s and nitpicks on content, or fix this while you are in there 15:35:12 tbarron: ++ 15:35:17 * gouthamr tbarron: uh-uh, noway 15:35:23 jungleboyj: the P-3 milestone? 15:35:23 :P 15:35:38 jungleboyj: is the before code freeze an OpenStack requirement or a cinder goal? 15:35:39 This is just to get the move. 15:35:47 that's unfortunately close and conflicts with stuff we actually care about 15:36:11 tbarron: Well, the docs are gone from the web right now. 15:36:11 why not do it after the milestone? 15:36:22 Oh, you know what ... 15:36:41 These get published independent of a milestone I think. 15:36:51 So maybe code freeze doesn't matter. 15:36:58 I would rather do it around the RC1 timeframe 15:37:01 jungleboyj, bswartz: so I can +2/+A on cinder's driver fixes branch but I'm not a stable maintenance core: https://review.openstack.org/#/c/464311/ 15:37:11 that's the traditional time for us to switch focus to docs problems 15:37:25 The docs meeting is right after this. I will get clarification. 15:37:55 okay I just wanted to call attention to this community wide goal 15:38:14 okay let me sneak in some topics not on the agenda 15:38:23 #topic bug squash day 15:38:29 tbarron: So are you going to look at doing the migration? 15:38:59 we discussed this 2 weeks ago and there was interest but nobody has indicated what times wouldn't work for them 15:39:00 jungleboyj: i am happy to copy your fine work if I don't have to do it for P-3 15:39:30 Ok. I will get clarification on the timing. Am here to support. 15:40:07 tbarron: yeah I think we'll all be too busy to do it before P-3 -- if there's a deadline then we will probably miss it 15:40:33 regarding bug squash day, I'd like to propose R-4 (the first week in August) 15:41:04 I know that's likely to conflict with people's vacations, but the backend of pike is fairly compressed 15:41:19 bswartz: unfort I have company meetings all that week but that shouldn't block others 15:41:22 the only realistic alternative would be R-3 15:41:42 but that's even more likely to conflict with vacations 15:42:27 so I hear tbarron is out for R-4 15:42:46 anyone else have a strong opinion for when we should plan a bug squash day? 15:42:57 the other question would be what day of the week 15:43:07 I would avoid monday and friday 15:43:30 maybe Wednesday is a good day for it? 15:43:34 bswartz: wait, r-4 is july 31-aug 4, it's r3 that I have to travel 15:43:48 so August 2 or August 9 15:44:15 August 2 would be better 15:44:28 and if that works for tbarron and nobody else objects, I'd like to just schedule it today 15:44:45 bswartz: +1 15:44:54 #link https://releases.openstack.org/pike/schedule.html 15:45:44 alright put manila bug squash on your calendars for August 2nd 15:46:12 #topic per-share-type quotas 15:46:28 hee hee 15:46:29 #link https://review.openstack.org/#/c/452158/ 15:46:40 #link https://review.openstack.org/#/c/452158/32/manila/api/v2/quota_sets.py@84 15:46:57 what's going on here 15:47:03 gouthamr vponomaryov 15:47:35 bswartz: gouthamr proposed me to change API behaviour and I disagree with it 15:47:41 * tbarron imagines bswartz as ward cleaver 15:47:50 the conversation is here: https://review.openstack.org/#/c/473464/11/manila/api/v2/quota_sets.py 15:48:02 tbarron: lol 15:48:03 vponomaryov: what is the choice that needs to be made? 15:48:11 whether to modify old API behavior or not? 15:48:25 It looks like we meet the same problem before ( export location feature) 15:48:28 tbarron: sorry I didn't watch that show 15:48:37 bswartz: it is related to "drop-garbage-by-default" approach we have in API 15:48:47 so the patch modifies old APIs for the new quota set key 15:49:04 if you use the new quota set on old APIs you get a 400 15:49:10 so the patch could theoretically break backwards compatibility, right? 15:49:15 bswartz: new change updates old APi to explicitly say that "new keys" are not allowed with old API 15:49:24 but in practice, would it? 15:49:51 my problem was with special casing 15:49:53 I'm less concerned about theoretical backwards compatibility issues than real ones 15:49:59 as zhongjun mentioned, we handled this in both the export_locations_filter and the "like" filter that she added 15:50:10 bswartz: keeping old behaviour will mean following: operator will provide new keys with old API and will get answer, not knowing it was not applied 15:50:19 that's why I take a strong stance that bugfixes shouldn't be microversioned unless the old behavior was desirable in some way 15:50:46 bswartz: so, yes, it is part of fixing "drop-garbage-by-default" approach 15:51:03 yes, we discussed it in last meeting 15:51:06 that should have been done tillnow 15:51:26 so I'm leaning towards supporting vponomaryov's patch as is 15:51:37 gouthamr: explain the harm with this approach 15:51:56 why apply special case fixes every time we introduce a new feature? 15:52:20 gouthamr: because we don't drop garbage now 15:52:21 gouthamr: you'd prefer that the change be to to reject ALL unsupported arguments? 15:52:22 i agree we were consuming garbage and ignoring it, which is very confusing 15:52:26 bswartz: yes 15:52:29 gouthamr: itis driven by technical debt 15:52:33 yeah I'd prefer that too... 15:52:35 bswartz: In last meeting, we agree with open a new bug to change this behavior and add microversion 15:52:40 bswartz: at a new microversion, we can prevent sending garbage keys 15:52:42 still I don't see why that's related to this 15:52:51 for now, just pop the key and log it if you must 15:52:56 it's an admin API 15:53:25 if you send a 400, you'll only confuse consumers.. 15:53:30 it's an admin API but vponomaryov has a good point that admins could easily make a request and get confusing results 15:54:23 this would be a non-issue if we were rejecting garbage originally 15:54:28 yes 15:54:31 gouthamr: as bswartz mentuioned, we should not keep backwards compat with "bugs" 15:55:20 vponomaryov: would you consider modifying your patch to reject all garbage starting with the new microversion? or would that be siginificant extra work? 15:55:52 bswartz: I would say that it should be done separately 15:55:56 bswartz: not in this patch 15:56:01 I don't want to block this patch on a minor issue like this, but if we split out the change and create an additional microversion then it's even more confusing 15:56:17 bswartz: here, I considered operator use case beforehand 15:56:34 vponomaryov: if we do it separately, would that other change be microversioned, or would it be retroactive? 15:57:15 bswartz: since, it will be bugfix that changes old behaviour... 15:57:38 you'd want to affect all old microversions? 15:57:59 my concern if we do it that way is that there might be legitimate backwards compatibility problems 15:57:59 bswartz: I don't have strong opinion on this 15:58:33 changing 2xx to 4xx: reason for a microversion bump.. 15:58:55 well I think we've agreed that this needs fixing, but nobody has time to work on that and it's not a good enough reason to block this new feature 15:59:50 i don't mind committing this change in another patchset 15:59:56 I'm in favor of merging the feature as it, and then separately changing the API to start rejecting garbage, possibly only after some microversion or possibly retroactively (need to think about specific cases where backwards compatibility would be broken) 16:00:07 bswartz: only on restricting "valid keys" from new microversions on OLD ones 16:00:28 can everyone live with that? 16:00:51 we're out of time so please raise your objections in the channel 16:00:57 thanks everyone 16:01:02 #endmeeting