15:00:24 <ganso> #startmeeting manila
15:00:25 <openstack> Meeting started Thu Oct 12 15:00:24 2017 UTC and is due to finish in 60 minutes.  The chair is ganso. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'manila'
15:00:39 <ganso> hello
15:00:42 <tbarron> hi
15:00:45 <toabctl> hey
15:00:45 <vkmc> hi
15:00:53 <zhongjun> Hi
15:00:55 <dustins> \o
15:01:21 <ganso> #topic announcements
15:01:34 <gouthamr> o/
15:01:44 <ganso> today I am chairing the meeting for bswartz
15:01:52 <ganso> he is in an airplane right now and unable to chair the meeting
15:02:04 <gouthamr> thanks ganso, be fair.
15:02:32 <ganso> bswartz's only announcement was that we are 1 week away from spec freeze
15:02:37 <jungleboyj> @!
15:02:37 <_pewp_> jungleboyj (ه’́⌣’̀ه )／
15:02:46 <jprovazn> hi
15:03:16 <ganso> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:35 <ganso> #topic Manila Driver Maintainers and the DriverLog (dustins)
15:03:40 <ganso> dustins: you're up
15:03:48 <dustins> thanks, ganso
15:04:21 <dustins> So I've been going through the DriverLog and looked at the spreadsheet that bswartz had to see who was maintaining what in Manila
15:04:31 <dustins> And both are pretty out of date
15:05:04 <dustins> We want to have all of our drivers in the DriverLog to match the other OpenStack projects
15:05:55 <dustins> So if you are a driver maintainer or know someone who is, could you get in touch with me and get me your driver, email, and launchpad ID so I can add it to the log
15:06:19 <gouthamr> dustins: fixed ours.. https://review.openstack.org/#/c/511372/
15:06:31 <dustins> I'll send an email out to the Manila list to ping folks who might not be here
15:06:43 <dustins> gouthamr: You rock \m/
15:07:00 <gouthamr> should community supported drivers be there?
15:07:03 <dustins> But that's all I have on this, I want to have this so that I know who to poke when bugs come in upstream
15:07:21 <dustins> gouthamr: Right now, only the LVM driver is
15:07:38 <dustins> The Generic, Containers, and ZFS ones are not
15:08:04 <ganso> dustins: and Ceph?
15:08:23 <dustins> The CephFS drivers are not in the driver log
15:08:35 <tbarron> dustins: we'll need to fix that
15:08:40 <tbarron> dustins: cephfs
15:09:13 <tbarron> likely we should have a driverlog update be part of qualifying a new driver?
15:09:31 <dustins> Right now the only drivers that are in the driver log are: Dell EMC VNX, Unity, VMAX, HDS HNAS, HPE 3PAR, Huawei, IBM GPFS, LVM, NetApp Unified, Quobyte, Tegile, and Windows SMB
15:09:34 <ganso> tbarron: sounds like a good idea to keep the driverlog updated
15:09:36 <dustins> tbarron: Most likely
15:09:55 <gouthamr> tbarron: +1
15:10:09 <tbarron> i think we have devref on driver requirements that we can update
15:10:50 <dustins> Yeah, we should do that
15:11:10 <tbarron> i'll take the AI to make sure we check that and add a blurb as appropriate
15:11:18 <ganso> dustins: do you know which drivers are not in the driverlog?
15:11:25 <dustins> ganso: I do!
15:12:34 <ganso> dustins: besides the first party ones you already mentioned
15:12:44 <dustins> CephFS Native, CephFS-NFS, Generic, GlusterFS, GlusterFS Native, GlusterFS Heketi, Dell EMC Isilon, HDS HSP, LXD Driver, Nexenta, Oracle ZFSSA, and ZFSOnLinux
15:12:49 <dustins> Those are not in the driverlog
15:13:02 <tbarron> Is there a convention for indicating in driverlog that a driver has no current maintainers?
15:13:06 <dustins> Whether it be because they're not supported anymore or they're just not there
15:13:26 <dustins> tbarron: I don't know! I'll have a look to see
15:13:45 <dustins> As much fun as looking at a 5000+ line JSON file can be :)
15:13:56 <tbarron> :)
15:14:01 <ganso> tbarron: if the driverlog is a go-to place to know which drivers exist, then I believe all existing drivers should be there, but marked as unmaintained if that's the case
15:14:06 <gouthamr> and probably the new drivers from the past few releases... MapRFS, Veritas, QNAP and such..
15:14:43 <dustins> Yeah, the list I have is from stuff in the driver log + stuff from bswartz's sheet
15:14:44 <ganso> tbarron: s/which drivers exist/which drivers exist upstream
15:14:52 <zhongjun> How to deal with the driver never has a maintainer
15:15:02 <gouthamr> like which one zhongjun?
15:15:37 <ganso> dustins: a list of existing drivers could be compiled from the upstream code
15:15:48 <tbarron> ganso: +1, if there's a way to do it in driverlog ...
15:16:02 <zhongjun> zfsonlinux?
15:16:27 <tbarron> well that one used to have a maintainer, at least unofficially :)
15:16:29 <gouthamr> zhongjun: that's a community driver, maintainers are on #openstack-manila and probably defaulting to PTL
15:16:34 <ganso> dustins: the capability support matrix also helps with that, in the past we have been enforcing new drivers to update that document
15:16:57 <ganso> zhongjun: all first party drivers are maintained by the community
15:17:16 <dustins> ganso: Right, it'll be good to add anything that's on that that isn't already in my list
15:17:42 <tbarron> ganso: to the extent they are maintained ..... :)
15:18:08 <ganso> anything else on this topic?
15:18:41 <ganso> alright, moving on
15:18:47 <ganso> #topic Important Manila Bugs (dustins)
15:18:53 <ganso> dustins: you're up again
15:19:35 <dustins> So this one, I started going through the Manila bugs in Launchpad
15:19:46 <dustins> I started with the Critical ones that are still outstanding
15:19:57 <dustins> #LINK https://etherpad.openstack.org/p/manila-bug-triage-pad
15:20:05 * dustins hopes he did the link right
15:20:28 <vkmc> works for me dustins :)
15:20:43 <dustins> This should (hopefully) be pretty easy to go through
15:21:06 <dustins> The first one has to do with the changes in Tempest and how we get Credentials for our tests
15:21:38 <dustins> We had a fix submitted upstream, but it was contingent on another bug being fixed as well
15:21:49 <gouthamr> Yogi1_:  https://bugs.launchpad.net/manila/+bug/1531049 looks like something you guys were hitting, can you confirm?
15:21:50 <openstack> Launchpad bug 1531049 in devstack-plugin-glusterfs "Devstack stop supporting Tempest deprecated cred options" [Critical,In progress] - Assigned to Ramana Raja (rraja)
15:22:05 <gouthamr> on the bug...
15:22:16 <dustins> And that bug referenced has now been fixed, so is this something that we need to just finish up on
15:22:43 <dustins> Possibly as part of our ongoing "make Tempest more better" efforts?
15:23:07 <ganso> dustins: yes
15:23:28 <ganso> dustins: I think it will be a good idea to go through the list and ask for volunteers at the end
15:23:46 <dustins> ganso: Sounds good to me, so moving along then :)
15:24:20 <dustins> #LINK https://bugs.launchpad.net/manila/+bug/1595234
15:24:22 <openstack> Launchpad bug 1595234 in Manila "tempest plugin in mitaka branch is broken" [Critical,Fix committed] - Assigned to Valeriy Ponomaryov (vponomaryov)
15:24:38 <tbarron> I don't think we're going to fix a mitaka-only issue at this point.
15:24:45 <dustins> This one shows that a fix has been committed, but not released yet
15:25:05 <tbarron> oh
15:25:18 <dustins> I remarked that maybe this is because there isn't an automated mechanism for showing that a fix has been released for an old version
15:25:26 <tbarron> well if it's not released it's not going to be, that branch was retired
15:25:33 <dustins> Since this has been in fix committed since last June
15:26:02 <tbarron> since june 2016
15:26:14 <dustins> tbarron: Sounds like we can close this, then
15:26:28 <tbarron> dustins: +1
15:26:33 <dustins> tbarron: Indeed, so over 16 months :)
15:26:54 <dustins> #LINK https://bugs.launchpad.net/manila/+bug/1629726
15:26:59 <openstack> Launchpad bug 1629726 in Manila "recompiled pycparser 2.14 breaks Cinder db sync and Nova UTs" [Critical,Confirmed] - Assigned to monika (monikaparkar25)
15:27:26 <gouthamr> darn, critical
15:27:28 <dustins> This one has someone assigned to it, but there has been no recent activity
15:27:33 <Yogi1_> gouthamr I think during OSP certification, we had a problem where we had to manually add the creds...I haven't looked at the above bug though
15:27:44 <dustins> And of note, it was marked as invalid in Cinder
15:27:59 <gouthamr> dustins: was a gate bug... and the library was fixed
15:28:23 <dustins> gouthamr: So this one's done?
15:28:32 <dustins> And likely has been for a while :)
15:28:36 <gouthamr> dustins: yes, marked it "fix released", just like the other projects
15:29:10 <tbarron> gouthamr: nice, thx
15:29:11 <dustins> Oh, I was like "man, when did that happen" and then looked and it said "15 seconds ago" :D
15:29:28 <dustins> gouthamr, quick on the draw
15:29:38 <gouthamr> Yogi1_: hmmm, probably unrelated then.. we do know that dynamic credentials in manila are broken, i thought that was the same bug...
15:29:42 <dustins> Alright, and lastly...
15:29:53 <dustins> #LINK https://bugs.launchpad.net/manila/+bug/1619788
15:29:54 <openstack> Launchpad bug 1619788 in Manila "Share migration does not allow_access before migration_complete" [High,In progress] - Assigned to Rodrigo Barbieri (rodrigo-barbieri2010)
15:29:55 * gouthamr has an open-discussion topic now.
15:30:20 <ganso> dustins: that one is deprecated
15:30:22 <dustins> So this was originally targeted for Ocata-1, which was September of last year
15:30:41 <gouthamr> dustins: looks like someone moved that from Triaged to "in-progress" :)
15:30:46 <dustins> ganso: Yeah, and it looks like it was taken out of a complete state by someone unfamiliar
15:31:19 <gouthamr> dustins: i fixed that... unassigned ganso..
15:31:27 <ganso> dustins: yea, probably someone looking for bugs to fix
15:31:40 <gouthamr> there's an explanation in the bug about the triage.. that's probably all we need..
15:31:46 <ganso> we discussed that bug in one of the weekly meetings and decided we do not want to allow access to shares during migrations
15:32:05 <dustins> ganso: Yeah, I thought that the discussion around this sounded familiar
15:32:49 <dustins> So it looks like this one's all set then, yeah?
15:32:50 <tbarron> so status is still triaged, should we close with explanation?
15:33:05 <gouthamr> tbarron: triaged doesn't mean closed?
15:33:18 <dustins> gouthamr: AFAIK it does not
15:33:34 <gouthamr> dustins: yeah, probably "Won't Fix" is a better state then?
15:33:37 <dustins> gouthamr: Could do Won't Fix
15:33:41 <tbarron> ack
15:33:48 <gouthamr> dustins: +1 good with that..
15:33:54 <ganso> yes, seems like more appropriate  status for this bug
15:34:00 <dustins> Agreed
15:34:16 <tbarron> triaged in systems I know mean that initial screening has been done and priority/severity assigned
15:34:16 <ganso> alright
15:34:33 <dustins> That's all I have for this week, I'm gonna start going through the other ones next week to go over at the next one
15:34:44 <tbarron> so how many of these are still alive?
15:34:46 <tbarron> one?
15:34:48 <gouthamr> dustins: thanks +100 :)
15:34:49 <ganso> ok, regarding the first one which is assigned to rraja
15:35:01 <dustins> tbarron: Yes, just the Tempest Credentials one
15:35:01 <tbarron> rraja did his fixes it looks like
15:35:04 <ganso> dustins, tbarron, vkmc do you know if rraja still intend to work on this?
15:35:24 <tbarron> aren't there patches there for hdfs and glusterfs?
15:35:27 * tbarron looks again
15:36:54 <tbarron> rraja isn't paid to work on those drivers anymore ...
15:37:26 <ganso> tbarron: ok, we should unassign the bug and call for volunteers then
15:37:26 <tbarron> they need to be marked as w/o maintainer in driverlog
15:37:46 <tbarron> but more to the point it looks like commits were made for the issue in those devstack plugins
15:37:46 <dustins> tbarron: It looks like the reviews for the GlusterFS and HDFS devstack plugins
15:37:58 <ganso> tbarron: oh, nvm, you're referring to the drivers
15:38:04 <dustins> There are reviews, and they've been merged
15:38:22 <tbarron> well, I meant the devstack plugins for the drivers
15:38:27 <ganso> tbarron: oh ok
15:38:30 <tbarron> I'll pursue this one dustin
15:38:43 <dustins> tbarron: Sounds good
15:38:47 <dustins> So NOW I think I'm done :)
15:38:49 <tbarron> Hopefully it's just a matter of cleanup on the bug.
15:39:00 <ganso> tbarron: yes possibly
15:39:15 <ganso> #topic open discussion
15:39:16 <dustins> tbarron: It sounds like it, the patches submitted were from nearly two years ago :)
15:39:51 <ganso> does anybody have any other topics for today?
15:39:54 <gouthamr> i've something
15:40:18 <gouthamr> has anyone else besides Yogi1_ played with the dynamic credentials in manila_tempest_tests?
15:40:53 <tbarron> vponomaryov has ....
15:41:08 <tbarron> but that doesn't help us
15:41:17 <tbarron> dustins: didn't you do a fix in that area?
15:41:34 <gouthamr> if you're running tests against any DHSS=True driver, without modifying stuff, you're probably using the dynamic credentials
15:42:03 <dustins> tbarron: A bit ago, yeah, I did some of the stuff in Tempest proper
15:42:03 <gouthamr> modifying stuff: creating "tempest accounts" before hand and specifying the accounts.yaml file location in your tempest.conf
15:42:21 <gouthamr> so in a sense, "pre-provisioned" credentials
15:42:40 <gouthamr> that's what our gate does...
15:43:33 <ganso> gouthamr: are you implying that there is still work to do on this front?
15:44:10 <gouthamr> ganso: so we tried using manila_tempest_tests without pre-provisioned credentials
15:44:36 <gouthamr> and things fail all over the place, because there's cleanup logic to delete the credentials created..
15:45:06 <gouthamr> and i suppose the cleanup logic has issues.. so i'm wondering if we should remove that code if no-one is using it..
15:45:45 <ganso> gouthamr: sounds like a new bug
15:46:22 <gouthamr> i can open up a bug and explain the situation on it... we'll need some looking over and buy-in from our new tempest experts
15:46:43 <dustins> gouthamr: Sounds like a plan
15:46:53 <ganso> gouthamr: who are the new tempest experts?
15:47:21 <gouthamr> #action: gouthamr open the bug on issue with using dynamically provisioned tempest credentials in manila_tempest_tests
15:47:26 <dustins> ganso: We've got raissa and I on the Tempest front :)
15:47:47 <tbarron> ganso: and they have connections into the secret tempest kabal
15:47:58 <ganso> tbarron: lol
15:48:15 <dustins> lol
15:48:34 <tbarron> they can probably get Yogi1_ initiated too
15:48:59 <raissa> let's keep in mind that the review for the new repo for manila_tempest_test was merged yesterday
15:49:03 <tbarron> but bswartz himself will not be admitted
15:49:23 <dustins> raissa: \o/
15:49:25 <tbarron> raissa: +1000
15:49:30 <raissa> going to submit initial patches for the jobs...
15:49:34 <gouthamr> raissa: nice!
15:50:11 <gouthamr> raissa: it's called manila-tempest-plugin?
15:50:14 <raissa> gouthamr: yes
15:50:24 <gouthamr> raissa: 8)
15:50:40 <ganso> #link https://github.com/openstack/manila-tempest-plugin
15:50:43 * gouthamr channeling bswartz: Yet another OpenStack repository, sigh
15:50:48 <raissa> heheh
15:50:51 <ganso> gouthamr: lol
15:50:56 <dustins> hehehe
15:51:24 <ganso> any other topics for today?
15:51:50 <tbarron> dustins: did you want to mention that share-type quotas bug?
15:52:18 <dustins> tbarron: Oh yeah, I could!
15:52:46 <tbarron> I was wondering why arnewiebalck didn't hit it when he tried out the new feature ...
15:53:18 <ganso> dustins: go ahead
15:53:22 <tbarron> and whether vponomarov would agree that it's a valid bug, etc.
15:53:27 <dustins> https://bugs.launchpad.net/manila/+bug/1722707
15:53:29 <openstack> Launchpad bug 1722707 in Manila "Quotas per share_type has bad db unique contraint " [Undecided,New]
15:53:31 <tbarron> but he's not here of course
15:53:35 * dustins had to go find the bug
15:53:41 <tbarron> dustins: thx
15:54:21 <dustins> It looks like the bug reporter is trying to figure out how to do this
15:54:32 <dustins> I think that it's something that makes sense to add if we can
15:54:58 <gouthamr> yes, it looks like we didn't document this
15:54:59 <dustins> But I honestly don't know enough to tell you why it could be a bad idea
15:55:11 <gouthamr> afair, you can't control project and share type quotas together
15:55:11 <dustins> Which is likely why I think it's a good idea :)
15:55:44 <gouthamr> http://specs.openstack.org/openstack/manila-specs/specs/pike/support-quotas-per-share-type.html#data-model-impact
15:56:45 <gouthamr> "It needs to take into account project_id so more than one project can have per share-type quotas." <--- when you assign a share type quota, you can't control that quota per project
15:56:52 <gouthamr> am i misunderstanding that?
15:58:37 <gouthamr> *chirp chirp* :)
15:58:43 <dustins> gouthamr: I'd have to look into the quotas more to be able to answer definitively
15:58:51 <gouthamr> ganso dustins: time check..
15:58:55 <tbarron> well I haven't had time to understand this one
15:59:02 <tbarron> we should compare with cinder too
15:59:03 <ganso> gouthamr: ya
15:59:12 <tbarron> for reasonable user expectations
15:59:13 <dustins> We'll have to circle back around on this one, and look at Cinder's work
15:59:20 <dustins> ...and bug Valeriy :)
15:59:29 <gouthamr> bug Valeriy with bugs
15:59:33 <ganso> lol
15:59:38 <gouthamr> bugomaryov
15:59:42 <ganso> we are running out of time
16:00:03 <ganso> let's continue this on the channel if there is more to discuss
16:00:05 <ganso> thanks everyone!
16:00:07 <ganso> #endmeeting