15:01:26 <bswartz> #startmeeting manila
15:01:26 <zhongjun> hi
15:01:27 <openstack> Meeting started Thu Dec 21 15:01:26 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:30 <openstack> The meeting name has been set to 'manila'
15:01:37 <bswartz> hello all
15:01:43 <zhongjun> Hi
15:02:00 <ganso> hello
15:02:16 <bswartz> courtesy ping: tbarron gouthamr toabctl xyang markstur vponomaryov cknight
15:02:23 <toabctl> hi
15:02:29 <vkmc> o/
15:02:54 <ganso> bswartz: you should include vkmc in that list :P
15:02:57 <bswartz> hmm we might be short of a quorum today
15:02:58 <dustins> \o
15:03:17 <ganso> bswartz: and dustins
15:03:19 <ganso> =)
15:03:21 <bswartz> ganso: true -- I just constructed the courtesy ping list from the core reviewers
15:03:25 <vkmc> :)
15:03:36 <bswartz> But I could add anyone who wants to be on it
15:03:48 <bswartz> Cinder actually has their courtesy ping list on the wiki
15:04:21 * gouthamr_ sneaks in
15:04:28 <ganso> bswartz: maybe we could do that as well
15:04:33 * bswartz marks gouthamr tardy
15:04:58 <bswartz> okay well I don't have any announcements for this week
15:05:05 <tbarron> hi
15:05:19 <bswartz> and no specific agenda items
15:05:34 <bswartz> however I am aware of the limited time until feature freeze, and the upcoming holidays
15:05:35 <jungleboyj> @!
15:05:36 <_pewp_> jungleboyj (;-_-)ノ
15:05:59 <bswartz> perhaps we should go over the list of features remaining for queens
15:06:51 <bswartz> ...
15:06:58 <bswartz> I thought we had more specs merged for queens
15:07:18 <bswartz> why do I only see 2?
15:07:40 <zhongjun> We only merged 2
15:07:53 <bswartz> What about specs for community goals?
15:08:08 <gouthamr_> We didn't need specs for those
15:08:21 <zhongjun> There isn’t a spec for community goals
15:08:51 <bswartz> okay I thought we talked about it and agreed to have a stub spec that pointed to the community spec
15:09:00 <bswartz> I could be misrememering though
15:09:07 <bswartz> misremembering
15:10:07 <bswartz> Well let's discuss the major things left to be done
15:10:13 <bswartz> #topic queens priorities
15:10:38 <bswartz> The ensure share stuff looks good to me at this point
15:11:12 <bswartz> I wish we could have automated testing that covered the upgrade/reconfiguration case for this feature
15:11:38 <bswartz> how are we doing on the policy-in-code goal?
15:11:53 <gouthamr> pretty well! nearly done.
15:12:24 <gouthamr> https://review.openstack.org/#/c/523819/ needs to merge for code-completion
15:12:33 <zhongjun> We only have two partches need to be merged
15:12:42 <bswartz> okay
15:12:44 <gouthamr> https://review.openstack.org/#/c/525115 is the last patch in the series
15:13:00 <bswartz> and the tempest plugin?
15:13:27 <bswartz> #link https://review.openstack.org/#/c/512300/
15:13:28 <zhongjun> We tested it, it is work
15:13:36 <gouthamr> LGTM
15:13:40 <bswartz> Can we merge this today?
15:13:57 <gouthamr> +1
15:13:58 <bswartz> We could have merged it last week but we held off because some vendors wanted time to test
15:14:18 <zhongjun> I think so
15:14:36 <bswartz> I get that some CIs might blow up over the holidays, but holding off at this point is unlikely to help anyone
15:15:36 <vkmc> +1
15:15:43 <gouthamr> we need the devstack-plugin-glusterfs and devstack-plugin-ceph folks to merge predecessor changes
15:15:53 <gouthamr> #link https://review.openstack.org/#/c/514374/
15:16:02 <gouthamr> #link https://review.openstack.org/#/c/514381/
15:16:11 <bswartz> who can make that happen?
15:16:39 <tbarron> gouthamr: i just did the ceph one 514381
15:16:39 <bswartz> any of you redhat guys have workflow power on those repos?
15:16:54 <gouthamr> tbarron has ze powers :)
15:17:07 <tbarron> not on 514374 though
15:17:15 <bswartz> really?
15:17:19 <tbarron> i'll see if I can chase people down
15:17:21 <bswartz> who has the powers for that repo?
15:17:45 <tbarron> bswartz: probably csaba
15:18:00 <gouthamr> rraja too, but he may be asleep
15:19:20 <bswartz> #link https://review.openstack.org/#/admin/groups/565,members
15:19:44 <bswartz> there's 4 people on the list
15:20:05 <tbarron> bswartz: I think maybe only csaba and rraja are around
15:20:09 <bswartz> tbarron, you think any of them are awake still?
15:20:25 <tbarron> I just pinged csaba since he's in Hungary but he's not on irc right now
15:20:31 <bswartz> we may want to clean up this group membership
15:20:58 <tbarron> Worst case I'll catch rraja tomorrow morning.  Will ask that they add vkmc or me or something like that too.
15:21:00 <bswartz> why do we depend at all on the glusterfs change?
15:21:20 <bswartz> oh the CI is still running I see
15:21:20 <chandankumar> tbarron: we need to fix manila rpm package also otherwise RDO and tripleo ci will break
15:21:26 <vkmc> we have the ci
15:21:26 <vkmc> yes
15:21:41 <xyang> hi.  I'm late
15:21:45 <tbarron> chandankumar: ack, did you just post a review for this?
15:21:56 <zhongjun> xyang: hi
15:21:57 <gouthamr> hey xyang! :D
15:22:04 <chandankumar> tbarron: new package review is up https://review.rdoproject.org/r/#/c/11032/
15:22:34 <bswartz> thanks chandankumar and tbarron
15:22:50 <tbarron> chandankumar: I read that specfile and it looks good to me; someone else has workflow powers there though.
15:23:09 <bswartz> please let's get this one workflowed today so anyone who needs to fix their 3rd party CI can start to do so right when they return from holidays
15:23:26 <chandankumar> tbarron: it needs a proper review from RDO guys, i have pinged amoralej on #rdo
15:23:33 <tbarron> chandankumar: ack
15:23:45 <bswartz> are there any other big things still in the pipe?
15:23:49 <bswartz> IPv6-related changes?
15:24:00 <bswartz> Changes for replication?
15:24:02 <gouthamr> yep a patch from ganso
15:24:13 <gouthamr> none for replication..
15:24:19 <tbarron> vkmc: you are here tomorrow - would you follow up with rraja and chandankumar if we don't get all this done today?
15:24:28 <vkmc> tbarron, sure
15:24:35 <gouthamr> #link https://review.openstack.org/#/c/529142/
15:24:40 <chandankumar> tbarron: i will be around tomorrow
15:24:41 <bswartz> I see an unmerged spec related to replication
15:24:47 <tbarron> chandankumar: thanks
15:24:49 <ganso> my changes will have to merge after the tempest plugin change
15:24:50 <tbarron> vkmc: thanks
15:25:13 <gouthamr> bswartz: yes, we didn't plan on finishing that in queens
15:25:35 <bswartz> okay just checking
15:25:50 <tbarron> On IPv6 we have put in some tripelo deployment patches, basically just to toggle neutron plugin options if IPv6 environment files are chosen for the deploy
15:25:51 <gouthamr> need to rewrite that spec with changes to dual IP networking
15:26:04 <gouthamr> tbarron
15:26:06 <bswartz> I don't know if any of you were following the MASSIVE thread on openstack-dev about the rocky release
15:26:08 <gouthamr> tbarron: nice
15:26:11 <bswartz> I'm now unclear on what will happen
15:26:12 <tbarron> vendors who are enabling ipv6 in their backends may want to test with these
15:26:31 * tbarron looks at VNX and NetApp
15:27:15 <tbarron> we'll be doing the same where possible
15:27:40 <bswartz> tbarron: is that expected to affect DHSS=true deployments only?
15:27:58 <tbarron> I think Huawei has backend support for IPv6 as well and would want to test with their deployment tool of choice.
15:28:42 <zhongjun> tbarron: no now, but will be
15:28:45 <tbarron> bswartz: well the options for those plugins were put in before you added DHSS=True support
15:28:59 <tbarron> bswartz: I'd have to check exactly how they are used though.
15:29:21 <bswartz> tbarron: well for DHSS=false, there really aren't any config options related to ipv6
15:29:53 <bswartz> it would be worth testing that IPv6 literals are not rejected by any of the config building tools
15:30:04 <tbarron> bswartz: yeah, I guess the plugins don't get invoked
15:30:45 <tbarron> bswartz: but the options were merged in pike while we were saying we had support only for DHSS=false, future-proofing I guess
15:31:27 <bswartz> Who on the NetApp side plans to look at the OSP changes?
15:31:30 <tbarron> ganso has an interesting scenario test in review for IPv6
15:31:53 <bswartz> I know there will be a certification effort at some point, but IIRC 12 hasn't happened yet, so 13 would be after that
15:31:59 <ganso> tbarron: =)
15:32:02 <tbarron> bswartz: to whom is your question addressed?
15:32:18 <bswartz> To NetApp
15:32:23 <tbarron> k
15:32:42 <bswartz> I'm not aware of any plans to test unreleased OSP 13 bits, so we could have a problem
15:33:32 <bswartz> We could have a test coverage gap and we might need to sound the alarm on that
15:33:52 <tbarron> bswartz: We may add support for IPv6 for CephNFS back end in which case we can test it end to end entirely ourselves but for now that's only DHSS=False
15:34:36 <bswartz> From what I know, NetApp is testing the heck out of driver with upstream queens bits, but there's no plans to test anything from tripleo
15:34:56 <bswartz> until after osp 13 is released and the cert tests happen
15:35:37 <tbarron> bswartz: ack, maybe just mention the issue.  tripleo partners get pre-release bits.
15:35:51 <tbarron> bswartz: we can talk about it early in the new year.
15:35:57 <bswartz> okay
15:36:07 <bswartz> anything else then for today?
15:36:15 <bswartz> dustins: do you have bugs to cover?
15:36:39 <dustins> bswartz: Yeah, just a few that we've gone over already that I wanted to check in on
15:36:55 <dustins> #link: https://etherpad.openstack.org/p/manila-bug-triage-pad
15:36:56 <bswartz> #topic Let's go over new bugs
15:37:33 <dustins> #link https://bugs.launchpad.net/manila/+bug/1717261
15:37:34 <openstack> Launchpad bug 1717261 in Manila "NetApp drivers don’t create share of requested size when creating from snapshot" [Low,In progress] - Assigned to Goutham Pacha Ravi (gouthamr)
15:37:47 <dustins> gouthamr: How's this going?
15:38:06 <gouthamr> this seems like a duplicate
15:38:30 <gouthamr> let me find the other bug (that was fixed) and mark this one duplicate
15:38:40 <dustins> Sounds good to me
15:39:04 <dustins> #link https://bugs.launchpad.net/manila/+bug/1708491
15:39:05 <openstack> Launchpad bug 1708491 in Manila "tempest api migration tests very long" [Undecided,New]
15:40:13 <dustins> Looks like this one we looked at and might not have decided what to do with it
15:40:17 <ganso> we have discussed that one in the past and we never reach a conclusion about what to do with those tests
15:40:27 <bswartz> ganso: do we know what the issue is?
15:40:38 <bswartz> I feel like we should do something
15:41:03 <ganso> at first I thought it was the periodic task, but gouthamr confirmed that the periodic task is already running as fast as possible
15:41:08 <bswartz> Either migrate less data (if it's a pure I/O bottleneck) or fix wherever the bottleneck is
15:41:18 <ganso> bswartz: it is migrating an empty share
15:41:49 <bswartz> okay so there's really no reason for it to be so slow
15:42:06 <ganso> we could increase the waiters polling rate
15:42:11 <ganso> this will increase the stress on the host
15:42:23 <bswartz> I think it's worth fixing
15:42:29 <bswartz> what's the polling rate now?
15:42:39 <ganso> it might end up not gaining much time as other parallel tests will be impacted by this stress
15:42:46 <ganso> bswartz: lemme check
15:43:27 <ganso> bswartz: "time.sleep(tries ** 2)"
15:43:31 <ganso> bswartz: that on the server side
15:43:59 <bswartz> oh exponential backoff could be the culprit
15:44:20 <ganso> bswartz: time.sleep(self.build_interval) on the tempest side
15:44:44 <bswartz> exponential backoff with an exponent of 2 means that the test can easily take twice as long as it needs to
15:45:00 <ganso> bswartz: build_interval defaults to 3 seconds
15:45:06 <bswartz> ok
15:45:28 <bswartz> well what we really need is for someone to volunteer to own the bug and to track down the problem
15:45:39 <bswartz> it won't help much to theorize about it here
15:45:59 <dustins> But it sounds like it's at least triaged
15:46:03 <ganso> bswartz: well we supposedly have a fairly good lead of what the problem is
15:46:13 <bswartz> this is the kind of bug I'd like to work on myself after I wrap up the other scenario test work I have
15:47:03 <bswartz> dustins: any other?
15:47:23 <ganso> next one is https://bugs.launchpad.net/manila/+bug/1713062
15:47:24 <openstack> Launchpad bug 1713062 in Manila "Missing ability to automatically build configuration reference artifacts" [High,Triaged]
15:47:37 <bswartz> yeah this came from the PTG
15:47:41 <dustins> ganso can copy and paste faster than me ;)
15:48:08 <bswartz> the plan of record was to copy what cinder did related to this docs change
15:49:20 <dustins> Right, so who wants to do it?
15:49:21 <tbarron> jungleboyj: ^^ is this done now on the cinder side?
15:49:54 <jungleboyj> tbarron:  To do it automatically out of the driver?
15:50:28 <tbarron> jungleboyj: to have something invoked by tox that builds these tables from the code for each driver
15:50:36 <bswartz> there is some code change so the doc building scripts can find the config options, but most of the change is in the docs themselves
15:50:57 <jungleboyj> tbarron:  No, that isn't done yet.  Kendall was working on that stuff and then dropped off the radar.
15:51:12 * tbarron blames kendall then :-)
15:51:14 <jungleboyj> I am hopefully going to have some people that can help out next year and start working on that kind of stuff.
15:51:41 <jungleboyj> We still have a lot of work to do on our config options.  Making incremental progress.
15:51:47 <tbarron> I've been busy with other stuff and haven't looked at it myself yet.
15:52:08 <bswartz> well it's a docs improvement
15:52:09 <tbarron> Would be good to get it done this cycle.
15:52:11 <jungleboyj> tbarron:  Actually, you know what you, probably shouldn't blame her.  I think that one is my fault.
15:52:21 <bswartz> there's a window of time after feature freeze to tackle docs issues
15:52:21 <jungleboyj> I was doing the doc stuff and was supposed to look at that.
15:52:31 <tbarron> jungleboyj: I'm just joking anyways to be clear.
15:52:39 <jungleboyj> Anyway, long story short, not done.
15:52:59 <jungleboyj> I have been off in stand alone Cinder land for the last few months.
15:53:12 <bswartz> #link https://bugs.launchpad.net/manila/+bug/1733494
15:53:13 <openstack> Launchpad bug 1733494 in python-manilaclient "Failed to allow user group access to the share" [Undecided,In progress] - Assigned to kedy (kedy)
15:53:52 <bswartz> kedy is working this?
15:53:55 <bswartz> I don't know who kedy is
15:53:57 <dustins> Looks like it's in progress, just checking in on it
15:54:08 <gouthamr> and abandoned by infra, nice :)
15:54:14 <dustins> I put it up for the bug squish, IIRC
15:54:17 <zhongjun> He is from h3c
15:54:22 <bswartz> okay
15:54:29 <gouthamr> (restored now, no panic)
15:54:33 <bswartz> ok
15:54:50 <bswartz> #link https://bugs.launchpad.net/manila/+bug/1591357
15:54:51 <openstack> Launchpad bug 1591357 in Manila "generic driver cannot remove user rule for NFS share" [Medium,New]
15:55:06 <bswartz> we shouldn't have user rules for NFS...
15:55:24 <bswartz> Is this obsolete?
15:55:38 <tbarron> ganso: ??
15:55:38 <bswartz> ganso: you filed this
15:55:51 <gouthamr> bswartz: we didn't modify the API to disallow user rules for nfs shares
15:56:05 <ganso> we might need to retest
15:56:19 <gouthamr> we didn't have the folks in the room that had user/ip access on NFS shares when we last discussed this
15:56:26 <ganso> it could have been fixed with the access rules refactor we did back in ocata
15:56:54 <bswartz> I think it's decided already
15:56:59 <bswartz> no user-based access for NFS
15:57:11 <tbarron> wouldn't we do "user" for NFS using a sidecar security service, e.g. kerberos?
15:57:13 <bswartz> we should just fix the API to enforce it
15:57:31 <bswartz> tbarron: that's not how it works
15:57:49 <bswartz> the manila access is based on IP only
15:57:50 <tbarron> bswartz: I don't mean this kind of user access rule
15:58:12 <bswartz> file-based access can be per-user, handled in-based through the NFS protocol
15:58:22 <bswartz> it's a different kind of thing though
15:58:43 <tbarron> ack, really didn't mean to be suggesting otherwise
15:59:00 <bswartz> okay
15:59:06 <bswartz> #topic open discussion
15:59:10 <tbarron> we were talking share access and I went on a tangent
15:59:30 <bswartz> we managed to use up the whole hour
15:59:38 <bswartz> next week's meeting is cancelled
15:59:42 <bswartz> I'll make a note on the wiki
16:00:08 <bswartz> we're planning to meet Jan 4 unless I send out an ML post saying otherwise
16:00:21 <bswartz> enjoy your holidays everyone!
16:00:25 <gouthamr> Happy Holidays! :)
16:00:33 <xyang> Happy holidays!
16:00:34 <gouthamr> and Happy New Year!
16:00:59 <ganso> happy holidays!
16:00:59 <tbarron> enjoy, all!
16:01:02 <bswartz> #endmeeting