15:01:50 <tbarron> #startmeeting manila
15:01:51 <openstack> Meeting started Thu Aug 22 15:01:50 2019 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:54 <openstack> The meeting name has been set to 'manila'
15:01:56 <carloss> hi o/
15:02:01 <tbarron> courtesy ping: gouthamr xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso dviroel lseki carloss
15:02:02 <jgrosso> hello
15:02:05 <ganso> hello
15:02:07 <lseki> hi
15:02:09 <dviroel> o/
15:02:10 <toabctl> hi
15:02:18 <vhari> o/
15:02:53 <tbarron> Hi all!
15:02:56 <bswartz> .o/
15:03:01 <amito> Hi .o/
15:03:15 <tbarron> Agenda: https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:03:22 <vkmc> o/
15:03:30 <tbarron> #topic Announcments
15:04:35 <tbarron> I don't have any except a reminder that we are not three weeks out
15:04:40 <tbarron> till feature freeze.
15:04:51 <tbarron> #link https://releases.openstack.org/train/schedule.html
15:05:03 <tbarron> Anyone else have any announcements?
15:05:27 <tbarron> OK
15:05:44 <tbarron> #topic Python3 tempest 3rd party CI
15:06:05 <tbarron> #link https://wiki.openstack.org/w/index.php?title=Manila/TrainCycle#Python3_Testing
15:06:35 <tbarron> NetApp and Quobyte are in the winners column now
15:07:11 <lseki> 🎉
15:07:22 <tbarron> EMC and NetApp are having a constructive dialogue about
15:07:27 <tbarron> https://bugs.launchpad.net/manila/+bug/1833160
15:07:28 <openstack> Launchpad bug 1833160 in Manila "VNX: driver cannot start under py37 due to wrap_socket() got an unexpected keyword argument '_context'" [Undecided,New]
15:07:43 <carloss> :)
15:07:49 <tbarron> Thanks for helping out!
15:08:03 <carloss> I'm performing some tests right now to answer to his last comment
15:08:19 <tbarron> carloss++
15:09:03 <tbarron> So we're making some progress ...
15:09:40 <tbarron> #topic Cross Project Goals
15:10:16 <tbarron> IPv6 testing is on track I think, waiting on gyanshyam's test job
15:10:43 <tbarron> On PDF doc generation is anyone interested in being point?
15:10:53 <tbarron> We're supposed to supply a name.
15:11:11 <tbarron> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008570.html
15:11:25 <tbarron> If not, I'll do it.
15:11:47 <tbarron> There's not a magic quick solution here yet.
15:12:25 <tbarron> I communicated to our TC folk that when we generate the PDFs it makes lots of terrible
15:12:40 <tbarron> warnings and errors doing the LaTeX conversion
15:12:57 <tbarron> and asked for an example of a project succeeding with this goal.
15:13:05 <bswartz> LaTeX?
15:13:09 <bswartz> In OpenStack?
15:13:16 <tbarron> So folks are trying to get neutron to work.
15:13:37 <tbarron> bswartz: the initial idea was to do rst to LaTeX and LaTeX to pdf
15:13:48 * bswartz head explodes
15:13:59 <tbarron> bswartz: I think another approach is being explored now too
15:14:15 <tbarron> so I'll put myself as contact and keep the dialogue going.
15:14:37 <tbarron> I'm willing to do some work in manila docs but I want it to be aligned with what
15:14:44 <tbarron> other proejcts are doing.
15:14:54 <bswartz> https://github.com/rst2pdf/rst2pdf
15:14:57 * tbarron wipes brains off his keyboard
15:15:16 <bswartz> There are probably deeper issues I'm not grasping here
15:15:23 <tbarron> bswartz: yeah I think that's the alternative being chased.
15:16:19 <tbarron> both approaches are mentioned here:
15:16:24 <tbarron> https://etherpad.openstack.org/p/train-pdf-support-goal
15:17:33 <tbarron> #topic Reviews
15:17:56 <tbarron> We have three weeks for features to get in and we have a Review Focus Etherpad here
15:18:11 <tbarron> #link https://etherpad.openstack.org/p/manila-train-review-focus
15:18:39 <tbarron> The last item on this board merged, hurray!
15:18:54 <dviroel> \o/
15:19:14 <tbarron> It's really great that we've got glusterfs (with NFS) maintainers again, especially
15:19:40 <tbarron> because we know it's being used by several significant deployerx in China
15:19:53 <bswartz> Indeed!
15:20:04 <tbarron> The first item on this board is quite close to merging.
15:20:25 <tbarron> This is the work to allow updating of share types.
15:20:33 <tbarron> High quality work with good reviewers.
15:20:44 <tbarron> Thanks to the reviewers and contributors!
15:21:05 <tbarron> There are some outstanding issues but they are small so this one is not at risk IMO.
15:21:33 <tbarron> We do need a reviewer other than gouthamr on the Nexenta refactor.
15:21:51 <tbarron> #link https://etherpad.openstack.org/p/manila-train-review-focus
15:22:10 <tbarron> gouthamr has done the lion's share of the work on this one so reviewing it at this
15:22:19 <tbarron> point should not be that burdensome.
15:22:39 <tbarron> Please sign up and review!
15:22:43 <gouthamr> was waiting on Alexey's response on docs, i've no other concerns with it atm
15:23:17 * tbarron hadn't noticed gouthamr sneaking in ....
15:23:30 <tbarron> OK, let's look at this nice diagram:
15:23:38 * gouthamr almost got through
15:23:51 <tbarron> #link https://docs.google.com/drawings/d/1oTdJn6s47tSKstH14NEaekm0V1zVnuOxs95Ljt7DI7Y/edit
15:24:18 <tbarron> These reviews are for the two features NetApp did specs for for Train
15:24:21 <tbarron> good stuff
15:24:32 <tbarron> And you can see the dependencies here.
15:24:51 <tbarron> We don't need everyone to sign up for everything :)
15:25:13 <tbarron> But we need progress right away on https://review.opendev.org/#/c/674896/ and
15:25:39 <tbarron> https://review.opendev.org/#/c/671043/
15:25:52 <gouthamr> ^ i'll take a look at that
15:26:09 <dviroel> gouthamr: thanks
15:26:13 <tbarron> gouthamr: excellent
15:26:19 <carloss> gouthamr: thanks
15:26:31 <tbarron> and we need some other reviewers too!
15:26:53 <tbarron> I want to commend the NetApp folks on doing a lot of review on this themselves, out
15:27:01 <tbarron> in the open, in gerrit.
15:27:29 <tbarron> We all learn when this practice is followed rather than keeping it all in house until
15:27:34 <dviroel> tbarron: ack
15:27:37 <tbarron> you think it's perfect.
15:27:37 <carloss> tbarron: ack
15:27:38 <lseki> tbarron we will :-)
15:28:08 <tbarron> pass on my thanks to Marty as well :)
15:28:45 <tbarron> So let's see if we can get this main lynchpin merged or close to merge by next week.
15:29:08 <tbarron> By lynchpin I mean https://review.opendev.org/#/c/671043/
15:29:59 <tbarron> Anything else on the Reviews topic today?
15:30:29 <tbarron> #topic Bugs
15:30:41 <tbarron> jgrosso: what do you have for us today?
15:30:41 <jgrosso> Thanks tbarron I have two bugs today
15:30:51 <jgrosso> https://bugs.launchpad.net/manila/+bug/1746725
15:30:52 <openstack> Launchpad bug 1746725 in Manila "LVM driver is unable to remove addresses in different IP versions belonging to the same interface properly" [Medium,New]
15:31:16 <ganso> ^ brings back memories
15:31:18 <tbarron> ganso!
15:31:26 <jgrosso> :)
15:32:08 <ganso> not sure if that bug still exists with the latest library
15:32:10 <ganso> it is mostly a library bug
15:32:35 <ganso> but the LVM driver code can be changed to work around the bug and manage the rules in a more appropriate way
15:32:44 <tbarron> ganso: what library?
15:32:52 <ganso> tbarron: nfs library
15:32:58 <ganso> tbarron: bug comes from exportfs -u command
15:33:29 <ganso> bswartz's refactor of NFS based drivers solved the problem: https://review.opendev.org/#/c/476239/
15:33:44 <ganso> but his patch is not finished or polished enough to be merged as is
15:34:22 <ganso> as far as I remember last time I tested it
15:34:54 <tbarron> So this was a CentOS bug and we don't know if it's also in Bionic.
15:35:39 <tbarron> But bswartz's patch cleaned up a lot of the OS specific code iirc
15:35:50 <gouthamr> ganso: was this a manual test case, or did you automate this at some point?
15:37:37 <ganso> gouthamr: I tried to automate, but there the bug showed up in tempest test
15:37:47 <ganso> gouthamr: so I coded the test differently to avoid the bug
15:38:06 <ganso> gouthamr: The test was share migration with IPv6
15:38:55 <ganso> I remember we had a long discussion about this, and it was close to a feature freeze so we collectively decided to just avoid the bug
15:39:02 <gouthamr> ganso: ah, so currently that test case doesn't test two IPs of the same client?
15:39:45 <ganso> gouthamr: it does, but it is handled in a non-obvious way. I don't remember the specifics
15:39:48 <tbarron> ganso: the library bug is that 'exportfs -u <client>:<path' removes multiple exports rather than just the targeted export?
15:39:56 <ganso> tbarron: exactly
15:40:07 <ganso> tbarron: if the multiple exports are related to the same interface
15:40:09 <tbarron> ganso: was it deterministic?
15:40:15 <ganso> tbarron: yes
15:40:23 <ganso> tbarron: always happened
15:40:30 <tbarron> ok, let's see if it happens on bionic beaver
15:40:50 <tbarron> if not, I'm happy just saying this is a CentOS bug and leaving it at that for now.
15:41:14 <tbarron> We use lvm driver for test coverage, I don't see it in production with CentOS ....
15:41:41 <tbarron> ganso: your point though is valid that the LVM driver could do things in a way that's less fragile.
15:42:08 <tbarron> so my remarks are in no way intended to discourage anyone from doing that.
15:43:04 <tbarron> bswartz: I know you are buys with other things, but do you have plans for https://review.opendev.org/#/c/476239/ ?
15:43:45 <bswartz> tbarron: I got stuck on the backwards compatibility stuff
15:43:59 <bswartz> If we could trash the old driver and rewrite it, that would make my changes very easy
15:44:21 <bswartz> I don't know who would be affected by a backwards compatibilty break in LVM
15:45:04 <tbarron> ok lemme send an email out to openstack-discuss and see if we can flush out any lvm driver users
15:45:15 <tbarron> I know folks who use it for POCs and for
15:45:30 <tbarron> testing
15:46:00 <tbarron> like it was real handy for the manila-csi folks who needed an easy to deploy NFS driver
15:46:09 <tbarron> it's quite valuable
15:46:44 <tbarron> but I don't know people running production systems with it, mainly b/c if you're going to back the driver itself with
15:47:09 <tbarron> a robust and scalable filer then you probably just want to use the driver for that
15:47:49 <tbarron> jgrosso: please help me remember and we can test whether the library bug ganso found is present in bionic
15:48:01 <tbarron> That will help us judge urgency.
15:48:02 <bswartz> The LVM driver can be super valuable for testing
15:48:08 <jgrosso> tbarron ack
15:48:13 <bswartz> Even if nobody runs it in production
15:48:19 <tbarron> jgrosso: also to check with the community.
15:48:30 <tbarron> bswartz: +1, that's what I'm trying to say as well.
15:48:31 <jgrosso> tbarron ack
15:48:56 <jgrosso> https://bugs.launchpad.net/manila/+bug/1781127
15:48:57 <openstack> Launchpad bug 1781127 in Manila "Share groups created from snapshot can be created with different share group type" [Medium,In progress]
15:49:03 <jgrosso> last bug
15:49:12 <bswartz> And for my purposes, it's actually better if nobody runs it in production, because that makes it easier to improve
15:49:14 <tbarron> bswartz: but if noone uses it in producation we can consider your idea about doing the rewrite.
15:49:27 <jgrosso> opps jumped ahead :)
15:49:32 <tbarron> jgrosso: that's fine.
15:49:58 <bswartz> If we were to take the stance that it's not production ready, and that we won't support backwards compatibility with it because it's just for testing, that would free us up to remove the bad garbage
15:50:33 <bswartz> We never got a proper upgrade mechanism for volume drivers though so we end up dragging around legacy problems forever
15:50:42 * ganso likes when bad garbage can be removed
15:50:43 <bswartz> s/volume/share/
15:51:33 <tbarron> So w.r.t. 1781127 I agree that it's a bug but why is it even Medium priority?
15:51:42 <gouthamr> maybe we can add the helper and its unit tests and ask people to switch to it in Train? - no upgrade guarantees
15:52:02 <tbarron> Is it particularly harmful?  Maybe I'm missing something.
15:52:05 <gouthamr> we can deprecate and remove the old helper in the next release - meaning, they'l have to reapply their access rules
15:52:27 <tbarron> gouthamr: bswartz: yes
15:52:46 <bswartz> It's just that there's no way to preserve shares created by the old helper once you move to the new helper
15:52:55 <bswartz> If you delete all your shares before upgrading you'd be fine
15:53:01 <gouthamr> oh, i thought this just affected the exports
15:53:05 <ganso> if I am not mistaken, we would make use of the new ensure_shares mechanism zhongjun wrote to help in the NFS Helper transition
15:53:05 <tbarron> Dustin set this bug to High, I knocked it down to Medium, but honestly I'm not even seeing that it's medium.
15:53:27 <bswartz> gouthamr may be right
15:53:32 <tbarron> jgrosso: so please bring the previous bug up again in the next meeting.
15:53:42 <bswartz> I'm not sure how much state exists for unexported shares
15:53:45 <jgrosso> tbarron ack
15:53:46 <tbarron> hopefully we'll have some data
15:53:52 <tbarron> on deployments
15:53:52 <jgrosso> thanks all
15:54:03 * gouthamr we have 7 minutes no?
15:54:29 <bswartz> ganso: we *could* go an upgrade using such a mechanism but it would be a lot of work
15:55:03 <gouthamr> ganso: also the issue is, ANY config change triggers that mechanism and access rules will be reapplied by the driver?
15:55:07 <ganso> bswartz: yup, just getting rid of it is definitely easier
15:55:24 * bswartz is lazy
15:55:34 <tbarron> Anyone want to talk about 1781127 ?
15:55:35 <ganso> gouthamr: if we code the driver implementation of ensure_shares to do so, yes. I don't think it does it by default
15:55:36 * gouthamr only 5 minutes now
15:55:53 <gouthamr> ganso: ack - i'll take a look and assist tbarron in writing his email
15:56:01 <tbarron> gouthamr: you filed it.
15:56:06 <gouthamr> tbarron: yep
15:56:29 <tbarron> it's an API bug, right?
15:56:42 <gouthamr> tbarron: yes it is
15:56:58 <tbarron> does it deserve MEDIUM priority?
15:57:02 <gouthamr> tbarron: i think it's a MEDIUM, and a low-hanging-fruit
15:57:36 <tbarron> playing devil's advocate it seems pretty harmless and not likely to hit
15:57:58 <tbarron> but let's mark it low hanging fruit
15:58:29 <tbarron> If someone wants to work on this one, that would be great cleanup and
15:58:45 <tbarron> I'm sure gouthamr can give you tips is you want to consult with him.
15:58:50 <gouthamr> +1
15:59:03 <tbarron> Just assign it to yourself.
15:59:26 <tbarron> OK, we're out of time folks,
15:59:29 <tbarron> Thanks!
15:59:36 <tbarron> and see you in #openstack-manila
15:59:42 <tbarron> #endmeeting