15:00:45 #startmeeting manila 15:00:47 Meeting started Thu Nov 17 15:00:45 2016 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:51 The meeting name has been set to 'manila' 15:00:53 hi 15:00:57 hi 15:00:57 hello all 15:00:58 hello o/ 15:01:00 hello 15:01:01 hello 15:01:03 hello 15:01:20 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:01:26 hello 15:01:33 hi 15:02:01 hi 15:02:13 cknight markstur toabctl: courtesy reminder 15:02:33 #topic announcements 15:02:58 ocata-1 milestone is today 15:03:33 for us that means low-priority spec freeze, and I need to tag the current builds 15:03:56 more about specs in the next topic 15:04:10 #topic Spec review & prioritization 15:04:18 #link https://etherpad.openstack.org/p/manila-ocata-spec-review-focus 15:04:24 #link https://review.openstack.org/#/q/status:open+project:openstack/manila-specs 15:05:05 so out of the 9 specs on the etherpad we got 2 merged so far 15:05:19 plus some other low priority ones 15:05:31 yep 15:05:52 * bswartz notices a new spec from gouthamr in the last 5 minutes 15:06:34 bswartz: yeah.. Insight was unforgiving, so i couldn't finish it; the code's mostly done - spec writing's not 15:06:47 so first I'd like to say that I'm generally very happy with how the new specs process has been going 15:07:08 bswartz: if we tag it low-priority, can i ask for a spec-deadline-extension on that one? 15:07:16 we're finding issues in design now that in previous releases wouldn't have been caught until code review -- most likely a week or two before feature freeze 15:07:35 I still need some time to get used to this process 15:07:35 +1 15:07:47 all of the effort we've put into spec reviews seems like it's paying off 15:07:55 and I think having a deadline is a big part of that 15:08:33 now on the negative side, we have all these unmerged specs 15:09:05 according the process we agreed to, we should punt all of these out to pike 15:09:20 I have a question will this one get merged? https://review.openstack.org/#/c/390052/ it seems that most of us already agreed on it :) 15:09:24 I'm not very inclined to do that, but I'm not sure what to do instead 15:09:43 bswartz: is the deadline until midnight today? 15:09:46 last minute reviews? 15:09:59 tommylikehu_: yeah don't worry that one looks fine 15:10:06 thanks~ 15:10:39 well we don't have a hard cutoff -- this is the first time we've tried this and I didn't anticipate that we'd be at the deadline with 80% of our specs not merged 15:11:16 I don't want to encourage everyone to just madly +2A the remaining specs without giving them the attention they deserve 15:11:25 bswartz: +1 15:11:30 agreed 15:12:12 and I don't want to keep specs reviews open forever given that we only have 10 weeks (minus holidays) from now to feature freeze to do all this work 15:12:48 hi 15:12:51 we could grant a blanket extension of the deadline, but next week is american thanksgiving and several people will probably not be around 15:13:34 * bswartz won't be around the later half of next week 15:13:50 so what do you guys think? 15:13:52 I suggest we take one last look on the specs and judge if they are ready to be coded... some of the details might change when looking at the code and some specs might need to be updated 15:13:57 would a few more days make a big difference? 15:13:59 bswartz: what about next IRC meeting? 15:14:07 yes~ 15:14:16 vponomaryov: I intend to cancel next week's IRC meeting 15:14:32 too many US-based core team members 15:14:37 I am ok with it 15:14:58 bswartz: how much time do we have for specs from now? 15:15:14 vponomaryov: that's up to us 15:15:52 do you guys want to give the remaining specs until the end of today? until end of this week? sometime next week? 15:16:07 bswartz: what do you think of my proposal? 15:16:10 18 24:00 15:16:13 bswartz: today and tomorrow - definitely 15:16:22 bswartz: some of the specs only needs some "fine tuning" 15:16:37 I want to see more specs approved, but I feel like we need to have a cutoff 15:16:55 inevitably something won't get merged and the author of that spec won't be happy 15:16:58 bswartz: if we could focus ALL effort right now from everyone to take a last look and decide if it is worth merging or not, and if not, if it can be fixed by the end of the day, it would be good 15:17:05 bswartz: and if we want to continue working on specs that need more than just a couple tweaks, we need to declare them hi prio, right? 15:17:19 tommylikehu_: you're suggesting friday midnight? 15:17:27 yep 15:17:41 bswartz: it is already late for tommylikehu_ 15:17:43 according to the ocata scheduler 15:17:47 tbarron: that's an option but only if we really consider something high priority 15:18:41 I'm hearing that people want at least the rest of today 15:18:55 bswartz, why not until this weekend, then we'll have more time to go through these specs. 15:18:58 anyone disagree with 2 more days? 15:19:18 no 15:19:36 end of the week makes sense to me -- that way we avoid bumping into holidays next week 15:19:42 but still have time today and tomorrow 15:20:03 bswartz: so friday midnight? 15:20:15 bswartz: is goutham's spec exception? 15:20:45 midnight UTC is the traditional time 15:20:54 this sunday midnight 15:21:08 that's 7PM for me 15:21:57 tommylikehu_: I don't want to ask people to work over a weekend -- it's one thing if a submission deadline is set for sunday night/monday morning, but a merge deadline involves many people 15:22:32 vponomaryov: what's wrong with gouthamr's spec? 15:22:37 vponomaryov: I want to go over specs one by one in a moment 15:22:39 you are right 15:22:42 ganso: it's not complete 15:22:46 ganso: it has just been uploaded )) 15:22:58 the deadline is not right now, so, what's the problem? 15:23:11 and I think the IPv6 deserves more attention from all of us , I am not urge to merge it, only a suggestion as tbarron mentioned in comment 15:23:15 ganso: other specs already had some review 15:23:56 okay I'm not hearing lots of feedback but no one seems opposed to blanket extension of the deadline to friday midnight UTC 15:23:58 on a side note, I am unaware of anything preventing his spec from being designated hi-pri, as it was already called for last weekly meeting 15:24:37 tommylikehu_, don't worry, it's a high priority spec, we'll pay more attention to it. 15:24:52 zengyingzhe: ipv6 is not hi-pri, it is review focus 15:25:01 #agreed low priority spec merge deadline 18 Nov 23:59 UTC 15:25:20 ganso: maybe it should be 15:25:27 okay let's go over remaining specs 15:25:30 ganso: I thought all specs on https://etherpad.openstack.org/p/manila-ocata-spec-review-focus are high priority 15:25:39 tommylikehu_: then we would need to vote for it 15:25:41 xyang2: no 15:25:56 bswartz: then what are high priority specs? 15:25:59 xyang2: high priority is here https://github.com/openstack/manila-specs/blob/master/priorities/ocata-priorities.rst 15:26:09 xyang2, yep, that's what I thought too. 15:26:12 * bswartz kicks himself 15:26:28 I forgot to add the race condition spec there 15:26:47 bswartz: just scenario tests? 15:26:55 xyang2: and race conditions 15:27:05 i think the diff between high prio and review focus was pretty clear: review focus was every core review; high prio is gets more time 15:27:06 wow 15:27:10 just the two? 15:27:25 xyang2: unless we agree to add more 15:27:32 remember how short this cycle is 15:27:35 what's the difference between review focus and hi-pr 15:27:54 tommylikehu_: review focus means it needs +2 from everyone, not just 2 people 15:28:01 bswartz: well, I misunderstood the purpose of the etherpad then 15:28:03 cool 15:28:35 xyang2: the information was in different places 15:28:48 xyang2: sorry I tried to explain this difference when we created the etherpad 15:29:19 bswartz: I believe I was in the meeting when you talked about it but I still missed it 15:29:23 we need reviewers to focus on these specs because they're complex, but not necessarily essential features for ocata 15:29:47 high priority specs are stuff we consider essential, and we give more time for those specs to be reviewed/merged 15:30:14 do we have deadline for these review focused specs? 15:30:17 I wish we had introduced this new process on a normal 6-month release cycle 15:30:31 tommylikehu_: if they are not hi-pri, it is tomorrow midnight 15:30:34 tommylikehu_: no special deadline just the low/high priority deadlines 15:30:43 this clarifies some of my misconceptions as well... can i propose adding the access rules fixes to ocata as high priority? 15:30:59 gouthamr: yes I'm trying to get there 15:31:12 I want to go over the remaining specs 15:31:31 but I also want to make sure we're all on the same page 15:31:51 the new system is unfortunately complicated 15:32:20 I laid all this out in the specs deadlines spec based on conversations and feedback from all the core team members 15:32:40 people liked the separate low/high priority designations and the review focus designations 15:33:00 bswartz: how do we decide which spec will become high priority? 15:33:26 xyang2: we discuss it in this meeting, then push a change to this page: https://github.com/openstack/manila-specs/blob/master/priorities/ocata-priorities.rst 15:33:54 we discussed the race conditions spec last week but I didn't push the change yet 15:34:06 ... 15:34:38 bswartz: seems pretty late now if today is the deadline for merging specs 15:34:57 tomorrow midnight 15:34:59 xyang2: it has just become tomorrow midnight 15:35:07 xyang2: yes that's why I'm regretting how short ocata is and how this process is new 15:35:14 ganso: still pretty short on time 15:35:18 but i think it's still too late 15:35:25 but we have to make the best of this situation 15:35:33 I sense that people are antsy to make some decisions so let's move on 15:35:38 #topic high priority specs 15:35:43 bswartz: I thought all specs on that etherpad have a later deadline 15:35:51 +1 15:36:26 let me try to fix the etherpad in parallel with running this meeting 15:36:42 are there any other specs to nominate for high priority? 15:36:50 bswartz: goutham's 15:36:55 IPv6 15:37:37 I'd like to vote IPv6 +1 15:37:49 i think IPv6 can use more spec attention and would provide nice feature gain in ocata without a lot of resource drain 15:37:57 let's discuss gouthamr's first 15:38:08 #link https://review.openstack.org/399049 15:38:21 ^ Fix and improve Access Rules 15:38:38 the access rules changes proposed (code only for now) is fixing race conditions. I think we're following a model that we discussed at the design summit for this change 15:38:49 this one does feel like high priority to me 15:38:54 +1 15:39:00 gouthamr: I wish you'd written the spec before the code 15:39:02 +1 for making it high prio as it affects all manila users 15:39:02 +1 15:39:08 +1 15:39:20 +1 15:39:24 +1 15:39:37 bswartz: we were aiming at newton, but it was too risky to attempt to fix when we had features that needed to merge 15:40:19 but we can take this opportunity to make other nice-to-have fixes as well and do it right, and hence the blueprint and the (yet unfinished) spec 15:40:21 okay does this spec also need to be added to review focus etherpad? 15:40:44 +1 15:40:49 +1 15:40:50 +1 15:40:55 +1 15:41:00 +1 15:41:08 +1 15:41:10 does that give me time to finish it though? :) 15:41:16 gouthamr: yes 15:41:18 bswartz: if specs on this etherpad are either high or low priority, we should have two sections if it is clear 15:41:20 gouthamr: I guess 15:41:34 xyang2: we now do 15:41:35 making it high priority already gives you more time 15:41:38 xyang2: Did you see what I did on the etherpad? 15:41:49 I see it now 15:41:57 * gouthamr is taking a 16 hour flight tomorrow and skipping more time zones 15:42:05 * markstur shows up late 15:42:10 hi. sorry late 15:42:19 markstur you are late 15:42:23 I didn't do this before because this etherpad is not authoritative -- people can just edit them and add their own spec to the wrong section 15:42:54 * bswartz worries too much about etherpad vandals perhaps 15:43:19 bswartz: most of time when others change it they will use a different color, so give you a clue it is changed 15:43:33 yep 15:43:37 okay moving on to IPv6 15:43:45 +1 15:43:46 #link https://review.openstack.org/362786 15:43:57 ^ enable IPv6 in manila 15:44:09 it's a very useful feature, +1 15:44:09 we covered this one 2 weeks ago and agreed it was low priority 15:44:24 thanks to the reviews it's gotten, we've seen a lot of positive changes 15:44:42 however high priority implies that this features really needs to be in ocata 15:45:04 I had some feedback and -1 that I thought I posted last night. It is stuff that could be resolved incode review. I think. 15:45:14 it sounds like the huawei guys are committed to getting the code for this done in ocata 15:45:24 sure 15:46:29 I would have preferred if this had wide driver adoption in the release it is merged 15:46:30 my argument for making it high prio is that they will get it done, but I'd like the review not to get cut off in a rush. 15:46:45 but in ocata it feels quite short to merge a feature that affects so many layers and also get driver support 15:46:45 is zhongjun here? 15:47:01 not this time 15:47:08 she's the owner of this and has pushed most of the commits here 15:47:14 bswartz: tommylikehu_ is working on zhongjun's behalf at this time it seems 15:47:24 I guess Iim wondering if we can't just get thins one merged this week and move on 15:47:26 yeah~ 15:47:50 ganso: it's a capability.. allowing the core code to merge now few drivers supporting it is good for lowering the risks as well.. 15:47:52 we can do the driver's part in Pike 15:48:16 yeah there's no need to actually implement v6 support in drivers if we get the capability stuff right 15:48:28 ^ that's what i meant to say 15:48:33 gouthamr: yes, it is not problem, although I would have preferred the other way 15:48:44 when we discussed this in BCN we were leaning towards requiring blanket support across all drivers 15:48:53 i just want some more eyes on the capability stuff as that was just added recently 15:48:59 If the drivers won't implement until Pike then we don't need to merge this in O. Just have it ready for drivers to try. 15:49:11 but during review we realized that no matter what driver authors do, deployers may still fail to configure IPv6 15:49:52 therefore a capability system is required and that frees us up from forcing drivers to implement anything other than the capability reporting 15:50:13 We should keep working on this 15:50:35 I guess I'm in favor of high priority for this one 15:50:39 or their network infra may not support it so that exports would not work 15:50:43 I'd like to see the capabilities land in ocata 15:50:53 +1 15:50:59 lack of IPv6 support in manila is frankly an embarrassment 15:51:10 +1 15:51:12 +1 15:51:13 so let's no drag our feet 15:51:51 any other opinions before we move on? 15:52:21 we'd be closer to the TC goal that you were mentioning if we can implement and test against atleast one of our drivers in ocata 15:52:46 I guess it should include support for at least one first party driver 15:52:57 to test the feature, along with the tempest tests 15:53:03 ganso: usign scenario tests 15:53:04 ganso: +1 15:53:10 vponomaryov: +1 15:53:22 #topic share groups spec 15:53:35 #link https://review.openstack.org/#/c/315730/ 15:53:42 this is low priority, review focus 15:53:47 seems to be getting positive reviews 15:53:51 Is this similar to cinder's generic group 15:54:18 I mainly support this effort because it removes the unsupported cgroups APIs 15:54:31 ok 15:54:37 cknight's work on this spec has been great, and vponomaryov is now leading the effort to finish it off 15:54:51 please give this one a review 15:55:04 #topic migration improvements and jobs tables 15:55:12 #link https://review.openstack.org/392291 15:55:14 bswartz: they are 2 separate specs 15:55:16 #link https://review.openstack.org/392262 15:55:18 I know 15:55:28 times is short so I'm covering them together 15:55:32 bswartz: ok 15:55:45 ganso: is there one you'd like to proritize over the other? 15:55:52 bswartz, OK, will review them. 15:56:03 so, seems there is more to investigate in the data jobs table, I am unfamiliar with the taskflow library suggested to be used 15:56:14 -1 for taskflow 15:56:22 bswartz: yes, the share migration ocata improvements would be higher priority for me 15:56:34 I've used taskflow but some folks despise it 15:56:55 markstur: but not you? 15:56:56 ganso: would you like to withdraw the jobs table spec for ocata so we can focus on other things? 15:57:02 bswartz: as it will be small amount of code and hopefully the last changes to the share migration API 15:57:16 ganso: or should we keep pushing for it? 15:57:19 vponomaryov: It worked so I don't "despise it" 15:57:39 bswartz: tbarron and toabctl have a lot of concerns about it 15:57:50 taskflow is used in cinder and the resulting code is completely incomprehensible 15:57:52 don't rathole on taskflow, there's just a lot more to discuss 15:58:06 bswartz: I can work on it in Pike no problem 15:58:15 okay 15:58:21 bswartz: it will make more sense if the feature still has research to do 15:58:24 #topic mountable-snapshots 15:58:34 #link https://review.openstack.org/321213 15:58:41 this is the last review focus spec 15:58:57 tpsilva: did I miss something about extra-specs and capabilities? 15:59:08 bswartz: that one looks ok by me, I really don't get the extra-specs question you asked 15:59:10 merged 15:59:11 I thought we agreed that this was a feature drivers needed to support 15:59:15 looks like this one is on its final discussions... markstur pointed some issues and I just fixed 15:59:16 it's optional 15:59:31 bswartz: I didn't quite get your question on the spec 15:59:31 bswartz: it is exactly the same as revert-to-snapshot extra-spec wise, it has its own extra-spec 15:59:35 therefore there has to be a capability so end users know if the share type can support it 15:59:47 bswartz: and it requires snapshot_support to be un-overloaded, just like revert-to-snapshot 15:59:47 ganso: I just didn't see that written in the spec 15:59:55 bswartz: it is there AFAIK 16:00:05 it's there 16:00:06 okay let's follow up on that one in the channel 16:00:10 that's all we have time for today 16:00:13 thanks everyone 16:00:18 I thought it was there but maybe I was reading between the lines. Let's make it very bold and explicit. 16:00:27 next week IRC meeting is canceled due to thanksgiving 16:00:35 * tbarron suggests a new review-focus deadline on high prio specs, perhaps December 1. 16:00:47 can discuss in channel 16:00:49 tbarron: isn't it ocata-2 16:01:02 ganso: review focus, not cutoff 16:01:02 #endmeeting