15:00:30 #startmeeting manila 15:00:31 Meeting started Thu Aug 2 15:00:30 2018 UTC and is due to finish in 60 minutes. The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:34 The meeting name has been set to 'manila' 15:00:37 .o/ hello 15:00:41 o/ hi 15:00:42 hello 15:00:54 i'm skipping the courtesy ping 15:01:01 so I don't get banned 15:01:03 good choice after last week 15:01:14 so nudge your comrades 15:01:25 bswartz isn't on 15:01:32 or gouthamr 15:02:06 some folks may just now be discovering that they need to register their nicks 15:02:31 the spam issue was bad so most of the openstack channels are +r now 15:02:37 o/ 15:02:48 tbarron: is this different than what we had to do to be able to PM other users? 15:02:49 xyang no courtesy ping any more 15:03:03 ganso: you mean to pm bswartz 15:03:09 I didn't require it 15:03:16 hmmm weird 15:03:18 but may have to 15:03:20 not sure why I had to 15:03:55 agenda: https://wiki.openstack.org/wiki/Manila/Meetings 15:04:06 #topic Announcements 15:04:10 \o 15:04:38 No one nominated themselves for PTL besides me, so 15:04:48 I'm the Stein PTL. 15:04:48 we're stuck with you 15:05:01 That'll teach you to be apathetic! 15:05:02 :P congratulations :) 15:05:12 congrats :D 15:05:25 tbarron: Congratulations on your 100% margin of victory :) 15:05:38 hi 15:05:40 Thanks all, please make sure that I do a good job, or start doing a good job. 15:05:41 congrats tbarron! 15:05:45 We've got stuff to do. 15:05:50 hi nirg22 15:06:03 Next week is RC1 target. 15:06:11 That's the release candidate. 15:06:21 tbarron++ 15:06:30 .o/ 15:06:35 The '1' in RC1 is not encouragement to have multiple rcs :) 15:06:38 whew, sorry I'm late 15:06:47 bswartz: hi!, good to have you here. 15:06:49 data center upgrade ran 10 minutes over 15:07:06 We'll aim to cut rc1 on Wednesday, 8 august. 15:07:14 Deadline is Thursday. 15:07:31 We want to flush out any bad bugs and fix them by then. 15:07:44 And ideally RC1 will *be* our release. 15:08:11 We'll look at bugs in a moment, but any questions about the target, process? 15:09:01 OK, also want to remind about the PTG planning etherpad. 15:09:06 https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018 15:09:26 Please note if you are attending, physically or remotely, and 15:09:43 add topics for discussion as you think of them. 15:10:04 Anyone have any other announcements? 15:10:47 #topic Python3 goal for Stein & third party jobs 15:11:13 You may have seen the mail with the weekly Technical Committee summary, which 15:11:28 mentioned the Stein cycle python3 first goal 15:11:49 which says that all projects will run python 3 jobs in gate 15:11:59 I asked 15:12:30 #link http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-01.log.html#t2018-08-01T19:38:26 15:12:49 whether that includes third-party CI jobs. 15:13:17 many openstack projects don't have multiple back ends and drivers the way manila and cinder do. 15:13:25 so we're a bit special. 15:13:51 Anyways, we're thinking that we should make an etherpad or other 15:13:58 What exactly does that mean? 15:14:01 No more python2? 15:14:21 public traker for the Stein cycle and encourage third-party jobs to convert or add python3 15:14:27 tracker 15:14:46 and then report on tested-with-python3 in a matrix 15:15:00 bswartz: it doesn't mean we have to abandon py2 15:15:13 I'm interested in when we *can* abandon py2 15:15:19 I'd love to delete all that "six" crap 15:15:22 bswartz: but we should either replace jobs with py3 or duplicate 15:15:44 bswartz: yeah, but first step is to get working py3 jobs whereever we have py2 15:15:46 Hi, sorry I am late 15:15:51 xyang!! 15:15:57 always good to have you 15:16:07 Is there a requirement to continue to test with py2? Or is it optional? 15:16:27 tbarron thanks! 15:16:31 bswartz: I didn't see any such requirement. But for us I think 15:16:39 And if py2-specific bugs are found, is it acceptable to not fix them? 15:16:48 the long pole will be getting all our third-party jobs to run py3. 15:17:25 When all our jobs *can* run py3 and pass (as much as they do now, not fail 15:17:43 on py3 errors) then we can consider dropping support for py2. 15:17:47 At least in master. 15:18:03 It seems to me that the trickiest part of all of this is when we can nudge customers off of py2, if any are still clinging 15:18:19 bswartz: agree 15:18:49 The main problem is the RHEL6.x distro 15:19:05 RHEL7 and all other distros have py3 15:19:44 doubt anyone will deploy newer openstack with older distros, RHEL 6.x 15:20:03 i.e, pretty sure a lot of tooling will break 15:20:19 not if it's rhel and they want support 15:20:28 but generalizing here 15:20:43 distros are moving towards py3 only, 15:20:58 the tricky part will be stable/branches 15:21:02 and backports 15:21:17 so I think we'll have six library around a while 15:21:25 but maybe I'm wrong 15:21:31 IIRC, Ceph is also stuck on py2, which may be holding people back from joining us in the future 15:21:40 in any case, in Stein we need to move jobs to py3 15:21:46 Although that may have been fixed recently 15:22:01 tbarron: well, unit tests should be able to capture backport problems because of the lack of py2 compatibility 15:22:07 i think it's happening for ceph, and even for swift 15:22:36 tbarron: unless we agree it is bad to adapt the code when doing the backports 15:22:41 ganso: yes, but bswartz looks forward to not having to care about py2 compatability 15:22:57 * erlon quietly opens the back door that makes a huge grit :p 15:23:03 he's always looking down the road :) 15:23:10 At this point it's like supporting Windows XP 15:23:21 I'm slightly worried about the evenlet use we have in our built-in driver 15:23:30 ok, anything else on this topic? no one has any issue with us converting first party jobs in Stein and 15:23:44 encouraging and tracking third-party job conversion 15:23:46 right? 15:23:47 evenlet py3 compatibility is not near to be done 15:23:56 at least, that was the case last time I checked 15:23:59 vkmc: yes!! 15:24:04 bswartz: if you think about it, XP was still supported when windows Vista and 7 came out. So, I believe we will slowly move away from the py2 as they become unsupported 15:24:15 vkmc: +1, i think we can start deprecating it 15:24:18 from the py2 *stable branches 15:24:29 and... also, I'm a bit worried about our ci, it's ok for ubuntu because py3 is available, but for centos gates we don't have py3 15:24:46 vkmc: gouthamr: what do we need to do to get off eventlet? 15:24:49 gouthamr, +1 15:25:01 tbarron, start using the wsgi server instead of the built in one 15:25:04 :) 15:25:35 so we depreacte the built in server at the beginning of Stein 15:25:41 what? 15:25:50 make a patch and put it in review now 15:25:51 The built in server is important for debugging 15:25:56 yep, although we might need a one-cycle deprecation, we're still deploying manila-api in rocky in OSP, addressing that right now 15:26:16 How do you run a WSGI container in a debugger? 15:26:22 and remove it in T 15:26:40 bswartz: just finishing the thought, now to your point.. 15:26:53 if we remove it, do we lose important debug capability? 15:27:11 Yes we do 15:27:22 We had this discussion in Atlanta when we talked about adding WSGI 15:27:35 The understanding was that we add a new option but no plan to take away the old option 15:27:43 bswartz: with logging? 15:27:54 bswartz: is this a bad dilemma b/c debug implies lack of py3 support? 15:27:58 If we take away old option we lose a useful ability 15:27:59 vkmc: ^^^? 15:28:15 IDK what the eventlet+py3 situation is 15:28:24 https://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#python-interactive-debugger 15:28:25 I've never been thrilled with eventlet 15:28:30 sounds like a PTG topic 15:28:49 ^ haven't tried that, but we'll have to, to take a call 15:28:54 vkmc would you make sure it's on the PTG ethepad 15:29:23 also, the issue is not manila specific so we'll need to socialize the problem 15:29:39 vkmc I think you were talking with dhellmann about it earlier? 15:29:41 Yeah the discussion in Atlanta I spoke of was in the TC goals session 15:29:50 It was a cross-project forum 15:29:58 bswartz: ack, makes sense 15:30:50 ok, let's move on for now, glad we got this issue out in front 15:30:57 #topic review focus 15:31:18 #link https://etherpad.openstack.org/p/manila-rocky-review-focus 15:31:38 I've updated this page quite a bit 15:32:12 we'll cut a manila-ui release at the end of the rocky cycle 15:32:20 ideally we'll be ready around rc1 time 15:32:33 we have a bad bug which vkmc is fixing 15:32:42 so we need to get it in first 15:33:05 #link https://review.openstack.org/#/c/587269/ 15:33:24 also it would be nice to get the mox requirement removed since that's a community goal 15:33:43 #link https://review.openstack.org/#/c/584795/ 15:33:45 Removed? 15:33:49 Oh yes 15:34:00 we have a transitive requirement through horizon 15:34:12 no work for us to do but a flag will get toggled 15:34:30 I don't think there are other ui fixes that we need before release but 15:34:43 if anyone else knows of some please ping me! 15:34:49 hi 15:35:05 jun2222: hi, are you "our" Jun? 15:35:16 yes :D 15:35:21 :D 15:35:28 jun2222: welcome 15:35:39 OK, moving on to manila proper. 15:35:47 jun2222: having problems getting registered with freenode? 15:35:57 My network is not good 15:36:07 we have a serious scheduler bug, isn't working on share protocols 15:36:17 bswartz: you know me 15:36:26 #link https://review.openstack.org/#/c/586456/ 15:36:35 This one needs review attention. 15:36:57 I don't know if we can get a fix before rc1 in place, but let's see. 15:36:58 jun2222: https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018 15:37:12 bswartz: Completely correct 15:37:25 hmmm why is there a new filter? I believe that this filtering functionality was working before 15:37:34 we have the community goal of mutable config, which we thought we'd dpone 15:37:36 done 15:37:40 but there's a bug 15:37:50 and a proposed fix at 15:37:51 ganso: do you recall when it was working? 15:37:51 ganso: somehow the scheduler regressed 15:38:05 It would be great to do the forensics and see when/why it broke 15:38:14 That might inform the best way to fix it 15:38:29 #link https://review.openstack.org/#/c/585890/ 15:38:48 no, but I remember there is a capability that the backends should report, like "supported_protocols" or something like that, then the Capability Filter would try to see if the protocol is contained in that string 15:38:58 bswartz: yeah, might be a better approach than the current proposal in review 15:39:03 less risky 15:39:24 that's how it used to work 15:39:36 a backend reporting "NFS_CIFS" would accept both protocols 15:39:46 backends reporting only "NFS" or "CIFS" would not 15:39:48 ganso: interesting... teh capability filer is supposed to only look at the extra-specs and not the other parts of the request spec, unless we were adding share_proto in there 15:40:00 ganso: +1 15:40:18 so, I am not sure creating a new mechanism is better than investigating why the old one is not working anymore, this could introduce more bugs. I agree with bswartz on this 15:41:22 ganso: did you implement the "old" mechanism? 15:41:31 tbarron: no, it was already working when I joined manila 15:41:50 The mechanism ganso describes goes back to Manila 1.0 15:41:55 vponomaryov wrote it 15:41:55 I noticed this old mechanism behavior when I coded drivers for Hitachi long time ago 15:42:05 and it was working, I validated it 15:42:17 i wonder if someone fixed the capabilities filter to only filter on capabilities in extra-specs 15:42:35 that is, removed a hack that made this work 15:43:35 Let's talk about this one in #openstack-manila and see if we can get a solution 15:43:41 in place before we ship 15:43:42 tbarron: ideally, that's what the capability filter should do, our protocol filtering was a custom behavior in it. It is still there somewhere in the code I believe, but it is broken and/or causing problems. If we create this ProtocolFiltering (which is a good idea, instead of custom CapabilityFilter behavior), we should find and remove the old code 15:44:02 I remember we add it because we want to support both capabilities true and false for capacity filter 15:44:04 More worrying, why didn't some test break when the mechanism was removed? 15:44:17 bswartz: yes! 15:44:30 * gouthamr shakes fist at tempest guys 15:44:34 * gouthamr oh.. 15:44:40 bswartz: because the steps to reproduce involve having separate CIFS and NFS backends present 15:44:48 not really 15:45:18 ganso is right 15:45:25 To properly test this, you need 2 backends 15:45:47 Scheduler testing could be a lot better 15:46:10 I believe it could also be reproduced having enabled NFS and CIFS in the API, but having only NFS or CIFS backends. If we are running a CI with only NFS or only CIFS, we would disable the other in the API. I am unaware of any CI that leaves all enabled 15:46:12 Before we had the dummy driver, testing the scheduler was difficult 15:47:18 In theory the dummy driver could be used to run tests with a large number of backends 15:47:40 And really exercise the scheduler's decision making ability 15:47:56 bswartz: +1 15:48:01 it could report anything 15:48:41 I added some stuff to the PTG etherpad w.r.t. scheduler testing but let's see if we can fix *this* 15:48:48 scheduler issue before rc1 15:49:20 Are there other bugs/reviews on the review focus etherpad that are potential 15:49:24 release blockers? 15:49:50 #link https://etherpad.openstack.org/p/manila-rocky-review-focus 15:49:58 * tbarron reminds 15:50:23 Even if not, there are some here worth clearing off our plate. 15:50:43 Please note those where diverse-company reviewers are needed. 15:50:47 And help. 15:51:47 OK, anything else on this topic? 15:52:17 #topic Bugs 15:52:28 dustins: have anything for us this week? 15:52:53 seems like we're up to our ears in bugs already... 15:53:08 tbarron: Don't think so this week, I think we got them all last week that I could see 15:53:14 Unless it's a release blocker it seems like we should boot it out 15:53:17 New ones that I saw were already assigned 15:53:28 ok, moving along 15:53:36 #topic Open Discussion 15:54:02 we can talk more about the bugs we touched on here too 15:55:00 gouthamr: i think vkmc responded to your last review point on https://review.openstack.org/#/c/587269/ 15:55:11 ^^^ horizon was badly broken folks 15:55:17 nice, will take a look thanks tbarron vkmc 15:55:30 so assuming he's OK, we need a non-red-hat reviewer for that one 15:56:02 oh, and I'm adding to the PTG etherpad selenium horizon testing for plugins 15:56:22 e0ne put in his PTL stump speech something about that and 15:56:26 :D 15:56:40 Oooh 15:56:43 this one is a great example of how horizon can be totally broken yet pass all our gate tets 15:56:45 tests 15:57:27 on tests side: is time permitting also to touch scenario tests topic? http://specs.openstack.org/openstack/manila-specs/specs/ocata/scenario-tests.html 15:58:07 dsariel: two minutes and then take it to #openstack-manila :D 15:58:16 dsariel: but start please 15:58:20 ok :-) 15:58:46 hmm, i thought we moved that link to http://specs.openstack.org/openstack/manila-specs/specs/release_independent/scenario-tests.html 15:59:35 yes we did 15:59:50 thanks. I'll update the trello card 16:00:01 with the new link 16:01:06 so regarding the scenario tests, I'm wip on several scenario tests from that list 16:01:13 ok, we're out of time, let's continue this on #rhos-manila 16:01:21 #openstack-manila? 16:01:33 on #openstack-manila :-) 16:01:35 #openstack-manila 16:01:37 !!!! 16:01:38 tbarron: Error: "!!!" is not a valid command. 16:01:44 Bye everyone, thanks! 16:01:49 #endmeeting