15:01:12 #startmeeting manila 15:01:13 Meeting started Thu Feb 9 15:01:12 2017 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:16 The meeting name has been set to 'manila' 15:01:20 hello o/ 15:01:20 Hi 15:01:24 Hi 15:01:25 Hello 15:01:27 hi 15:01:28 hello all 15:01:28 hi 15:01:29 hi 15:01:31 \o 15:01:37 hi 15:01:55 hi 15:01:57 #topic announcements 15:02:31 All of you should know by now that we finally reached Ocata RC1 on Tuesday 15:02:52 so Ocata is officially "done" unless we discover a release-stopping bug 15:03:31 but how long we should not merge "big" changes? 15:03:32 Hopefully many of you are downloading the RC1 bits and trying to break them in search of bugs 15:04:13 vponomaryov: as always it's best to avoid any siginficant changes until the Ocata release itself (Feb 23) 15:04:27 but master is officially open for pike-related feature changes 15:04:31 bswartz: ok, thank you 15:05:04 hi 15:05:09 Some of us are now looking towards Pike though 15:05:30 It's a great time to propose your specs for Pike-related features 15:05:51 if we have specs proposed going into the PTG it would help discussions around those features 15:06:11 at this point I'm assuming we'll keep our existing specs process as it seemed to work pretty well 15:06:27 +1 15:06:47 although for Pike we'll get a normal 6 month release instead of the painfully-compressed 4 month schedule for ocata 15:07:05 that's great 15:07:09 I guess the one think I want to revisit is the Priority specs deadline 15:07:29 setting it all the way to milestone 2 is too long after the milestone 1 deadline for other specs 15:07:49 #action bswartz propose PTG topic about priority specs deadline 15:08:05 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:08:18 so only 1 topic today! 15:08:19 hello 15:08:21 #topic PTG 15:08:27 #link https://etherpad.openstack.org/p/manila-pike-ptg-topics 15:08:34 too long a gap, yes. But a late deadline is good for things that come up during Pike that we'd decide to prioritize. Maybe exception process for that. 15:09:01 the etherpad has a ton of topics now 15:09:08 thanks to those who are proposing them 15:09:23 I'm going to start drafting a tentative schedule for them 15:09:25 bswartz: we have three days for these? 15:09:37 tommylikehu_: 2 days only 15:10:04 my plan is to schedule some topics for Wednesday and some for Thursday, and to put a rough priority order on them 15:10:27 I can't promise when any given discussion will start or end, but I will cut off discussions that run too long to ensure that we get through the whole list 15:10:32 bswartz: is there going to be webex for remote participants? 15:10:48 ganso: yes that's especially important this time around 15:10:56 ganso: I assume you're still not travel approved? 15:11:00 bswartz: yea 15:11:15 tommylikehu_: are you or anyone other Huawei representatives planning to attend the PTG in person? 15:11:23 I will 15:11:35 okay great 15:11:37 ganso: have you tried the travel support program? 15:11:50 xyang1: yes... ended up on waiting list... still on waiting list AFAIK 15:12:16 xyang1: I know you'll probably be in the cinder sessions, but will anyone from dell/emc be attending manila sessions? 15:12:34 bswartz: probably not 15:12:48 k 15:13:14 me and xyang are probably the most negatively affected by the new PTG schedule 15:13:17 bswartz: people are not sure what PTG is about and are still prefer to go to the summit 15:13:23 yeah... 15:13:45 bswartz: have you heard anything about the location of the next PTG? will that be in the U.S. or not? 15:14:00 oh well -- because ganso and markstur both can't join in person we will try hard to get conferencing setup for remote people 15:14:02 won't be US 15:14:15 xyang1: no word on the fall PTG -- not even a date 15:14:23 according to openstack top leadership 15:14:38 bswartz: maybe there is not going to be another PTG? 15:14:40 but they didn't specify where 15:14:41 tbarron: I heard it would likely be US-based 15:14:59 one is in, one is outside america 15:15:00 I think it would be wise to wait until after the first PTG before they plan the next one 15:15:01 tbarron: that means I am not sure whether I can attend in the future. too much international travel 15:15:04 bswartz: they announed not, b/c of us entrance policy 15:15:16 tbarron: oh that makes sense 15:15:34 next 3 gatherings after boston not in us 15:15:43 of course sidney was already set 15:15:44 but what if we're afraid to leave US? b/c of re-entrance policy? 15:16:02 wow, sticking it to trump 15:16:06 tbarron: I think they have only announced the location of the summit, but not future PTG yet 15:16:12 markstur: :-) 15:16:16 xyang1: right 15:16:27 markstur: that's definitely an issue. it applies both ways 15:16:30 * vponomaryov grabs pop-corn 15:16:40 okay back to the topic at hand 15:16:51 we need to plan this PTG 15:17:12 vponomaryov: bored?:) 15:17:22 The main thing I need to know for my scheduling is if there are any topics that remote attendees NEED to be part of, and what time restrictions they will have 15:17:59 bswartz: no time restrictions... If possible I'd like to participate on all of them 15:18:01 so ganso, markstur, please contact me outside this meeting 15:18:16 ok 15:18:23 about remote attendees, i got NetApp to approve more storage space (hehe) on my webex account --- so, i hope to record stuff again 15:18:33 and this will be your last reminder to add topics to the etherpad 15:18:52 I'm going to assign topics to days and put the high priority stuff earlier in the days 15:19:01 anything else that comes up will go at the end of the list 15:19:37 and given the number of topics we have already, it's possible we will actually use up all our time and have to punt some topics out 15:19:56 #topic open discussion 15:20:11 https://review.openstack.org/#/c/431315/ 15:20:18 so we have plenty of time left if anyone has something else to cover today 15:20:27 so looks like there is another critical LVM driver bug ^ 15:20:31 ganso: thanks 15:20:49 I am wondering whether we should take it as a bug 15:21:04 I would like to highlight that my feeling is that LVM has been the reference driver lately, in place of generic 15:21:26 this is a good catch 15:21:28 and I think it is important that we have it working 15:21:45 we don't have enough tests around combinations of snasphots, expand/shrink, revert, etc 15:21:58 bswartz: how many driver support extend share with snapshot exist? 15:21:58 so when multiple features are used together, sometimes bugs are found 15:22:12 tommylikehu_: for many it's an easy thing to support 15:22:17 but since the introduction of revert and mountable, it looks like it got a little more than it could handle, and would need a refactor to take into account all the capabilities it has implemented 15:22:26 I'm not sure how hard it will be to fix this for the LVM case 15:22:54 ganso, tommylikehu_: have you investigated a possible fix here? 15:23:01 should be be concerned that it might be impossible? 15:23:10 bswartz: a little bit, I suggested in the patch comments 15:23:46 k 15:23:48 bswartz: looks like tommylikehu_ already fixed it, but he changed the extend driver interface to have a snapshot parameter 15:24:02 bswartz: which I think it is not ideal 15:24:12 tommylikehu_: does the huawei driver have a similar issue? 15:24:28 bswartz: because it is the only driver so far that would need this, and there are other means to obtain the snapshots so the parameter wouldn't be needed 15:24:35 ganso: I agree it's best not to change the driver interface for the benefit of a single driver, if other workarounds can be found 15:24:39 bswartz: yingzhezeng told me huawei driver does not support exrend share with snapshot exist 15:24:59 tommylikehu_: even with the modified driver interface, you couldn't support this feature? 15:25:14 bswartz: sounds like that 15:25:28 personally I feel we should definitely fix this, but I'm not sure about holding up the release of Ocata for it 15:25:40 bswartz: I will confirm this tomorrow 15:25:50 it doesn't feel like a release blocker bug 15:26:02 bswartz: it's not 15:26:07 bswartz: if it is fixed in time before the Ocata release, can't it be backported and RC2 be requested? 15:26:15 so we could fix it and backport the fix later -- after we're comfortable it doesn't cause any other refressions 15:26:36 ganso: yes that's a possibility, but as you know I prefer to avoid RC2 at nearly all costs 15:28:31 I'll take a look at the review after the meeting 15:28:35 anything else for today? 15:28:53 yes 15:29:06 I noticed that several CIs seem to be very flaky lately 15:29:21 several are not passing, some are not even running, some fail right away 15:29:23 just several? ) 15:29:34 * bswartz nominates ganso for CI police 15:29:52 besides, even our first party CIs are not very stable 15:30:03 * ganso puts on the CI police hat 15:30:20 ganso: I hope to address that problem with our driver support matrix 15:30:35 we will use public shaming as a motivator to get CIs fixed 15:31:06 however we should recognize that it's an inherently difficult problem, and we should set reasonable standards for how reliable CI should be 15:31:21 cinder struggles with this same issue, just at a larger scale 15:32:11 bswartz: I haven't read through the whole PTG topic list 15:32:19 cinder has tried to set some official guidelines for how long a CI can be broken before the community flags it as a problem 15:32:42 bswartz: so maybe we should have some official rules, success ratio, etc in order to flag drivers as deprecated or unsupported 15:32:42 I think they started with 2 weeks as a grace period 15:32:51 yeah 15:33:19 bswartz: oh no.. 15:33:31 bswartz: we should publish that standard somewhere, on wiki, etc. 15:33:59 I'm less interested in ratios of success/failure and more interested in measures that ensure that a person is actively engaged (because that's the whole point of CI) 15:34:00 bswartz: and which is criterion for shaming? per-driver? per-company? 15:34:16 we talked about that at BCN, but I guess we did not have any members in CI police squad xD 15:34:23 vponomaryov: per driver 15:34:38 ganso: ocata was so short and we tried to do so much 15:34:43 bswartz: driver + driver mode? 15:34:55 vponomaryov: should be per-driver as not all have a "company" and even if they do there are different responsible parties 15:35:03 ganso: this is important to me, but I decided to focus on feature content during ocata and had no time for other things 15:35:41 vponomaryov: i agree that stats per-mode are useful for a deployer to see 15:36:00 tbarron: it is very likely that one mode fails and other not 15:36:10 vponomaryov: not driver mode -- it's impossible that there would be different maintainers for 2 modes of the same driver, and what we're trying to measure is whether the people responsible are still engaged 15:36:31 vponomaryov: in that case maybe even failure is the wrong metric 15:36:32 vponomaryov: you may have left out 'not' but I agree with the statement as is 15:36:42 but it would be interesting to see if one mode has CI and one mode is left uncovered 15:36:42 i guess, for ease of stats this should be "per CI account" 15:36:45 well, that it is quite possible 15:37:13 vponomaryov: or that e.g. dhss=true is claimed but not tested 15:37:34 the main thing we want to discover is drivers where the vendor has walked away and stopped maintaing it 15:37:39 yeah, so, in other words, our shaming approach will not be trivial )) 15:37:42 tbarron: any capability in the matrix would need to be tested in CI 15:38:21 vponomaryov: I actually don't like the word 'shaming' 15:38:27 ^ is hoping the matrix we can "automate" the matrix in pike 15:38:29 vponomaryov: just data, let it speak for itself 15:38:29 tbarron: that was my word 15:38:37 tbarron: it is not "my" word )) 15:38:49 bswartz: vponomaryov yeah, understood 15:39:01 s/vponmaryov/bswartz/ 15:39:07 tbarron: yes we won't actively ridicule anyone, but we will hope that presenting the data has that effect 15:39:14 give deployers the info to make decisions 15:39:20 bswartz: understood 15:40:26 as long as vendor pays someone to pay attention to driver bugs and CI issues, that's a huge improvement over vendors that throw a driver over the wall and go on to work on something else 15:40:39 that's the behavior we want to encourage 15:41:30 +1 15:41:54 okay anything else? 15:42:00 tbarron: s/shaming/highlighting/ OK? 15:42:19 markstur: i feel hightlighted sometimes 15:42:38 this meeting is the "highlight" of my day ;) 15:42:40 ^_^ 15:42:49 okay sounds like we're finished 15:42:53 thanks everyone 15:43:02 we'll hold the meeting next week as usual 15:43:11 #endmeeting