15:01:00 <tbarron> #startmeeting manila
15:01:01 <openstack> Meeting started Thu Apr 12 15:01:00 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:05 <amito> hello o/
15:01:05 <openstack> The meeting name has been set to 'manila'
15:01:14 <markstur> hi
15:01:14 <bswartz> .o/
15:01:15 <ganso> hello
15:01:16 <dustins> hey hey \o
15:01:17 <tbarron> manila courtesy ping:  gouthamr zhongjun xyang markstur vponomaryov cknight toabctl bswartz ganso
15:01:19 <zhongjun_> hi
15:01:22 <tbarron> bswartz: :)
15:01:36 <tbarron> Hi all
15:01:47 <tbarron> #topic announcements
15:02:02 <toabctl> hi
15:02:13 <tbarron> toabctl: hi
15:02:36 <tbarron> Sunday is the deadline for Forum submissions, so pls. update
15:02:50 <tbarron> #link  https://etherpad.openstack.org/p/YVR-manila-brainstorming
15:03:12 <tbarron> Unless there are updates to that etherpad I'll go with what's there.
15:03:34 <tbarron> Spec freeze is 19 April, one week from today.
15:03:49 <tbarron> We'll talk about specs in more detail in a moment.
15:03:55 <tbarron> Any other announcements?
15:04:34 <gouthamr> o/
15:04:52 <tbarron> gouthamr: hi
15:04:59 * tbarron passes gouthamr a cup of coffee
15:05:11 <vkmc> o/
15:05:17 <gouthamr> thank you tbarron :P
15:05:36 * tbarron passes vkmc aspirin (for manila-ui)
15:05:49 <vkmc> oh so much needed
15:05:52 <vkmc> \o/
15:06:22 <tbarron> #agenda https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:06:35 <tbarron> #topic spec reviews
15:06:46 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-specs
15:07:02 <tbarron> https://review.openstack.org/#/c/553662/
15:07:09 <tbarron> This one has some momentum
15:07:41 <tbarron> If anyone has concerns about backwards compatability for APIs returning the wrong codes speak fast
15:07:53 <bswartz> I already reviewed this -- for some reason I didn't press the +2 button
15:08:00 <tbarron> not fast, I mean raise your concerns or forever hold your peace :)
15:08:06 <tbarron> bswartz: cool
15:08:39 <tbarron> We'll skip the next one (access rule) since it has its own topic.
15:08:59 <tbarron> #link https://review.openstack.org/#/c/546301
15:09:19 <tbarron> dustins: can you work with the author to resolve your -1 ?
15:09:30 <gouthamr> I agree with dustins that the diff is hard to read
15:09:39 <tbarron> dustins: I think you don't object to the actual correction, right?
15:10:04 <dustins> tbarron: Indeed
15:10:07 <tbarron> gouthamr: dustins: so please reach out and get that procedural issue resolved
15:10:17 <dustins> And yes, I can do so, thanks for the reminder
15:10:24 <tbarron> dustins: thanks much
15:10:35 <tbarron> Anyone have material objections to this one?
15:10:44 <tbarron> It's pretty minimal.
15:11:02 <tbarron> #link https://review.openstack.org/#/c/551106/
15:11:13 <tbarron> metadata for access rule resource
15:11:22 <gouthamr> haven't reviewed past zhongjun's latest changes..
15:11:24 <tbarron> looks like it has review attention
15:11:47 <gouthamr> but important point to note here is the list API is going to change
15:11:53 <tbarron> gouthamr: ack, so please keep the review going
15:12:07 <zhongjun_> yes, I fixed bunch of comments
15:12:16 <tbarron> gouthamr: do you have any fundamental objections at this point, or just fixups?
15:12:24 <gouthamr> zhongjun_: please correct me if that's incorrect, you do plan on adding a new API to list access rules and that API will allow filtering on metadata?
15:13:10 <zhongjun_> gouthamr: yes
15:13:12 <gouthamr> i.e, the existing API will be unchanged, and will continue to work as is, you won't be able to use it to filter by metadata
15:13:46 <zhongjun_> gouthamr:  the existing list API already use POST action
15:14:44 <gouthamr> zhongjun_: yes.. i guess we should add these points to the spec
15:15:13 <zhongjun_> tbarron: I thought it just fixups,   gouthamr: right?
15:15:26 <gouthamr> zhongjun_: yes, mostly
15:15:59 <tbarron> gouthamr: zhongjun_ is this one close enough that the remaining changes can be made by next week at this time?
15:16:03 <gouthamr> tbarron: please see the bit about the API change, that's the only controversial part
15:16:27 <gouthamr> the current API is POST /shares/{share-id}/action to get a list of access rules
15:17:34 <gouthamr> a new API which will support filtering by access rule metadata will be GET /share-access?share_id={share-id}&key=value&key2=value2
15:17:37 <zhongjun_> tbarron: It's about how to design API for list access rule
15:18:17 <tbarron> gouthamr: zhongjun_ right, we're stuck with the old POST but does it make sense to use a GET for the new api to, umm, get ?
15:18:25 <ganso> so with the microversion bump the POST /shares/{share-id}/action will start rejecting calls for that access-list action and only the new one will work, right?
15:19:34 <ganso> IIRC correctly share list API is a GET, so why shouldn't this be?
15:19:48 <tbarron> zhongjun_: do you disagree?
15:19:54 <gouthamr> yeah, all of the list APIs are GETs
15:19:56 <ganso> s/'correctly'/''
15:20:57 <zhongjun_> tbarron:  I am not disagree, but it is a little big change
15:21:16 <zhongjun_> so I think we should put it on the meeting
15:21:37 <tbarron> zhongjun_: This is the meeting :)
15:21:42 <gouthamr> :) +1
15:22:54 <zhongjun_> If there isn't any to against it, then we could go on
15:23:37 <tbarron> zhongjun_: are you saying that you are willing to revise the new spec such that the new API will be a GET rather than a POST ?
15:23:54 <tbarron> s/the new spec/the spec/
15:25:10 <zhongjun_> yes
15:25:15 <tbarron> zhongjun_: thanks
15:25:18 <gouthamr> ganso: yes, we'll be setting a maximum microversion on the old API
15:25:27 <tbarron> #topic New Drivers
15:25:43 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-drivers
15:26:02 <tbarron> We have two new driver submissions, both of which are passing CI now.
15:26:12 <tbarron> So it's time to sign up for reviews.
15:26:25 <zhongjun_> cool
15:27:07 <gouthamr> are passing the gate checks but not their own third-party CI
15:27:14 <bswartz> gouthamr: you must love reviewing drivers
15:27:30 <gouthamr> bswartz: i must love reviewing
15:27:45 <tbarron> gouthamr: yeah, put a -1 in there and say that
15:27:51 <tbarron> they've asked for reviews
15:28:07 <tbarron> I'll encourage people who have recently added drivers
15:28:10 <tbarron> hint hint
15:28:13 <tbarron> to review
15:28:22 <amito> who're you hinting to? ;)
15:28:29 <tbarron> amito: oh, not you :)
15:28:45 <amito> oh, good then :P
15:29:05 <tbarron> You'll be able to help and also be able to note where common problems could be solved by common code :)
15:29:14 <tbarron> And stuff like that.
15:29:34 <tbarron> Let's get these reviews going early enough so that there are no surprises.
15:29:44 <tbarron> Anything else on this topic?
15:30:15 <tbarron> #topic priority for access rules spec
15:30:25 <tbarron> #link https://review.openstack.org/#/c/552935
15:30:48 <tbarron> zhongjun_: this one is yours, right?
15:30:56 <zhongjun_> yes
15:31:12 <zhongjun_> Do we require a limitation for value of the access rule priority (1~100)
15:32:20 <tbarron> I forget the reasoning you and bswartz gave for having a limited range
15:32:25 <zhongjun_> I remember we discussed in PTG, we agreed that the value of priority is "1-100", bswartz: right? if my member is right
15:32:37 <tbarron> It wasn't that there aren't enough integers
15:32:40 <bswartz> We never need more priorities than there are bits in a netmask for ip-based rules
15:33:02 <bswartz> 100 is a good round number that fits into human brains
15:33:14 <tbarron> gouthamr: does that address your concern?
15:33:30 <zhongjun_> gouthamr's question is if we have more access rules,  more than 100, is it work?
15:33:34 <bswartz> For user-based rules, you'd never need more priorities than there are groups that contain the same user
15:34:02 <bswartz> There's no problem with using the same priority for multiple rules, as long as the rules don't overlap
15:34:04 <ganso> the range is not for different access rules, just for overlapping ones
15:34:05 <gouthamr> tbarron: no
15:34:21 <gouthamr> there's no such limitation on adding access rules, so why bother adding a limit?
15:35:00 <bswartz> Putting a limit on the priority number is a subtle indication to users about how the feature should be used
15:35:08 <bswartz> In reality there is no need to limit it
15:35:19 <bswartz> But I think 1-100 will result in better usuability
15:35:39 <gouthamr> ganso: agreed that this feature is for overlapping rules, but having an API check around something that isn't really limited is kinda weird
15:35:50 <gouthamr> bswartz: maybe we should add a hint in the UI?
15:36:13 <bswartz> Limits make users happier
15:36:34 * gouthamr thinks of ONTAP's limits... smiles
15:36:34 <amito> gouthamr: which hint? the order in which the rules are shown?
15:36:38 <bswartz> If we leave it unbound people will wonder about negative numbers higher than 4.2 billion
15:36:58 <bswartz> If we leave it unbound people will wonder about negative numbers and numbers higher than 4.2 billion
15:37:18 <ganso> if 100 isn't big enough we can make it bigger
15:37:20 <tbarron> And they might wonder a couple of times too
15:37:24 <bswartz> When people see there's a small range, they get the message that they don't need that many different priorities
15:37:25 <tbarron> :)
15:37:39 <gouthamr> bswartz: a valid value is any positive integer
15:37:55 <bswartz> Incuding numbers higher than 64 bits?
15:38:09 <bswartz> That might break mariadb
15:38:14 <zhongjun_> or make it could be configed ?
15:38:34 <gouthamr> bswartz: you could theoretically have >100 rules and assume you can only do so many
15:38:44 <gouthamr> s/and/but
15:40:07 <bswartz> gouthamr: Yes but that's around the point that you're doing something wrong even ignoring priorities
15:40:28 <gouthamr> bswartz: i agree validation is important, but the limit may seem confusing to the end user
15:40:35 <bswartz> We can support over 100 rules, but there's probably not a good use case for it
15:40:52 <bswartz> I don't feel strongly on this
15:41:01 <tbarron> bswartz: gouthamr why don't you two take this one offline
15:41:01 <amito> How do you handle two rules with the same priority? (and how does it show in the ui?) does the spec address that? I don't remember
15:41:15 <tbarron> bswartz: gouthamr specc should indicate the reasoninig for the choice
15:41:26 <tbarron> bswartz: gouthamr and talk about ipv6 explicitly
15:41:30 <bswartz> amito: same priority means the order between them is arbitrary (how it is today for all rules)
15:41:41 <tbarron> why 64 max with 128 bit addresses
15:41:54 <tbarron> bswartz: so that is my real concern
15:41:54 <gouthamr> tbarron: agreed, i was asking zhongjun_ for the reason from the PTG because i wasn't around and the spec didn't mention what it was
15:41:58 <zhongjun_> amito: I added the example in the spec
15:42:01 <bswartz> tbarron: that's easy, it's in the RFC
15:42:05 <amito> bswartz: then there should be some precedence based on other attributes (access type / address range / etc.)
15:42:11 <tbarron> I'm not sure that the spec solves the problem it's intended to address
15:42:30 <tbarron> bswartz: I just said put it in the spec :) pointing to rfc is fine
15:42:50 <tbarron> back to the problem, ambiguity in our access rules
15:43:02 <tbarron> what will this one mean?
15:43:15 <bswartz> #link https://tools.ietf.org/html/rfc7421
15:43:34 <tbarron> A 192.168.1.0/24 RO 5
15:43:45 <tbarron> A 192.168.1.10 RW 1
15:43:52 <tbarron> 5 is higher
15:44:03 <tbarron> order is irrelevant
15:44:03 <bswartz> 1 is higher than 5
15:44:24 <tbarron> I don't care which is higher, but I thought the spec said 5 is higher.
15:44:28 <bswartz> Priorities always sort backwards
15:44:42 <ganso> tbarron: the spec states the lowest number is higher priority
15:45:01 <tbarron> Read the example such aht the more general rule is higher priority.
15:45:08 <tbarron> ganso: kk
15:45:19 <tbarron> what does that mean?
15:45:20 <gouthamr> "The lower number have the higher priority"
15:45:34 <tbarron> gouthamr: right, so let me re-do the example
15:45:44 <tbarron> A 192.168.1.0/24 RO 1
15:45:52 <zhongjun_> ganso: yes, because we could have multiple overlap access rule than 5 ?
15:45:53 <tbarron> A 192.168.1.10 RW 5
15:46:01 <bswartz> ^ In this example the second rule is effectively ignored
15:46:21 <ganso> in that example the RW ones is pointless
15:46:40 <bswartz> However, we keep it in the database because if the other rule is deleted (denied) then it suddenly has meaning
15:46:55 <gouthamr> bswartz: it doesn't though
15:47:02 <gouthamr> bswartz: oh, you mean the subnet rule
15:47:11 <ganso> gouthamr: the RW one
15:47:39 <gouthamr> ganso: if the access for 192.168.1.0/24 is denied, the RW one actually works
15:47:49 <ganso> gouthamr: yes
15:47:51 <tbarron> I am not sure this is implementable naturally on all backends
15:48:19 <tbarron> a backend that matches most specific over more general for example
15:48:30 <ganso> tbarron: the ordering that could cause a rule to be ignored does not prevent them from being sent to the backend
15:48:31 <bswartz> All we need to do is implement the sorting in the share manager and document what the ordering of the rules now has meaning
15:49:00 <tbarron> or we could document that more specific over general has meaning
15:49:08 <gouthamr> bswartz: +1, that's where i'm caught up with this feature
15:49:11 <tbarron> which would avoid nonsense entries like the one I gave
15:49:12 <bswartz> If the backend can interpret the meaning correctly, then they should all be sent to to the backend -- otherwise the driver may want to perform some preprocessing
15:49:35 <tbarron> and backends that process first match priority would just sort more specific first
15:49:48 <tbarron> That would be unambiguous semantics.
15:49:59 <tbarron> With less chance of user error.
15:50:05 <tbarron> Clear rules.
15:50:28 <tbarron> No need for assigning priorities.
15:51:02 <bswartz> The priorities are about the API not the driver
15:51:20 <tbarron> API has clear rules with more specific wins.
15:51:28 <bswartz> Right now if I have 2 overlapping rules defined, and they're in the wrong order, I have no choice but to delete them and add them back in the right order
15:51:41 <bswartz> Adding priorities allows me to reorder them without deleting anything
15:51:52 <tbarron> It allows a lot of confusion
15:52:06 <tbarron> And therefore support cases.
15:52:26 <bswartz> The current situation leads to incorrect behavior and tough-to-solve problems
15:52:27 <tbarron> Proving to customers that they shot themselves in the foot and deserve to hurt.
15:52:32 <bswartz> I'm not sure which is worse
15:52:36 <ganso> tbarron: o_O
15:52:48 <tbarron> I'm not for the current situation, to be clear.
15:52:55 <ganso> tbarron: oh
15:52:59 <tbarron> I think this spec poses the problem well.
15:53:09 <tbarron> Currenlty we have ambiguity.
15:53:23 <ganso> tbarron: so we should document it correctly
15:53:29 <tbarron> I'm just not sure at this point that user assigned priorities are the best solution.
15:53:55 <tbarron> "more specific wins" is a familiar semantic from routing
15:53:56 <ganso> tbarron: implementation-wise it doesn't seem there much to improve on usability
15:53:59 <zhongjun_> we should document it in the spec or a special doc?
15:54:12 <bswartz> Didn't someone point out that a real cloud provider today implements this with priority numbers?
15:54:31 <bswartz> (One that's not using openstack)
15:54:49 <tbarron> bswartz: mebbe, AWS?
15:54:59 <gouthamr> AWS doesn't have access rule priority last i checked
15:55:32 <tbarron> Let's take some time to think about this one a bit more even if it means extending the spec deadline for it.
15:55:39 <zhongjun_> bswartz: aliyun implement this with priority numbers today
15:55:40 <gouthamr> see https://docs.aws.amazon.com/efs/latest/ug/gs-step-two-create-efs-resources.html
15:55:44 <tbarron> I'm convinced that there's a real problem.
15:55:59 <tbarron> But let's get a solution that we'll be happy with down the road.
15:56:16 <bswartz> I think priorities are pretty straightforward
15:56:23 <tbarron> #topic New Bugs
15:56:26 <gouthamr> zhongjun_: do you have a link to their documentation
15:56:30 <bswartz> Think of how a UI could be built for this feature
15:56:42 <bswartz> It would just be a listbox with ^ and v buttons
15:57:01 <tbarron> #link https://etherpad.openstack.org/p/manila-bug-triage-pad
15:57:12 <tbarron> dustins: you're up
15:57:16 <zhongjun_> gouthamr: I am finding
15:57:21 <tbarron> bswartz: we'll talk some more ....
15:57:44 <amito> I think you skipped the second bullet, but we're out of time in 3 min anyway
15:57:52 <tbarron> amito: oh sorry
15:58:11 <amito> It's ok, maybe we should move this off-meeting
15:58:18 <gouthamr> zhongjun_: found it
15:58:21 <gouthamr> #link https://www.alibabacloud.com/help/doc-detail/27534.htm?spm=a3c0i.o27533en.b99.23.77643ad5TzJF1D
15:58:24 <tbarron> amito: ok
15:58:25 <zhongjun_> Do we have  conclution
15:58:26 <gouthamr> 1-100 :D
15:58:31 <tbarron> zhongjun_: no
15:58:35 <dustins> amito: Feel free to continue, my bugs will take more time than is remaining
15:58:40 <tbarron> zhongjun_: but we'll give more time if we need to
15:58:46 <tbarron> zhongjun_: for the spec
15:58:46 <gouthamr> "When the same authorization object matches multiple rules, the rule with the highest priority overwrites the remaining rules."
15:58:59 <zhongjun_> tbarron: thanks
15:59:05 <bswartz> gouthamr: +1
15:59:17 <gouthamr> oops, i'm messing up the meeting log, sorry tbarron
15:59:26 <tbarron> gouthamr: that's ok
15:59:35 <bswartz> We can always #undo the topic change
15:59:46 <tbarron> #undo
15:59:46 <openstack> Removing item from minutes: #link https://www.alibabacloud.com/help/doc-detail/27534.htm?spm=a3c0i.o27533en.b99.23.77643ad5TzJF1D
15:59:58 <bswartz> Doh that undid the #link
16:00:03 <amito> I might've missed if you discussed it above since I was afk for awhile now, but how do we handle overlapping allow-deny rules? gouthamr and bswartz stated that priority is irrelevant for deny rules, but I don't think that's the case.
16:00:05 <ganso> lol
16:00:07 <gouthamr> hahaa
16:00:07 <tbarron> #undo
16:00:12 <openstack> Removing item from minutes: #link https://etherpad.openstack.org/p/manila-bug-triage-pad
16:00:20 <tbarron> #undo
16:00:21 <openstack> Removing item from minutes: #topic New Bugs
16:00:31 <gouthamr> rollback :P
16:00:41 <ganso> time check
16:00:42 <tbarron> #link https://www.alibabacloud.com/help/doc-detail/27534.htm?spm=a3c0i.o27533en.b99.23.77643ad5TzJF1D
16:00:53 <tbarron> Thanks everyone!!
16:01:02 <gouthamr> amito: #openstack-manila?
16:01:07 <amito> gouthamr: kk
16:01:12 <tbarron> let's continue in #openstack-manila
16:01:15 <tbarron> #endmeeting