15:00:21 <gouthamr> #startmeeting manila
15:00:21 <openstack> Meeting started Thu May  9 15:00:21 2019 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <openstack> The meeting name has been set to 'manila'
15:00:31 <gouthamr> courtesy ping: xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso
15:00:37 <lseki> o/
15:00:38 <carloss> Hey :)
15:00:39 <ganso> hello
15:00:41 <gouthamr> hello o/
15:00:49 <gouthamr> tbarron is away, and i'm chairing today - my first in a long time so expect some clumsiness :)
15:01:08 <bswartz> .o/
15:01:15 <gouthamr> we'll wait a couple of minutes for quorum
15:01:16 <vhari> hi
15:01:21 <dviroel> o/
15:01:25 <amito> o/
15:01:40 <bswartz> Oh good we can trout slap the chair today
15:01:43 <bswartz> :-)
15:01:46 <gouthamr> :D
15:01:50 <gouthamr> #chair bswartz
15:01:51 <openstack> Current chairs: bswartz gouthamr
15:01:56 <bswartz> Doh!
15:01:58 <gouthamr> now we can
15:02:17 <gouthamr> #topic Announcements
15:02:38 <gouthamr> Welcome back, everyone that traveled to the mile high city
15:03:00 <gouthamr> and thanks everyone that joined us remote :)
15:03:07 <vkmc> o/
15:03:36 <gouthamr> we had a great PTG and Summit; and it felt good to be back to the old times personally
15:04:03 <bswartz> Did it feel like old times with the updated format?
15:04:11 <bswartz> That what I would have hoped for
15:04:52 <gouthamr> yes, felt as packed as BCN, which i recall was the last combined conference (Summit + Design Summit)
15:05:47 <gouthamr> the PTG seemed to have a good turn out, comparable to the exclusive event in Denver last cycle, although there were a few new projects represented
15:06:54 <gouthamr> we have a lot to follow up from the PTG ourselves - a day and a half seemed productive and discussions were well paced
15:06:59 <gouthamr> more on this later..
15:07:30 <gouthamr> in terms of announcements, I proposed the change we discussed at the PTG: A Parking lot for old unimplemented specs
15:07:35 <gouthamr> #LINK https://review.opendev.org/#/c/657894/
15:08:08 <gouthamr> found a few ones that we might want to move there, please take a look
15:08:53 <vkmc> like the "parking lot" term
15:09:10 <gouthamr> if you have a spec there that needs to be moved to the Train release and not the "unimplemented" section, please note it in review
15:09:26 <vkmc> do we want to clean up those specs? say, change the expected release and asignee fields
15:10:04 <gouthamr> vkmc: yes, the act of moving the specs out of the release specific folder should signify the former
15:10:23 <gouthamr> vkmc: however, i dunno if we should pop out the assignee/s field..
15:11:15 <gouthamr> vkmc: that is probably a good idea, however - we can use another field that suggests the design author, and leave the assignee field empty
15:11:55 <vkmc> gouthamr, yeah, I mean, in the blueprint you can see who proposed what
15:12:02 <vkmc> so the authorship remains the same
15:12:46 <vkmc> but... having the assignee field filled in might prevent people to take the blueprint and work on it
15:13:28 <gouthamr> true true... if the authors are available to consult, but not code, it might make sense for the new owner to reach out to them
15:13:52 * gouthamr labels himself design consultant, prints new business cards
15:14:25 <vkmc> :)
15:14:57 <gouthamr> so PTAL, everyone, and we'll take these discussions to the review
15:15:30 <gouthamr> #topic Summit (29 April 29-May 1) and PTG (May 2-4) summary, action items
15:15:52 <gouthamr> #LINK https://etherpad.openstack.org/p/manila-ptg-train
15:16:41 <gouthamr> alright, on this one, thanks to note takers, we have a decent summary against each topic and action items listed underneath
15:17:11 <gouthamr> we did not cover all the topics we had proposed, so we'll schedule those topics in our weekly meetings if the proposers can participate
15:17:37 <gouthamr> tbarron is working on an upstream summary, and will post one to the ML (openstack-discuss) soon-ish (TM)
15:18:02 <gouthamr> if he doesn't, vkmc and I'll channel him and do it anyway :)
15:18:21 <gouthamr> thank you NetApp folks (erlon, dviroel, lseki) for getting us AV support
15:18:52 <gouthamr> and thank you vkmc for hosting the bluejeans session for our remote attendees and for recording the whole thing
15:19:03 <vkmc> ++
15:19:10 <lseki> :-)
15:19:17 <dviroel> :)
15:19:20 <gouthamr> we'll plan on posting the recording along with the summary to the mailing list
15:19:50 <gouthamr> does anyone have anything to say about this $topic?
15:20:28 * gouthamr hears crickets, sees smiles, moves on :)
15:20:40 <gouthamr> #topic Train Schedule
15:20:47 <bswartz> #pun
15:20:55 <gouthamr> wee
15:21:29 <gouthamr> ooh, if you got lucky, you could get your own train whistle at the PTG and blow it on the corridors
15:21:40 <gouthamr> and attract annoyed faces :)
15:21:59 <bswartz> Heh
15:22:13 <bswartz> What is "train" a reference to?
15:22:27 <gouthamr> he asks ^
15:22:27 <bswartz> Is it the loud train near the PTG hotel?
15:22:32 <ganso> bswartz: the trains in denver close to the hotel
15:22:39 <bswartz> K
15:23:21 <gouthamr> tbarron flagged off a review for the manila release schedule here
15:23:22 <gouthamr> #LINK https://review.opendev.org/#/c/655667/
15:23:34 <vkmc> I think it was the only release for OpenStack that was named because everybody got nuts with the naming idea on the denver ptg 2018 feedback session
15:23:52 <gouthamr> it overlays the openstack release schedule with the manila project specific deadlines
15:24:30 <gouthamr> please visit that, and provide your reviews
15:24:58 <gouthamr> there's also our own tracking wiki
15:25:00 <gouthamr> #LINK https://wiki.openstack.org/wiki/Manila/TrainCycle
15:25:17 <gouthamr> it's only beginning to be filled
15:25:37 <gouthamr> PTAL (heh, GitHub PRs you ruined me)
15:26:22 <gouthamr> we'll track our work on that wiki page, so feel free to add your own work items, and status as we proceed through the release
15:26:40 <bswartz> vkmc: I think people couldn't resist the puns
15:27:05 <gouthamr> absolutely, hop on the choochoostack
15:27:32 <vkmc> bswartz, exactly, that made it special :)
15:27:35 <vkmc> haha
15:28:27 <gouthamr> from next week, we'll be the fare enforcement officers on this train, and check your statuses for the work on the wiki
15:28:49 <gouthamr> moving on..
15:28:55 <gouthamr> #topic Extend share when clients are connected (gouthamr)
15:29:12 <gouthamr> alright, that's me pinging me
15:29:50 <gouthamr> this could be a known issue for our veteran contributors who at one point or another worked with/on the generic driver
15:29:52 <gouthamr> #LINK https://review.opendev.org/#/c/531568/
15:30:26 <gouthamr> ^ is a scenario test - a test case suggested by vponomaryov
15:30:47 <bswartz> This is a good one
15:30:49 * gouthamr misses the dude
15:31:13 <bswartz> The dude abides
15:31:24 <bswartz> What's the issue here though?
15:31:27 <bswartz> Does it not work?
15:31:54 <gouthamr> so the problem here is the mount becomes stale after issuing an extend API to manila
15:32:01 <gouthamr> the mount inside the nova VM*
15:32:22 <gouthamr> the test logs from a previous CI run are here:
15:32:22 <gouthamr> #LINK http://logs.openstack.org/68/531568/26/check/manila-tempest-dsvm-scenario/1ea651d/logs/testr_results.html.gz
15:32:41 <gouthamr> the error of interest is "dd: failed to open '/mnt/t3': Stale file handle"
15:33:22 <bswartz> Yeah that would be expected for some drivers
15:33:42 <gouthamr> nirg22, who is implementing this test case for us is confused, because it works on the other first party drivers - LVM and ZFSOnLinux
15:33:45 <bswartz> We were not strict about the expectation on the client side, because we have no way to prevent this kind of problem
15:34:11 <bswartz> Sometimes a resize will require a remount, and sometimes it won't
15:34:23 <bswartz> We don't tell the user which situation they're in
15:34:44 <bswartz> They just have to know, or learn empircally
15:34:45 <gouthamr> wont shares from the generic driver always require a remount?
15:34:51 <bswartz> Yes
15:34:59 <bswartz> But the user doesn't know which driver they've got
15:35:04 <gouthamr> true
15:35:31 <gouthamr> i wonder if we can use the "online extend" capability in the cinder API
15:35:39 <gouthamr> although it comes with its own caveats
15:36:46 <bswartz> Does LVM suffer from this at all?
15:37:08 <bswartz> Maybe the answer is to stop using Generic
15:37:27 <gouthamr> bswartz: nope, LVM passes the test: http://logs.openstack.org/68/531568/26/check/manila-tempest-minimal-dsvm-lvm/130046f/logs/testr_results.html.gz
15:37:42 <gouthamr> "manila_tempest_tests.tests.scenario.test_share_extend.TestShareExtendNFS" is the test to look for there ^
15:38:18 <ganso> gouthamr: generic is cinder using LVM underneath, but it happens because here we need to use resize2fs
15:38:38 <ganso> wait a min, LVM also uses resize2fs
15:39:12 <gouthamr> ganso: so the client (generic driver share server) needs to issue a resize2fs?
15:39:29 <gouthamr> ganso: or do you mean this is if we were to use the new online-extension API
15:39:42 <ganso> gouthamr: I'd say it would need to whatever the LVM is doing, because essentially they would work the same in this situation
15:39:59 <bswartz> No
15:40:03 <ganso> gouthamr: s/would need to/would need to do
15:40:08 <bswartz> Cinder is not the same as LVM
15:40:29 <bswartz> The problem is the block device resize, not the filesystem resize
15:40:37 <bswartz> LVs can be resized online
15:40:52 <ganso> gouthamr: what would be the caveat of cinder online extend?
15:41:54 <gouthamr> ganso: the limitations around where it can be used - not all cinder backends support extending attached volumes iirc, and not all nova hypervisors support it either (only libvirt driver has support last i looked, but i could be wrong)
15:42:40 <gouthamr> bswartz: on stopping the use of the generic driver :) - this is the only job where scenario tests are running with DHSS=True
15:43:05 <gouthamr> bswartz: we did take an AI to run scenario tests in the container job...
15:43:31 <ganso> gouthamr: what if we make it configurable? the main importance of the generic driver is in the gate or POC deployments
15:43:35 <bswartz> If we can use cinder online resize we might be able to work around this issue
15:43:45 <bswartz> But the deeper question is what guarantees we make to our end users
15:44:02 <gouthamr> ack
15:44:12 <ganso> gouthamr: if a cloud is using the generic driver in production with a backend that wouldn't work with online extend, just disable it and we fallback to the other problem (if there is no other way to solve the problem)
15:44:14 <bswartz> If we want to guarantee online resizes, then certain drivers may not be able to fulfill the contract
15:44:51 <bswartz> If we don't want to guarantee online resizes, then the test needs to accommodate the drivers that can't, which probably requires communicating some extra information at the API level
15:44:52 <gouthamr> ganso: yes, that would be a good direction to take - unless we want to extract the cinder pools information, and check for the capability atleast from cinder's side and fail faster
15:45:32 <ganso> gouthamr: that is a good idea as well, but the history that I know of online extend capability is a messy one
15:45:40 <ganso> gouthamr: it was enabled by default for everyone
15:45:41 <gouthamr> bswartz: makes sense, a new capability flag that defaults to True?
15:45:59 <ganso> gouthamr: and then the vendors that do not support it need to disable
15:46:37 <bswartz> ganso: We have to make the first decision before we discuss the mechanism for the second
15:46:56 <ganso> gouthamr, bswartz: Why a capability and not a config option just for the generic driver?
15:47:24 <gouthamr> ganso bswartz: ^ yeah, we don't know what other drivers suffer this problem
15:47:27 <bswartz> The question is, can users assume nondisruptive resize or not
15:47:46 <bswartz> If no, then how do they find out if it's disruptive or not
15:48:14 <bswartz> I kinda like assuming nondisruptive
15:48:29 <bswartz> But we should figure which drivers that might break
15:48:45 <ganso> the scenario test should point that out
15:49:06 <ganso> problem is 3rd parties are not running scenario tests
15:49:24 <gouthamr> +1 the test case looks good right now, and everyone needs to be running it and testing the various backends we have
15:49:29 <ganso> so the only way to obtain this information is mailing list?
15:49:55 <gouthamr> ganso: yes, sadly, we have one or two AIs about scenario tests from the PTG
15:50:09 <gouthamr> part of the problem is our own inconsistent testing in the first party drivers
15:50:18 <bswartz> Well with this new scenarios test we are de-facto assuming that resizes are nondisruptive
15:50:41 <bswartz> So maybe we just merge it, fix (or kill) the generic driver, and see what other drivers fail the scenario test
15:51:14 <bswartz> Because the status quo is to not tell users if the resize is disruptive
15:51:21 <gouthamr> i wonder if we can try...except and log a warning saying a remount was required to pass the test
15:51:38 <ganso> gouthamr: what about the user experience then?
15:51:44 <bswartz> We can later choose to relax the contstraints by communicating about disruptive resizes if we decide we want to continue to allow them
15:51:45 <ganso> gouthamr: and the user's expectations
15:52:29 <bswartz> ganso: My suggestion leaves things unchanged, user-experience-wise, until we decide to relax things.
15:52:45 <ganso> LGTM
15:53:20 <gouthamr> ganso: although i will take an AI to bring this discussion on the ML for the wider audience
15:53:42 <gouthamr> i know that NetApp and Dell/EMC want to run our scenario tests
15:53:56 <gouthamr> would be nice to have all the other drivers do the same
15:54:29 * gouthamr recalls a bug downstream that vhari pointed out regarding a manila/CIFS scenario test
15:54:44 <jgrosso> gouthamr I want to run your scenario tests also !
15:55:07 <gouthamr> jgrosso++
15:55:18 <vkmc> jgrosso++
15:55:23 <vhari> tempest_manila_plugin.tests.scenario.test_shares_scenario.SharesScenarioTest.test_scenario_1
15:56:34 <gouthamr> vhari: that one looks like an internal test..
15:56:42 <gouthamr> i'm thinking about this one: https://bugzilla.redhat.com/show_bug.cgi?id=1703185
15:56:44 <openstack> bugzilla.redhat.com bug 1703185 in python-manila-tests-tempest "Tempest manila test fail" [Unspecified,New] - Assigned to rhos-maint
15:57:03 <vhari> here is the CIFS one: manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsCIFS)
15:57:11 <gouthamr> ack, ty :)
15:57:16 <vhari> :D
15:57:34 <gouthamr> alright, we're almost out of time... this was a great discussion, and we have some AIs
15:58:22 <gouthamr> #action: suggest next steps for the scenario test regarding the generic driver failure, maintain current user experience/expectations
15:58:50 <jgrosso> Thank you Goutham I don't have anyone new bugs to discuss today !
15:59:01 <jgrosso> :)
15:59:13 <jgrosso> be prepared next week!
15:59:16 <gouthamr> #action: raise issue on the ML, point to the scenario test - propose a solution to provide a consistent user experience by claiming support (or lack thereof) of online/nondisruptive extensions
15:59:26 <gouthamr> cool, ty jgrosso
15:59:32 <gouthamr> #topic Open Discussion
15:59:34 <bswartz> Thx for chairing gouthamr
15:59:37 <jgrosso> gouthamr: welcome
15:59:39 <gouthamr> we have 1 minute :)
15:59:59 <gouthamr> anything anyone wants in the meeting logs before we all retire to #openstack-manila?
16:00:15 * bswartz reaches for large trout
16:00:18 <gouthamr> oh ho, we're out of time :)
16:00:24 <gouthamr> #endmeeting