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