15:00:14 <bswartz> #startmeeting manila
15:00:15 <openstack> Meeting started Thu Nov 16 15:00:14 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <openstack> The meeting name has been set to 'manila'
15:00:28 <bswartz> hello all
15:00:31 <gouthamr> o/
15:00:33 <ganso> hello
15:00:35 * gouthamr TZ change feels nice
15:00:36 <tbarron> hi
15:00:39 <dustins> \o
15:00:48 <zhongjun> hi
15:00:59 <raissa> hi
15:01:10 <bswartz> courtesy ping: toabctl xyang markstur vponomaryov cknight
15:01:43 <bswartz> #topic announcements
15:01:46 <junboli> hello
15:02:00 <bswartz> welcome back from the openstack summit
15:02:09 <jungleboyj> @!
15:02:09 <_pewp_> jungleboyj (ஐ╹◡╹)ノ
15:02:31 <bswartz> thanks to gouthamr, ganso, and vkmc for represending manila at the summit
15:02:38 <bswartz> (hope I didn't forget anyone -- I wasn't there)
15:02:44 <amito-infinidat> hi
15:03:24 <gouthamr> was a pleasure.. we had a good summit!
15:03:38 <bswartz> this week is R-15, there's just 3 weeks left until milestone 2
15:04:06 <bswartz> we have a deadline the week of milestone 2 -- that monday is the new driver deadline
15:04:38 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:04:49 <bswartz> #topic The Manila community was not very active
15:05:02 <bswartz> junboli: this is your topic, welcome!
15:05:07 <bswartz> (nice topic name btw)
15:05:21 <zhongjun> junboli: welcome!
15:05:38 <tbarron> junboli: good to see you here!
15:05:54 <junboli> good to see you too,
15:06:29 <junboli> yeah, I raise item 1, I would like to talk about manila community.
15:07:03 <junboli> from my view point, I think manila community is little bit inactive, compared with other project.
15:07:29 <bswartz> (from the agenda)
15:07:29 <bswartz> 1. patches cost long time to review and merge.
15:07:29 <bswartz> 2. less response for questions in IRC channel.
15:07:29 <bswartz> 3. more core members are required.
15:07:45 <junboli> yeah, whatever in the number of contributors or the patches submission and review.
15:08:00 <bswartz> junboli: your criticism is valid, regarding the time to merge patches
15:08:32 <bswartz> we have a large backlog of proposed patches, and we don't work very agressively to review patches
15:08:57 <bswartz> it's an area we need to improve, because I'm sure it's off-putting to new contributors and casual contributors
15:09:09 <gouthamr> +1
15:09:25 <tbarron> agree
15:09:32 <bswartz> regarding #2, we have different amounts of coverage in the channel different times of day
15:10:09 * jungleboyj is concerned that this isn't just a problem for Manila.  Lots of projects are suffering the same challenge.
15:10:34 <bswartz> I'm not sure what we can do to address #2
15:10:59 <gouthamr> #2 is a timezone mismatch, because manila has few developers from the AUS/APAC/Eastern Europe time zone
15:11:05 <bswartz> I try to keep the channel open on my screen, but its easy for me to miss messages that aren't send directly to me
15:11:07 <tbarron> junboli: I see that you have patches up for a number of projects: https://review.openstack.org/#/q/owner:junbo85.li%2540gmail.com+status:open
15:11:29 <tbarron> junboli: are these issues especially bad for manila, or do you agree with jungleboyj ?
15:11:52 <bswartz> my main recommendation if you aren't getting answers in the channel is to ping some of the core team members by name
15:12:08 <bswartz> we are here, just usually with our heads buried in code
15:12:09 <jungleboyj> I just say that because we have had some of the same complaints for Cinder and it is because of changes in people's responsibilities.
15:12:23 <jungleboyj> bswartz:  ++
15:12:24 <tbarron> Also make sure to keep the channel open so that you'll see asynchronous responses.
15:12:56 <junboli> Agree
15:13:14 <bswartz> regarding #3, I acknowledge that we've had some attrition of core team members -- mostly due to people's changing jobs, and it takes time to add new core team members
15:14:08 <bswartz> we're always looking to grow the core team, but we won't add people just for the sake of having a large core team
15:14:09 <gouthamr> repeating what we said in Sydney, we're looking for more developers and i'm happy to mentor new developers who want to be on the core team
15:15:26 <gouthamr> We had a slide in the on-boarding session enlisting a few areas we need help with
15:15:28 <gouthamr> #link: https://www.slideshare.net/gautampr12/manila-project-onboarding-openstack-summitforum-sydney-2017
15:15:43 <jungleboyj> gouthamr:  How many people were in the on-boarding room?
15:15:44 <bswartz> so your points #2 and #3 are understood, but I don't think we can make much impact on those
15:15:52 <bswartz> on #1 we can and should change our behavior
15:16:32 <gouthamr> jungleboyj: about 8-10 people
15:16:43 <bswartz> I'm a little shy about pushing people to do more reviews, because I'm personally one of the guilty ones
15:16:56 <jungleboyj> gouthamr:  Nice!  That is good.
15:17:00 <bswartz> I think I need to spend time just combing through the open review list and looking at patches
15:17:02 <tbarron> junboli: I would understand if you say "I shouldn't have to do this" but if you have pathes that aren't getting reviewed then do bring it up in channel!
15:17:13 <bswartz> and I would invite everyone on the core team to do the same
15:18:02 <junboli> OK.
15:18:58 <gouthamr> junboli: thanks for bringing this up, and for contributing :)
15:19:45 <bswartz> in the immediate term, I hope we can give all of junboli's patches a timely review
15:20:31 * bswartz puts them on his TODO list
15:20:38 <bswartz> okay let's move to the next topic
15:20:48 <bswartz> #topic Bug smash in China
15:20:58 <bswartz> zhongjun: you're up
15:21:05 <zhongjun> bswartz: thanks
15:21:22 <zhongjun> #link http://lists.openstack.org/pipermail/openstack-dev/2017-October/123854.html
15:21:35 <zhongjun> The 7th OpenStack bug smash is coming in China
15:21:52 <zhongjun> I wanted to mention the bugsmash is next week.
15:21:52 <zhongjun> Hopefully we could have more people to help with reviews, and take a look at those patches for this bugsmash
15:22:05 * dustins contemplates how much a short notice plane ticket is to China
15:22:07 <zhongjun> And we could work with dustins and groom some bugs for this bugsmash
15:22:34 <dustins> zhongjun: I'll make sure to triage a bunch for everyone to work on :D
15:22:58 <zhongjun> dustins: nice
15:23:05 <gouthamr> exciting.. the etherpad has a few people intending to fix manila bugs
15:23:08 <gouthamr> #link: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan
15:23:22 <zhongjun> dustins: Will you help for fix those bugs? :D
15:23:48 <bswartz> looks like the dates of the bug smash overlap with American thanksgiving -- so some of us will be on holiday during this event
15:24:24 <dustins> zhongjun: I'd love to, but it looks like it's during Thanksgiving...
15:24:37 <bswartz> dustins: it starts wednesday
15:24:48 <dustins> I'm on PTO all next week :(
15:24:48 <bswartz> so you might get 1 day in
15:24:53 <bswartz> oh
15:24:56 <zhongjun> from Nov 22 to Nov 24
15:24:57 <gouthamr> I can help on Wednesday (Tuesday night for us)
15:25:23 <dustins> I'll get as many bugs triaged as I can in the next couple of days
15:25:38 <dustins> If I can't fix 'em, I can at least give everyone stuff to look at
15:25:38 <gouthamr> zhongjun: will you be available through the two days to guide/help folks?
15:25:44 <bswartz> zhongjun: what would be helpful to you, other than a list of bugs that need fixing, and code reviews of the fixes?
15:25:52 <zhongjun> gouthamr: Thanks,  you always do a lot of help :)
15:26:24 <zhongjun> bswartz:  yeah, maybe need more code reviews of the fixes
15:26:50 <zhongjun> gouthamr: I will , it is my pleasure
15:26:56 <bswartz> it will be hard to do real-time reviews of the fixes, which is normally what people would want during a bug smash event
15:26:58 <gouthamr> zhongjun: nice..
15:27:19 <bswartz> I'll be in the office on Tuesday/Wednesday at least, so I can offer to prioritize reviews for that time
15:27:37 <bswartz> Starting Thursday I'm definitely AFK though
15:28:27 <ganso> bswartz: will we have the manila meeting next week?
15:28:42 <bswartz> zhongjun: thanks for making sure Manila is covered in the event though
15:28:47 <zhongjun> thanks, just try to do what things you can
15:28:55 <bswartz> ganso: I was going to cover that at the end of this meeting
15:29:10 <bswartz> I personally won't be able to participate next week
15:29:39 <zhongjun> because of the thanksgiving?
15:29:49 <bswartz> I also suspect that we won't be able to achieve quorum, given the number of people likely to be on vacation
15:29:52 <bswartz> yes
15:30:06 <bswartz> traditinally we cancel the manila meeting every thanksgiving
15:30:15 <bswartz> because of the number of US-based developers on the team
15:30:16 <gouthamr> :) a thanksgiving tradition
15:30:43 <dustins> Goes great with stuffing :)
15:30:58 <bswartz> ganso: it might just be you and zhongjun if you wanted to hold the meeting
15:31:14 <bswartz> oh and maybe vkmc+raissa
15:31:24 <ganso> yea
15:31:41 <bswartz> anyways, I think we should plan to cancel that meeting and meet the following week
15:31:42 <zhongjun> haha, I am fine with that
15:31:57 <bswartz> okay, next topic
15:31:59 <ganso> I'm ok if we all agree to cancel
15:32:08 <bswartz> #topic IPv6 driver capabilities required variables
15:32:15 <bswartz> ganso: you're up
15:32:17 <ganso> bswartz: thanks
15:32:40 <ganso> so I was doing some IPv6 testing with the NetApp driver
15:33:22 <ganso> and I found that there are a couple of places that it is expected that the driver returns ipv6 related support data
15:33:27 <ganso> like in here
15:33:28 <ganso> https://github.com/openstack/manila/blob/master/manila/share/driver.py#L2501
15:33:49 <ganso> so, the driver can implement get_configured_ip_version
15:34:06 <ganso> and is also expected to return a 'ipv6_support' field in the capabilities dict
15:34:20 <bswartz> oh yes I remember this conversation
15:34:32 <bswartz> pretty sure we have a bug in driver.py
15:34:44 <ganso> I would like to understand why is it necessary to return this kind of information twice, since one can be derived from the other
15:35:07 <ganso> since I did not follow the IPv6 implementation and design review closely, I would like ask this before filing a bug
15:35:10 <bswartz> IMO the share manager should be able to compute the capability flags based, and the driver should only need to return 2 things
15:36:00 <bswartz> drivers should need to assert the ipv6_implemented flag, and implement the get_configured_ip_version() driver method
15:36:21 <ganso> I keep hitting the error message in line 2503 because the driver does not return it in the capabilities dict, thus that condition I highlighted always resolves to False
15:36:43 <zhongjun> ganso: You driver can support IPv6, it doesn't mean your driver network can support ipv6
15:36:56 <bswartz> I can't think of a good reason to make drivers also report a capability in the update_share_stats() method
15:37:18 <bswartz> zhongjun: isn't that what get_configured_ip_version() is meant to address?
15:37:30 <zhongjun> the driver network that you configured in your driver configuration
15:38:05 <bswartz> that method is meant to be a runtime check on the actual configuration of the backend
15:38:23 <zhongjun> bswartz:  yeah that is get_configuraed_ip_version meant to address
15:38:52 <bswartz> so IMO the ShareDriver class could compute the appropriate values of ipv4_support and ipv6_support itself, using that method
15:38:53 <ganso> zhongjun: get_configured_ip_version runs only once, during initialization because self.ip_version is None. What is the value supposed to be returned here and what if the network configuration changes without restarting the driver?
15:39:06 <ganso> bswartz: it cannot be a runtime because it runs only once
15:39:39 <zhongjun> ganso, your share driver service only runs once, it means your driver init only onec
15:39:46 <zhongjun> s/onec/once
15:40:03 <bswartz> ganso: it's reasonable to require bouncing the driver if you add/remove IP addresses from tge backend
15:40:09 <bswartz> s/tge/the/
15:40:28 <gouthamr> just to confirm, the design was around three variables: driver must attest taht the backend supports IPv6, admins can configure IPv6 support for the network plugin (standalone), share network will have the ip_version
15:40:30 <zhongjun> then your value of the configuration options can not be changed,right?
15:40:33 <bswartz> I don't think drivers should need to constantly check what IPs the backend has
15:41:01 <bswartz> gouthamr: no
15:41:09 <ganso> bswartz: the capability requirement accomplishes that, so that one (which NetApp driver does not implement) would be a runtime value that should be True if there is an IPv6 network configured in the driver
15:41:15 <bswartz> the requirements are slightly different for dhss=false
15:41:39 <bswartz> for dhss=false, the main requirement is to check that the backend actually has a usable IPv6 address
15:41:41 <gouthamr> in DHSS=False, 1 and 3 are not valid
15:42:00 <ganso> gouthamr: 2 and 3 you mean
15:42:01 <gouthamr> s/1 and 3/2 and 3
15:42:05 <bswartz> in addition to checking that the driver is coded with IPv6 support
15:42:34 <zhongjun> you only need to return the value that it is up to driver
15:43:21 <ganso> bswartz: it is true that the driver setting "ipv6_implemented = True" does not guarantee that the API should accept IPv6 access rules for that driver, as for the case where there are not IPv6 networks configured
15:43:54 <bswartz> ganso: there is no harm in accepting them in that case
15:44:27 <bswartz> the rules can be applied, and they'll be irrelevant because no packets could reach the shares over ipv6
15:44:38 <ganso> bswartz: indeed, there is not, and I remember we discussing this back then, of having IPv6 rules added and they would make sense someday later when network configuration changes
15:44:55 <bswartz> it's up to the driver to do the right thing with the rules if it asserts ipv6_implemented
15:45:25 <bswartz> we only supress the rules for drivers that don't have any ipv6 support, because presumably those drivers would break if given and ipv6 ruile
15:46:21 <ganso> gouthamr, bswartz: so the conclusion we got to is that the design is correct and we need to fix the driver?
15:46:42 <bswartz> I'm still not convinced the existing implementation is right
15:46:58 <bswartz> I think the check in driver.py needs to be changed
15:47:42 <bswartz> we're short on time though
15:48:00 <gouthamr> ganso: perhaps open a bug and we can continue this discussion?
15:48:04 <ganso> ok
15:48:04 <bswartz> zhongjun: do you agree we can change that check, or do you still think the check is correct?
15:48:13 <bswartz> if there's still an issue here, we may need to take it offline to resolve it
15:48:22 <zhongjun> I think the check is correct
15:48:35 <bswartz> okay we need to continue the discussion
15:49:23 <bswartz> ganso: I suggest you push a patch that would fix the check to the way we think it should work, then have a discussion in the code review
15:49:27 <bswartz> I could also push the patch
15:49:39 <bswartz> but we need to move on
15:49:51 <bswartz> #topic 3rd Party CIs may have to change to use Manila Tempest Plugin repo
15:50:01 <gouthamr> s/may/will :)
15:50:05 <zhongjun> okay
15:50:39 <bswartz> raissa: you're up
15:50:54 <raissa> hi, so I was discussing the patch to remove the in-tree manila tempest plugin
15:51:02 <raissa> in favor of the new repository
15:51:10 <raissa> *discussing with gouthamr
15:51:40 <raissa> and we didn't find a non disruptive way of applying the change without breaking 3rd party CIs
15:52:15 <raissa> because they need to add the project to their PROJECTS variable
15:52:26 <bswartz> raissa: this large of a change will probably break 3rd party CIs inevitably
15:52:33 <raissa> yeah
15:52:42 <bswartz> as long as we can make it very easy to fix them, I don't think that's a problem
15:52:43 <raissa> so gouthamr suggested we send an email to inform of this
15:53:08 <bswartz> I'd recommend doing a writeup of exactly what changed and how it's impacted the 3rd party CIs who know about, and how to fix them
15:53:23 <raissa> ok, makes sense
15:53:28 <tbarron> +1
15:53:28 <bswartz> make sure it goes to the dev ML
15:53:57 <bswartz> then just be available to help people who are looking to fix their systems
15:54:13 <raissa> sounds good
15:54:44 <bswartz> so what scope of change are we looking at to unbreak a broken CI system?
15:54:56 <bswartz> gouthamr: do you know about the NetApp one, for example?
15:55:14 <bswartz> is it like a 1-line change and you're back in business?
15:55:15 <gouthamr> bswartz: we probably have to wait until that patch merges to fix the CI
15:55:26 <gouthamr> it is a one line change to our job manifests
15:56:00 <bswartz> but you're saying there are unknowns still?
15:56:06 <ganso> I like one-liners
15:56:12 <bswartz> we can't test the solution before merging the upstream change?
15:56:15 <gouthamr> that said, we have a ton of downstream test tooling built using manila_tempest_tests, so it could be similar for other driver maintainers
15:56:39 <gouthamr> that they have other non-CI related changes to make as well*
15:56:43 * bswartz doesn't like merging changes with unknown consequences
15:57:05 <ganso> bswartz: once you merge, they become known :P
15:57:17 * gouthamr pitchforks on the ready
15:57:18 <bswartz> I'd feel better if we had worked through fixing at least one system before we merge a change, so we can give hope to all the other upset CI maintainers
15:57:57 <bswartz> is it really impossible to make the changes on the CI-side ahead of time?
15:58:21 * bswartz looks at the clock
15:58:25 <gouthamr> i don't know, raissa, what happens if we used manila-tempest-plugin alongside the in-tree tempest plugin?
15:58:30 <bswartz> okay we're not going to get to our last 2 topics
15:58:35 <raissa> gouthamr: unsure
15:58:38 <gouthamr> :)
15:58:56 <raissa> may have some conflict, but I didn't test it
15:59:07 <bswartz> so I'm okay with breakage, but I'd feel much better if we had a handle on the scope of the breakage before we inflict it on the whole community
15:59:29 <bswartz> let's see if we can actually get one system moved over to the new way in advance so we know what all is required
15:59:36 <gouthamr> we can wait to merge it
15:59:37 <raissa> ok
15:59:46 * gouthamr chaos monkey says merging just before thanksgiving sounds fine
15:59:58 <bswartz> REMINDER: next week's meeting is cancelled -- we will meet again 11/30
16:00:12 <bswartz> thanks all
16:00:17 <jungleboyj> Thanks.
16:00:18 <gouthamr> thank you!
16:00:28 <bswartz> #endmeeting