15:00:24 <bswartz> #startmeeting manila
15:00:24 <openstack> Meeting started Thu Jul 20 15:00:24 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <bswartz> hello all
15:00:29 <openstack> The meeting name has been set to 'manila'
15:00:29 <cknight> Hi
15:00:45 <vponomaryov> hello
15:00:52 <ganso> hello
15:01:10 <xyang1> Hi
15:01:11 <bswartz> hopefully I won't have any network issues during this meeting -- someone seems to have tripped over a cable and broken my ethernet this morning
15:01:29 <bswartz> so I'm on (very sketchy) wifi now
15:01:38 <vkmc_> o/
15:01:39 <gouthamr> o/
15:01:41 <jungleboyj> @!
15:01:41 <_pewp_> jungleboyj (;-_-)ノ
15:02:00 <bswartz> #topic announcements
15:02:03 <jungleboyj> bswartz:  Sorry I was so clumsy.
15:02:19 <bswartz> next week is feature freeze
15:02:47 <zhongjun> hi
15:03:04 <bswartz> we are using https://launchpad.net/manila/+milestone/pike-3 to prioritize BPs and reviews
15:03:20 <dustins> \o
15:03:37 <tbarron> hi
15:03:42 <tbarron> i'm tethered to cell atm myself :(
15:03:47 <tbarron> oh, jungleboyj must be in RTP, 'splains everything
15:03:56 <bswartz> jungleboyj: if it was you that tripped over the cable, kindly fix it after the meeting is over!
15:04:19 <vponomaryov> bswartz: "Add quota for amount of share-groups" cannot have priority bigger than "Support quotas per share type", because it depends on it
15:04:20 <jungleboyj> tbarron:  No, I am in Minnesota.  Just seems like when network isn't working I get blamed.  ;-)
15:04:25 <bswartz> I'm going to go pester IT if a few reboots don't sort me out
15:05:24 <bswartz> vponomaryov: that's an implementation dependency not a design dependency right?
15:05:54 <vponomaryov> bswartz: kind of
15:06:12 <bswartz> okay well the best case is to get both merged
15:06:18 <bswartz> I'll leave the priorities alone for now
15:06:42 <bswartz> we'll just let reviews know now that there's a dependency that affects the merge order
15:06:57 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:07:08 <bswartz> okay first item of business
15:07:17 <bswartz> #topic FPF Exception request - ONTAP QoS
15:07:35 <bswartz> #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/119858.html
15:07:41 <bswartz> #link https://review.openstack.org/#/c/484933/
15:07:59 <bswartz> gouthamr submitted this 2 days ago on the ML
15:08:24 <toabctl> hi
15:09:07 <gouthamr> yes.. the code change seems large, but unit tests caused the code bloat..
15:09:08 <bswartz> ...quiet it here....
15:09:15 <bswartz> I hope my network hasn't failed yet
15:09:32 <bswartz> anyways there were only 2 responses on-list
15:09:48 <vponomaryov> I am ok letting it in
15:09:53 <bswartz> if there are no comments I'd like to call a vote
15:09:58 <bswartz> just to make it official
15:10:11 * gouthamr +1 :)
15:10:20 <bswartz> #startvote grant FFE for NetApp QoS? yes, no
15:10:21 <openstack> Begin voting on: grant FFE for NetApp QoS? Valid vote options are yes, no.
15:10:22 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:10:25 <vponomaryov> yes
15:10:31 <vponomaryov> #vote yes
15:10:37 <zhongjun> #vote yes
15:10:39 <xyang1> #vote yes
15:10:41 <bswartz> #vote yes
15:10:44 <tbarron> jungleboyj: :)
15:10:46 <toabctl> #vote yes
15:10:48 <jungleboyj> #vote yes
15:10:52 <cknight> #vote yes
15:10:56 <ganso> #vote yes
15:11:06 <bswartz> jungleboyj: we only blame you for wifi related problems IIRC
15:11:25 <bswartz> 10 seconds
15:11:37 <bswartz> #endvote
15:11:37 <openstack> Voted on "grant FFE for NetApp QoS?" Results are
15:11:38 <dustins> #vote yes
15:11:39 <openstack> yes (8): bswartz, toabctl, ganso, jungleboyj, cknight, vponomaryov, xyang1, zhongjun
15:11:52 <bswartz> okay nobody opposed, the FFE is granted
15:12:00 <gouthamr> thanks everyone!
15:12:12 <jungleboyj> :-)
15:12:19 <bswartz> just a reminder as per our usual rules -- features that missed the freeze go to the back of the priority line for reviews
15:12:22 <jungleboyj> I like to keep it that way.
15:12:57 <bswartz> please focus reviews on high priority BPs, as we have a lot of unmerged stuff and not a lot of time to get it all in
15:13:23 <bswartz> next week I will be ruthless with pushing incomplete things out of the release
15:13:39 <gouthamr> bswartz: should we track on etherpad?
15:13:47 <bswartz> gouthamr: track what?
15:13:52 <bswartz> oh the reviews
15:14:05 <bswartz> yes that's something we've done in past releases
15:14:11 <bswartz> we didn't create an etherpad for pike though
15:14:17 <bswartz> and it's a bit late to start one now :-/
15:14:32 <bswartz> it's still worth doing however
15:14:35 <gouthamr> https://etherpad.openstack.org/p/pike-manila-code-review-focus
15:15:46 <bswartz> I won't fill in the whole etherpad now, but I will populate it after the meeting
15:16:01 <bswartz> and encourage people to assign themselves to reviews
15:16:26 <bswartz> there's very little time, so we won't get a chance to review the etherpad before the freeze itself
15:16:35 <bswartz> I'll just ping people in the channel as needed
15:16:42 <bswartz> thanks gouthamr
15:17:11 <bswartz> okay on to the next topic
15:17:19 <bswartz> #topic IPv6 access
15:17:27 <bswartz> some questions came up in the channel about this
15:17:51 <bswartz> I thought we had reached consensus in Barcelona but maybe not everyone remembers so it's worth revisiting
15:18:18 <bswartz> I'm strongly opposed to any kind of new "capability" bits around ipv6 that clients need to be aware of
15:18:53 <bswartz> IMO, client should be able to assign access rules to shares using ipv4 and ipv6 (assuming the share protocol supports IP access) and expect success
15:19:50 <bswartz> however for obvious reasons, ipv6 accces rules on ipv4-only shares and ipv4 access rules on ipv6-only shares will effectively do nothing
15:20:18 <bswartz> there are 2 benefits to allowing the rules despite them not doing anything
15:20:46 <bswartz> 1) when additional export locations are added later on, the rules can already exist and immediately start working at that time
15:21:17 <vponomaryov> bswartz: (1) is not practical in real deployment
15:21:20 <tbarron> #vote yes
15:21:20 <tbarron> jungleboyj is going to change his vote
15:21:26 <bswartz> 2) is saves clients from having to make any queries before assigning access rules -- clients can simply express what they want and expect it to succeed
15:21:42 <jungleboyj> Holy lag.
15:21:55 <bswartz> tbarron: you're about 11 minutes behind the rest of us...
15:21:59 <vkmc_> Sketchy connection is sketchy
15:22:06 <bswartz> or else I'm 11 minutes in the future
15:22:18 <ganso> at least he tried
15:23:04 * tbarron is traveling very quickly atm
15:23:06 <bswartz> anyways this is what we agreed to in Barcelona and I'm wondering if anyone feels differently now or if anyone who wasn't there disagrees with the decision
15:23:38 <vponomaryov> bswartz: I think that silent skipping of a rule is bad user experience
15:23:42 <tbarron> backwards, apparently
15:23:44 * bswartz hears the doppler effect in tbarron's voice
15:24:12 <bswartz> vponomaryov: it's not skipping the rule
15:24:24 <bswartz> on some backends it may actually configure a rule on the storage controller
15:24:40 <bswartz> it's just that the rule won't matter because it will be impossible to talk to the share over that IP version at that time
15:24:44 <vponomaryov> bswartz: you propose to skip it where it is not supported
15:24:46 <zhongjun> 1)  If we get error status, it is still work:  when additional export locations are added later on, the rules can already exist and immediately start working at that time
15:25:04 <bswartz> later on when an export location is added, the rule should be enforced, so there is value in having it in the manila DB
15:25:29 <bswartz> what does it mean for the rule to have error status in that case?
15:25:46 <tbarron> we should refresh the access rules in ensure share then, b/c the backend may not have been able to implement it the first time
15:25:48 <vponomaryov> bswartz: "error" means "was not applied"
15:25:59 <bswartz> but it was applied
15:26:06 <bswartz> it doesn't ends up not mattering
15:26:31 <vponomaryov> bswartz: you are talking about those backends that are able to set ipv6 rules in general
15:26:32 <bswartz> it's like schrodinger's cat
15:26:33 <ganso> bswartz: this "conditional" behavior of "if it does make sense it is ok, but it if it does, should be enforced" may lead to complicated coding
15:26:39 <zhongjun> bswartz: error status means  the driver doesn't support ipv6 acl
15:26:50 <bswartz> you don't know if the rule is applied or not until you add an export location of the appropriate type
15:27:27 <bswartz> tbarron: yes I was going to mention that an upshot of this is that adding an export location will require an access rule update
15:27:40 <bswartz> zhongjun: that's precisely what I want to avoid
15:27:43 <ganso> bswartz: s/if it does make sense it is ok/if it does not make sense it is ok
15:28:05 <vponomaryov> bswartz: it is expected that we add ipv6 rules right afer we added appropriate export locations
15:28:18 <vponomaryov> bswartz: what is the use case to add rules beforehand?
15:28:27 <bswartz> IMO a user should not be able to percieve any difference between a backend that doesn't have ipv6 support and a backend which does have ipv6 support but not ipv6 export locations
15:28:54 <bswartz> because if they can, then we're looking at new capability bits
15:30:18 <bswartz> my whole goal here is to avoid an awkward transition from no ipv6 support to full ipv6 support as vendors take a long time to add this feature to their drivers
15:30:33 <zhongjun> bswartz: like the user access, user doesn't need to know a backend that doesn't have user access support
15:30:34 <bswartz> capability bits are ugly, optional features are ugly
15:30:49 * markstur sneaks in late
15:31:26 <ganso> zhongjun: does not need to, but is likely to get an error when adding a user access rule that will not work
15:31:27 <bswartz> zhongjun: I'm not sure what you mean -- backends are required to support user access (for CIFS) and we removed user access for other protocols because optional features are confusing and terrible
15:31:54 <tbarron> bswartz: so what does the end-user see, an export location that then doesn't work, right?
15:32:20 <bswartz> tbarron: no, my expectation is that everything will work fine
15:32:28 <bswartz> I'm not sure what you're getting at
15:32:50 <tbarron> bswartz: maybe i'm confused, but end user sees ipv6 access rule, but
15:32:57 <tbarron> ok, no ipv6 export location
15:33:08 <bswartz> if we do this properly, then from a user's perspective ipv6 will be a univerally supported feature, but most backends just won't happen to have any ipv6 export locations yet
15:33:33 <bswartz> and as vendors implement support, admins will be able to assign ipv6 export locations and the drivers will do the right thing
15:33:46 <tbarron> so end user doesn't open a ticket when she has a user vm with ipv6 capability b/c she doesn't see the export location
15:33:58 <tbarron> and doesn't attempt ipv6 mount
15:34:23 <bswartz> tbarron: the user will see the export location with a v4 address
15:34:26 * tbarron is just thinkiing this through from a 'have to support it' POV
15:34:55 <bswartz> if they want an ipv6 address then they should open a ticket and pressure the admin to get ipv6 exports added
15:35:34 <tbarron> user may bug cloud admin 'why isn't ipv6 location there'? and cloud admin will do RFE with backend supplier or distro but I guess that's OK
15:35:39 <bswartz> if the driver doesn't support ipv6 then that's between the admin and their driver vendor, which is where the pressure should come from
15:36:02 <ganso> bswartz: what you are describing is a behavior similar to when the user adds a rule that is in a different subnet than the exports. There is no error. The driver and backend do actually add the rule. But there may be backends that fail to do add ipv6 rules because they are not compatible.
15:36:06 <tbarron> distro will get some tickets on same, but probably not too bad
15:36:08 <ganso> bswartz: I believe ipv6 should behave in a similar way to what happens when you try to add a user rule to a share that does not support it, even though there will be no "ipv6" access rule type being selected, will be "ip"
15:36:13 <bswartz> the right people to yell at vendors are the customers of storage -- the openstack admins
15:37:15 <bswartz> tbarron: right now they would be yelling at *us* (the manila community) for not supporting this feature at all
15:37:36 <zhongjun> bswartz: In some backend, we can support user access in both NFS and CIFS
15:37:38 <ganso> I think it is hard to design a behavior that we may not be capable of supporting from all vendors and get inconsistent behavior
15:37:58 <bswartz> ganso: this was the point of the discussion in barcelona
15:38:16 <bswartz> ipv6 isn't something that some vendors can't support -- it's just a matter of when support is added
15:38:33 <bswartz> there's no question that eventually every driver will have ipv6 support
15:38:42 <ganso> bswartz: yes but they may differ on how it is supported
15:39:07 <bswartz> ganso: it's not that complicated
15:39:23 <bswartz> is there any vendor you know of that can't implement a list of IPv6 access rules?
15:40:10 <ganso> bswartz: I can't comment on details, but I know of backends that cannot add IPv6 access rules if the export is IPv4
15:40:23 <bswartz> getting back to my point, since it will be a universal feature, I'd like to spare the users a bad user experience and just start with a design that looks like the ultimate design where ipv6 is universally supported
15:40:51 <bswartz> ganso: presumably those share would always be v4-only or v6-only though right?
15:40:58 <ganso> bswartz: yes
15:41:16 <bswartz> in which case the unsupported rules can be safely ignored and nobody will know the difference
15:41:37 <ganso> bswartz: but ignored will mean that it will be added in manila with "active" status
15:41:39 <zhongjun> ganso: Our backends that can add IPv6 access rules if the export is IPv4
15:42:03 <bswartz> this is only a really interesting technical problem when shares support both IP versions
15:42:26 <zhongjun> ganso: The share export IP and  share ACL can be spearated
15:42:48 <zhongjun> separate
15:43:04 <ganso> zhongjun: by "our backends" you mean this behavior is enforced at the share manager?
15:43:20 <bswartz> the key here is that admins ultimately have control over export locations (for DHSS=false drivers) and can easily arrange for the right thing to happen
15:43:51 <bswartz> but I always prioritize the needs of the users over the needs of the admins/developers which is why I favor this scheme
15:44:07 <bswartz> yes it's slightly weird, but only during the transition
15:44:24 <bswartz> eventually all drivers will have ipv6 support, and ipv6 export locations will be common
15:45:15 <bswartz> I don't want end users to have to suffer through the transition by checking which shares have which export locations types and then only assigning relevant access rules
15:45:38 <zhongjun> ganso: I mean it can support in driver about  driver can add IPv6 access rules if the share export location is IPv4
15:46:37 <gouthamr> thinking in perspective of the code, this seems possible
15:46:46 <bswartz> so I'd like to get a conclusion on this topic and I've heard a few difference concerns raised
15:46:54 <gouthamr> with the new access rules interface, drivers can update access rules..
15:47:27 <bswartz> does anyone really feel like it's important to have rules in an error state if they are in reality not applied, even though the user can't tell the difference?
15:47:39 <gouthamr> so they don't need to ignore and set thngs to "active". they can leave the rule in "queued" state until someday an ipv6 export location shows up?
15:47:44 <gouthamr> why "error"?
15:48:05 <ganso> gouthamr: really? any queued rule will be sent to the driver
15:48:16 <bswartz> as long as we have a way to ensure that they are applied by the time a user would be able to notice (such as adding a new export location)
15:48:22 <gouthamr> ganso: sure, ignore and return queued_to_apply..
15:48:22 <ganso> gouthamr: then the result of that invocation will lead either to error or active
15:48:29 <ganso> gouthamr: oh, right!
15:48:32 <bswartz> ah, ganso you bring up an important point
15:48:34 <ganso> gouthamr: the return values
15:48:49 <bswartz> I didn't get to the this important detail yet
15:48:56 <ganso> gouthamr: that error/active was the old design
15:49:20 <zhongjun> How about vote for this
15:49:39 <gouthamr> yep.. we changed the rules interface, specially to accommodate access_keys for CEPHFS and then added a way to communicate per-rule status
15:49:39 <bswartz> assuming we agree on what I specified, the way to make it work is to add code to drivers to simply skip over ipv6 rules in the update_access code paths, and the drivers will remove that code when real ipv6 access is added
15:50:12 <gouthamr> i'd vote on leaving rules queued and emitting user messages (if one already doesn't exist for the rule in question) when something is amiss..
15:50:44 <bswartz> gouthamr: won't that cause the manager to spam the driver with update calls?
15:51:39 <gouthamr> :|
15:52:16 <gouthamr> we can think of a way to stop asking of updates for ipv6 rules unless such an update is initiated by ensure_share
15:52:17 <ganso> gouthamr: bswartz has a point...
15:52:17 <gouthamr> ?
15:52:22 <bswartz> I'm in favor of "active"
15:52:43 <bswartz> and then remembing to push an update when any export location is added
15:52:52 <bswartz> that would be part of ensure share though
15:53:12 <ganso> bswartz: for backends that cannot add the rule, and will simply ignore, thus "active", if the ipv6 export is later added, the "active" status will not make sense, the rule will need to be removed and added back
15:53:33 <bswartz> ganso: I don't agree
15:53:42 <bswartz> the rule will be in manila's DB the whole time
15:54:03 <bswartz> the driver just needs to send it to the backend before the v6 export location is added
15:54:18 <bswartz> that's a driver issue which should be hard to deal with
15:54:20 <ganso> bswartz: "remembering to push an update when any export location is added" is what I would categorize as "complicated code logic". I understand that you want user experience to be as simple as possible, but I think the code should be kept simple as well
15:55:22 <bswartz> both would be idea
15:55:24 <bswartz> ideal*
15:55:33 <bswartz> but if we have to choose one I'd favor the user experience
15:55:45 <bswartz> anyways I think this is less complicated than you think
15:56:14 <bswartz> it's just passing the current list of access rules to any method which is allowed to return a new export location
15:56:24 <bswartz> and adding tests for this particular scenario
15:57:04 <bswartz> actually the adding tests part is not easy >_<
15:57:16 <bswartz> so scratch that
15:57:24 <bswartz> but the coding part is not hard
15:58:30 <ganso> bswartz: well, we are ok with making some compromises, like going back to "recovery mode" in this situation. We kinda got rid of this with the new access rules design
15:58:41 <ganso> bswartz: s/well, we are ok/well, if we are ok
15:58:59 <bswartz> yes recovery mode should be the default IMO
15:59:27 <bswartz> the other modes were just for drivers with severely limited backends like the ceph one which couldn't implement recovery mode efficiently
15:59:38 <bswartz> every other one can to my knowledge
16:00:03 <bswartz> also there was some hope that ceph would get better in this regard
16:00:04 <gouthamr> time check
16:00:19 <bswartz> gah
16:00:24 <bswartz> okay we're out of time
16:00:32 <bswartz> I still feel strongly about my position
16:00:49 <bswartz> we can continue discussing in channel if you all don't agree
16:01:10 <bswartz> thanks to gouthamr for filling in that etherpad while we argued
16:01:22 <bswartz> please sign of up reviews that you're doing
16:01:26 <bswartz> so we know where there are holes
16:01:32 <bswartz> that's all for today
16:01:37 <bswartz> #endmeeting