15:01:01 <tbarron> #startmeeting manila
15:01:02 <openstack> Meeting started Thu Jul 11 15:01:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:05 <openstack> The meeting name has been set to 'manila'
15:01:06 <bswartz> .o/
15:01:09 <lseki> hi
15:01:10 <carloss> hey :)
15:01:12 <dviroel> o/
15:01:14 <ganso> hello
15:01:27 <tbarron> courtesy ping: gouthamr xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso dviroel lseki carloss
15:01:32 <vkmc> o/
15:01:33 <vhariria> hi
15:01:42 <xyang> hi
15:02:01 * tbarron waits a minute
15:02:27 <amito> Hello
15:02:58 <tbarron> ok, let's get started, Hi everyone!
15:03:06 <tbarron> Agenda:
15:03:19 <gouthamr> o/
15:04:02 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:04:18 <tbarron> #topic announcements
15:04:28 <tbarron> Anyone have any?
15:04:51 <tbarron> I'll just remind that M2 is in two weeks.
15:05:30 <tbarron> #topic Our Work - specs
15:05:45 <tbarron> And M2 is our spec approval deadline
15:06:00 <tbarron> We have two specs not merged yet.
15:06:10 <tbarron> Both seem to be quite close.
15:06:30 <tbarron> #LINK: https://review.opendev.org/#/c/644218
15:06:46 <tbarron> This is the OSC client integration spec
15:07:15 <tbarron> I've been watching this one and re-reading it as it has made progress
15:07:35 <tbarron> Thanks to vkmc for getting it started and to
15:07:55 <tbarron> enriquetasso and s0ru for continuing the work
15:08:20 <tbarron> And to Goutham for lots of good review.
15:08:20 <s0ru> tbarron, i'm making my best effort
15:08:31 <s0ru> o/
15:08:48 <tbarron> I think we're probably ready to merge this and get the implementation under way.
15:09:01 <tbarron> Does anyone else want to review this one first?
15:09:54 <tbarron> OK, I plan to workflow this one later today then.
15:09:57 <s0ru> gouthamr++ , thanks :)
15:10:29 <tbarron> #link https://review.opendev.org/#/c/609537
15:10:57 <tbarron> This is dviroel's spec for creating share from snapshots in another pool or back end
15:11:10 <tbarron> It's had lots of good review from gouthamr
15:11:26 <dviroel> Yes, thanks gouthamr!
15:11:29 <gouthamr> s0ru: you're welcome - imo we've settled some huge issues, but there may be things that will need to change further; we'll review that during implementation
15:11:40 <tbarron> I'm of the opinion that this is about ready to merge and we can ^^^
15:11:47 <gouthamr> +1
15:11:56 <tbarron> bswartz: do you want to give this one another read?
15:12:30 <s0ru> gouthamr, sure!
15:12:41 <bswartz> tbarron: sure
15:13:15 <tbarron> bswartz: thanks, if you're ok with it then unless someone else says they want to do a review we'll go ahead and merge it
15:13:26 <bswartz> Will do
15:13:27 <tbarron> dviroel: nice work!
15:13:41 <dviroel> tbarron: thanks
15:13:57 <tbarron> #topic Cross-team cycle goals
15:14:07 <tbarron> gouthamr added this topic
15:14:30 <tbarron> PDF doc creation
15:14:44 <tbarron> #link https://governance.openstack.org/tc/goals/train/pdf-doc-generation.html
15:14:57 <tbarron> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007301.html
15:15:21 <tbarron> I thought this one would be more or less done centrally and we wouldn't have a lot to do but ...
15:15:26 <tbarron> gouthamr: you're up
15:15:32 <gouthamr> ack, ty tbarron
15:16:08 <gouthamr> so, i can't open the ML link for some reason, but while i try:
15:16:48 <gouthamr> we need a volunteer to start this goal for us
15:17:53 <tbarron> Yeah that email from the docs PTL solicits volunteers to help tweak our docs so that they can be convereted to PDFs
15:18:23 <gouthamr> each project has its own documentation, and may use different sphinx extensions - so this makes it harder for a central doc team to drive this effort
15:18:52 <gouthamr> so the sooner we get started, the easier it will get; is the message i get
15:19:57 <tbarron> the team working on this includes some very high quality people: tosky, johnsom, bogdando, amotoki
15:20:15 <tbarron> And donny Davis whose nick I don't know
15:20:18 <tbarron> from nova
15:20:20 <gouthamr> there are some patches from modred and bogdando that can be used as starting points
15:21:14 <tbarron> So if you have an interest in this, let me know.
15:21:44 <gouthamr> #LINK: https://review.opendev.org/#/q/status:open+topic:build-pdf-docs
15:23:02 <tbarron> gouthamr: do you have more on this topic?
15:23:12 <gouthamr> tbarron: nope..
15:23:21 <tbarron> gouthamr: thanks
15:23:37 <tbarron> #topic bugs
15:24:03 <tbarron> jgrosso is on vacation so vhariria you are up, and thanks for filling in
15:24:06 <vhariria> hey all
15:24:51 <vhariria> we don't have any new open bugs
15:25:07 <vhariria> can look at a few open sev MED bugs
15:25:16 <vhariria> https://etherpad.openstack.org/p/manila-bug-triage-pad
15:25:26 <vhariria> https://bugs.launchpad.net/manila/+bug/1833766
15:25:27 <openstack> Launchpad bug 1833766 in Manila "Microversions tempest tests expect no other "Vary" headers" [Medium,New] - Assigned to Liron Kuchlani (lkuchlan)
15:26:02 <gouthamr> ^ this one is fixed with https://review.opendev.org/668622
15:26:29 <tbarron> cool
15:26:32 <vhariria> gouthamr: yes, it was merged
15:27:14 <gouthamr> yeah, for downstream consumers, i'm requesting a release here: https://review.opendev.org/#/c/670172/
15:27:46 <vhariria> gouthamr: I will update the bug ty
15:28:37 <vhariria> https://bugs.launchpad.net/manila/+bug/1617490
15:28:37 <openstack> Launchpad bug 1617490 in Manila "[doc] Add neutron driver for binding" [Medium,New]
15:29:22 <vhariria> this one is unassigned - should it be assigned to Nabanita Dash for follow up?
15:29:42 <tbarron> vhariria: yes, and we can adjust its milestone
15:29:59 <tbarron> M3 stein would be appropriate
15:30:11 <vhariria> tbarron: will do
15:30:25 <vhariria> https://bugs.launchpad.net/manila/+bug/1822415
15:30:27 <openstack> Launchpad bug 1822415 in Manila "[zfsonlinux] job migration tests are failing" [Undecided,New]
15:31:06 <vhariria> this one's been out there for a while - any recent results on this one?
15:33:16 <tbarron> vhariria: not that I know of, I can look to see if we're still seeing the issue
15:33:56 <gouthamr> i look at this job from time to time, but haven't seen a bulk failure on teh migration tests as the bug indicates.. maybe we can query the infra grafana dashboard
15:34:15 <gouthamr> this driver implements driver-optimized migration; so it's not exercising the data service
15:35:24 <gouthamr> error however looks similar to
15:35:25 <gouthamr> https://bugs.launchpad.net/manila/+bug/1557636
15:35:26 <openstack> Launchpad bug 1557636 in Manila "ZFSonLinux fails to unmount dataset sometimes" [Low,Fix released] - Assigned to Ben Swartzlander (bswartz)
15:35:42 * bswartz ducks
15:36:00 <bswartz> This is a thorny one
15:36:12 <vhariria> tbarron / grouthamr: thanks .. any feedback is helpful to decide next steps
15:36:31 <bswartz> I'm not sure how to fix the ZFS unmount problems
15:37:15 <gouthamr> "From time to time, we see error in ZFSonLinux CI where some share cannot be unmounted because it is, as CI thinks, already unmounted." -> this might still be happening, bswartz?
15:39:01 <bswartz> Could be
15:39:25 <gouthamr> vhariria: ack, yeah.. low seems a good priority to assign to this one, since no-one has reported it outside of the CI jobs
15:39:27 <bswartz> The original problem was very rare, and because I never fully understood it, we might never have added any code to work around it
15:39:56 <vhariria> gouthamr: will do
15:40:00 <gouthamr> these API tests don't try accessing the share on the data path
15:40:34 <vhariria> any more thought on this one?
15:40:40 <gouthamr> so possible that the share creation had some issue - i.e., setting up the mount
15:40:53 <gouthamr> nope, just spitballing - tbarron
15:41:03 <gouthamr> proposed a change to run the tests again
15:41:03 <vhariria> :)
15:41:25 <vhariria> k .. one more to look at
15:41:25 <tbarron> yeah let's get a fresh look, thanks for bringing this one up vhariria
15:42:14 * gouthamr although we might have gotten a first look to the ipv6 implementation of the ceph-fs driver in there :D
15:42:23 <vhariria> tbarron: sure thing
15:42:44 <tbarron> gouthamr: heh
15:42:47 <tbarron> will fix
15:43:02 <tbarron> rough stuff that
15:43:21 <vhariria> 3 2 1 ... https://bugs.launchpad.net/manila/+bug/1607422
15:43:23 <openstack> Launchpad bug 1607422 in Manila "[api] manila API returns HTTP 404 NotFound even when the resource that it raised the error for is not part of the URI" [Medium,New]
15:44:06 <vhariria> any chance this is dup of or related to bugs jgrosso suggested?
15:44:12 <gouthamr> ... in the general category of API inconsistencies ...
15:44:53 <gouthamr> vhariria: one of them is related
15:45:01 <gouthamr> i'll copy over the comment from that bug here: https://bugs.launchpad.net/manila/+bug/1607405/comments/3
15:45:03 <openstack> Launchpad bug 1607405 in Manila "[API] not all manila APIs report asynchronous resource creation with the correct response code" [Wishlist,Opinion]
15:45:38 <gouthamr> "It seems too small a gain to go fix past mistakes to adhere to HTTP standards. We can accept that our APIs are not perfect, and ensure (as we've been doing since OpenStack has had an API-SIG, and we nominated a liaison for it) that we don't repeat these mistakes."
15:45:46 <vhariria> gouthamr: ack ty
15:45:47 <gouthamr> echo bswartz
15:46:06 <bswartz> :-p
15:46:39 <bswartz> Is that something I said before?
15:46:46 <bswartz> It sounds like something I would say
15:47:49 <gouthamr> hehe, yes :)
15:48:25 <gouthamr> it's true though, none of our new APIs have inconsistencies (TM)
15:49:14 <tbarron> so we're going to go with WON'T FIX ... ?
15:49:25 <tbarron> not challenging that, just being explicit
15:49:36 <gouthamr> tbarron: good point, probably better than wishlist
15:49:49 <tbarron> less kicking the can
15:49:59 <gouthamr> making changes will require microversion bumps; and this bug is too general..
15:50:08 <tbarron> agree
15:50:12 <vhariria> agreed
15:50:24 <tbarron> other fish to fry
15:50:31 * tbarron is working on his cliches today
15:50:46 * gouthamr goes buys halibut
15:50:54 <tbarron> vhariria: let's look at https://bugs.launchpad.net/manila/+bug/1831983 for a minute
15:50:55 <openstack> Launchpad bug 1831983 in Manila "Manila 8.0.0 stein GPFS Driver index error" [Undecided,New]
15:51:04 <bswartz> so many fish references.....
15:51:09 * gouthamr wonder who works for IBM here
15:51:15 * bswartz resists urge
15:51:42 <tbarron> for i in list; do /me slaps $i with trout; done
15:52:40 * gouthamr hey!
15:52:45 <tbarron> so it looks like these folks are getting output from gpfs back end with escaped newlines?
15:53:25 <vhariria> interesting!
15:53:38 <tbarron> so that split() isn't finding regular whitespace and they need to supply '\\n'
15:54:07 <tbarron> I'm inclined to ask them if they want to propose their fix as a patch.
15:54:32 <tbarron> There's a chance that someone else with a gpfs back end has a different software version on the back end or something
15:54:39 <tbarron> and the change would break them.
15:55:17 <tbarron> But unless we know specific gpfs back end customers to ask, I think maybe inviting these folks to submit a pathc
15:55:26 <tbarron> and merging it would be the right thing to do.
15:55:29 <tbarron> Thoughts?
15:55:31 <vhariria> may need more testing to prove setup variances
15:55:49 <tbarron> vhariria: the issue is that *we* have no way to test
15:56:07 <tbarron> vhariria: need a gpfs back end
15:56:33 <tbarron> vhariria: and there are no maintainers for that back end currently in the manila community
15:56:59 <vhariria> tbarron: ack
15:57:12 <tbarron> OK, hearing no objection I'll invite them to submit a patch.
15:57:30 <tbarron> #topic open discussion
15:58:05 <tbarron> ok, thanks everyone!
15:58:15 <tbarron> See you in #openstack-manila !!
15:58:20 <tbarron> #endmeeting