15:00:26 <tbarron> #startmeeting manila
15:00:28 <openstack> Meeting started Thu Jun 13 15:00:26 2019 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:31 <openstack> The meeting name has been set to 'manila'
15:00:38 <bswartz> .o/
15:00:38 <carloss> hey! :)
15:00:43 <gouthamr> o/
15:00:45 <tbarron> courtesy ping: gouthamr xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso dviroel lseki carloss
15:00:50 <dviroel> o/
15:00:51 <ganso> hello
15:00:53 <toabctl> hi
15:00:55 <lseki> o/
15:01:10 <vhari> hi
15:01:20 <_erlon_> Hey
15:01:27 <tbarron> Agenda: https://wiki.openstack.org/wiki/Manila/Meetings
15:01:34 <tbarron> Hi all!
15:02:02 <amito> hey
15:02:21 <tbarron> looks like we've got a quorum
15:02:33 <tbarron> #topic announcements
15:03:06 <tbarron> I don't have any, just a reminder to review outstanding specs and new driver submissions.
15:03:14 <tbarron> Anyone else?
15:03:41 <tbarron> #topic launchpad spam
15:04:15 <tbarron> You may have noticed our bug topics and descriptions getting changed to adds for pharmaceuticals.
15:04:40 <tbarron> If you run into one of these it won't do any good to correct it.
15:04:43 <bswartz> #link https://en.wikipedia.org/wiki/Spam_(Monty_Python)
15:04:49 <tbarron> They'll just come back again.
15:04:54 <tbarron> whack-a-mole
15:05:10 <tbarron> bswartz: ty!
15:07:04 <gouthamr> Sir Can-A-Lot :'D
15:07:12 <tbarron> Instead, plese file a Question under the Answers tab on launchpad
15:07:34 <bswartz> Is this a problem canonical is working on addressing?
15:07:36 <tbarron> Here's an example
15:07:39 <bswartz> I imagine it affects all of LP
15:07:53 <tbarron> https://answers.launchpad.net/launchpad/+question/681282
15:08:21 <tbarron> bswartz: I don't know what Canonical is doing about the issue structurally but
15:09:02 <tbarron> there are folks working on Launchpad who pay attention to these reports and respond pretty quickly
15:09:22 <tbarron> They ban the user doing it and restore any bugs you tell them about.
15:10:00 <tbarron> There doesn't seem to be a good way to search for bugs that a particular user has polluted though.
15:10:30 <tbarron> So the best thing is to report as soon as we see so that spammers realize that manila folks are vigilant and
15:10:44 <tbarron> they won't find us to be a good playground.
15:11:10 <tbarron> Any questions/thoughts/further remarks on this?
15:11:32 <tbarron> OK, thanks in advance to everyone for helpling clean this stuff up.
15:11:57 <tbarron> #topic allowing toggling visibility of share types
15:12:04 <tbarron> gouthamr: you are up
15:12:12 <gouthamr> thanks tbarron
15:12:21 <gouthamr> #LINK: : https://review.opendev.org/#/c/661209/ (Spec: Add update share-type API to Share Types)
15:12:46 <gouthamr> i see haixin on #openstack-manila, but not here
15:13:16 <gouthamr> haixin's the owner of that spec, and therefore interested in the discussion here.
15:14:46 <bswartz> Errr
15:14:54 <bswartz> Why didn't we do this from the beginning?
15:14:59 <gouthamr> a question came up during the review of that spec, the proposers are seeking to add support to toggle the name, description and "is_public" attribute of share types
15:15:19 <bswartz> It seems we must have had a reason to not make that field mutable
15:15:26 <gouthamr> bswartz: yeah, seems like we missed it, i don't recall a discussion..
15:15:55 <tbarron> haixin: hello!
15:16:27 <gouthamr> private share types have share-type-access rules
15:16:32 <tbarron> we were just trying to remember why we didn't make this field mutable when it was implemented
15:17:14 <haixin> hello
15:17:19 <gouthamr> hey haixin
15:17:28 <vkmc> o/
15:17:38 <bswartz> I guess one concern is revoking access to shares that were previously public and in use by other tenants
15:17:40 <gouthamr> so as haixin suggests, we could safely allow setting private share types to public without deleting any of the accesses
15:17:56 <bswartz> Of course the is_public and the actual access rules are orthagonal
15:18:00 <haixin> https://review.opendev.org/#/c/661209/
15:18:14 * tbarron pretends he didn't notice vkmc sneaking in
15:18:39 * vkmc sits silently in the back seats
15:19:30 <gouthamr> bswartz: they are; and i did a quick test to confirm nothing really breaks.. we just don't allow retrieving/setting share type accesses for a public share type
15:19:50 <bswartz> Okay there aren't any problems coming to my mind
15:20:05 <bswartz> It just seems weird we didn't do it this way from the start
15:20:09 <gouthamr> well, what about when taking a public share type private
15:20:40 <gouthamr> users that lose access won't be able to see these share types any longer
15:21:02 <haixin> today i try to set share_type from public to private, then try some manila api, all normal
15:21:28 <gouthamr> haixin: nice thanks, i hadn't tested that..
15:23:04 <gouthamr> can't think of anything else being affected, besides the fact that it might be confusing to lose access to something and not be able to tell
15:24:52 <gouthamr> i.e., for a user without access, their existing shares will still refer to the now hidden share type... but they won't find that share type if they want to seek more details
15:26:17 <tbarron> gouthamr: the alternative of deleting the share type and making a new one like it that's private wouldn't be any better though
15:26:24 <haixin> at the database level, these shares have been associated with the share-type, and still keep the characteristics of the share-type, does not affect the other share operations.
15:27:15 <haixin> yes, that means the user without access, can not create share with this share type any more
15:27:34 <gouthamr> haixin: yeah true, today we allow share type extra-specs to be modified, and existing shares retain their older properties, so that's already a confusion we allow :)
15:27:49 <tbarron> gouthamr: right
15:28:13 <gouthamr> tbarron: ack, i see the need for the feature.. if they want to stop provisioning to a certain class of storage or take away rights to one or more projects
15:28:40 <gouthamr> quite helpful indeed to allow modifying the visibility
15:29:14 <tbarron> Maybe we should just make sure that the share type doc mentions that people need to be careful when changing anything significant about a share type b/c
15:29:32 <tbarron> pre-existing shares will use the definition from when they were created.
15:31:18 <tbarron> It seems like we have a consensus?  Anyone have further concerns about the change this spec proposes?
15:31:54 <tbarron> I don't hear any.
15:32:00 <gouthamr> not me, i like the idea of calling out the doc, and perhaps adding a hint on the UI that modifications will cause confusion to users
15:32:22 <tbarron> haixin and gouthamr thanks for the testing
15:32:24 <gouthamr> s/will/may - given we don't know how one treats share types
15:32:27 <haixin> i agree, tbarron
15:32:39 <tbarron> haixin: thanks for coming to this meeting, I know it's very late for you
15:32:48 * bswartz +1
15:33:04 <tbarron> we'll review the spec and I'm sure there will be some small issues that come up but
15:33:05 <haixin> it does not matter
15:33:09 <tbarron> this was the main thing.
15:33:44 <tbarron> And it probably saved a lot of back and forth in review to be able to talk it through synchronouly here.
15:34:06 <tbarron> #topic security services testing in tempest
15:34:14 <tbarron> gouthamr: you again
15:34:24 <gouthamr> thanks tbarron
15:34:36 <gouthamr> alright, this is an old bug
15:34:37 <gouthamr> #LINK https://bugs.launchpad.net/manila/+bug/1699856
15:34:38 <openstack> Launchpad bug 1699856 in Manila "Tempest tests missing adding Security service to share-network" [Medium,Triaged]
15:36:29 <gouthamr> there's currently no way to assign one or more security services to share networks created by the tests
15:36:58 <gouthamr> this limits testing for CIFS with a backend that supports security services
15:36:58 <bswartz> That sounds like just a limitation of our tempest code
15:37:10 <tbarron> bswartz: +1
15:37:43 <gouthamr> and perhaps other protocols too ^
15:37:46 <gouthamr> https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html#mapping-of-share-drivers-and-security-services-support
15:39:04 <gouthamr> ^ so that's all the backends that have testing limitations
15:39:12 * tbarron wonders if anyone has actually done kerberized nfs with netapp in manila
15:39:46 <gouthamr> iirc netapp uses a pre-created share network with a security service assigned to it as the common share network for all tempest tests
15:39:52 <gouthamr> as a workaround
15:40:12 <bswartz> tbarron: i've done keberized nfs with netapp, but never the manila piece
15:40:25 <gouthamr> that severely limits multi-tenancy testing, because on that backend, a share network will ever only need one share server
15:40:55 <tbarron> bswartz: i think in theory ganesha will do kerberized nfs but i've not tried
15:41:09 <bswartz> Well if the real goal is multitenant tesing, you only need multiple share networks. Security services aren't relevant there
15:41:11 <tbarron> side issue
15:41:40 <gouthamr> bswartz: NetApp/manila/CIFS won't work without Active Directory
15:41:55 <gouthamr> don't know if the other backends have that requirement
15:42:46 <gouthamr> as a fix: i feel we can at least have configuration options that allow assigning a configured security service to every share network tempest creates
15:43:23 <tbarron> gouthamr: so this would be a tempest config option, right?
15:43:51 <gouthamr> tbarron: yes (or options if necessary)
15:44:08 <tbarron> seems reasonable
15:44:32 * gouthamr thinks we have a DictOpt type to dump all security service data into one config option
15:44:39 <bswartz> Does it make more sense for tempest to do the configuration using tempest options for the values, or for the pre-tempest setup to do the configuration, and tell tempest what to use?
15:46:22 <gouthamr> tempest currently creates share networks when it needs them... so having a pre-created manila security service that can be configured as a tempest option would also work
15:46:44 <tbarron> bswartz: gothamr: hmm, tempest is sometimes run w/o our CI pre-tempest setup ...
15:46:47 <gouthamr> but, puts the burden on testers and CI hooks
15:47:11 <tbarron> and our hooks might not be the same as we convert legacy jobs?  not sure ...
15:48:01 <gouthamr> tbarron: ack, it's been harder to ask folks to automate things elsewhere where they use manila-tempest-plugin - it doesn't fit right with their way of doing things
15:48:27 <gouthamr> going by experience with RDO, tripleo-ci, downstream redhat CI, certification folks
15:48:59 <gouthamr> i.e., easy for us that we use pre-test-hooks to do all sorts of things :)
15:49:01 <tbarron> gouthamr: yeah and I think non-RedHat will have similar issues
15:49:38 <tbarron> so from that POV doing it for tempest plugin itself is the most portable
15:49:55 <gouthamr> +1
15:50:21 <gouthamr> okay, the real question now: would some one who maintains of the backends affected be kind enough to take this bug?
15:51:46 <ganso> lseki, dviroel, carloss: ^
15:51:55 <tbarron> gouthamr: that's sneaky, given the table you put up that means netapp, huawei, emc, or windows and only one of those is here today
15:51:58 <ganso> I think that question is mostly directed at you
15:52:11 * gouthamr finds a gif for ganso and himself
15:52:18 <tbarron> ganso: you are taking entirely too much fun with that
15:52:25 <ganso> tbarron: xD
15:52:46 <bswartz> So for the NetApp guys, this one really does interest us
15:53:20 <bswartz> But I'm not sure where the prioritiy is relative to other things
15:53:34 <jgrosso> Did I miss the bug portionof the program ? :)
15:53:51 <lseki> we need to check the priority among other stuff
15:53:53 <gouthamr> jgrosso: no man, i stole one from you
15:53:59 <jgrosso> what!
15:54:01 <jgrosso> :(
15:54:16 <jgrosso> I see how it is gouthamr
15:54:21 <bswartz> lseki: it's wouldn't be bad to take ownership, even if it won't get addressed for a little while
15:54:29 <tbarron> let's tag this one with the affected back ends at least
15:54:50 <gouthamr> tbarron: ack, will do..
15:55:04 <tbarron> and it would be great if a netapper would grab this one
15:55:23 <tbarron> we promise to keep jgrosso from hounding you about whey it's not fixed next week
15:55:35 <ganso> bswartz: in my experience taking ownership sometimes prevents other people from eventually taking ownership if you take a long time to work on it
15:55:43 <jgrosso> :)
15:55:54 <tbarron> #topic bugs
15:56:07 <tbarron> jgrosso: you can't just ask netapp for status on this one now
15:56:35 <tbarron> what else do you have for us?
15:56:45 <jgrosso> https://bugs.launchpad.net/manila/+bug/1707378
15:56:46 <openstack> Launchpad bug 1707378 in Manila "Quota usage value error in batch create share" [High,Incomplete]
15:56:57 <jgrosso> its old and HIGH
15:57:08 <dviroel> Done! Assigned 1699856 for me
15:57:45 <tbarron> dviroel: thanks
15:57:52 <bswartz> ganso: That's true
15:57:52 <tbarron> jgrosso: we didn't talk about this at PTG
15:57:58 <jgrosso> hmm ok
15:58:29 <jgrosso> should this be downgraded from HIGH or placed on a wishlist
15:59:24 <tbarron> jgrosso: we don't currently have downstream customers complaining about this bug
15:59:32 <jgrosso> sounds good
15:59:35 <tbarron> nor customer reports upstream but
15:59:48 <tbarron> presumably huawei hit this in their public cloud
16:00:11 <tbarron> you could probably set it to medium or low and if someone
16:00:22 <tbarron> has an issue maybe they can bring resources to the problem
16:00:26 <ganso> tbarron:  time check
16:00:30 <jgrosso> sounds good
16:00:34 <tbarron> but we're out of time
16:00:39 <jgrosso> ok
16:00:40 <tbarron> thanks everyone!
16:00:42 <jgrosso> thanks tbarron
16:00:45 <tbarron> #endmeeting