15:00:52 <tbarron> #startmeeting manila
15:00:56 <openstack> Meeting started Thu Oct 18 15:00:52 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:59 <openstack> The meeting name has been set to 'manila'
15:01:00 <gouthamr> o/
15:01:01 <bswartz> .o/
15:01:05 <ganso> hello
15:01:09 <erlon__> hey
15:01:11 <tbarron> ping vkmc
15:01:11 <amito> hello .o/
15:01:14 <tbarron> ping dustins
15:01:25 <tbarron> ping erlon
15:01:27 <dustins> \o
15:01:46 <tbarron> ping xyang
15:01:57 <xyang> hi
15:02:15 <tbarron> ping tpsilva
15:02:40 <tbarron> I think those are all the folks from the ping list who are not away
15:02:44 <tbarron> Hi all!
15:03:12 <tbarron> Agenda:
15:03:22 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:03:30 <tbarron> #topic announcements
15:04:15 <tbarron> Five of us will not be here next week - we're at an offsite meeting - so:
15:04:30 <tbarron> I'm one of the five.
15:04:34 <tbarron> So:
15:04:53 <tbarron> 1) does someone else want to chair the meeting next week?
15:04:57 <tbarron> or
15:05:04 <tbarron> 2) should we skip a week?
15:05:38 <tbarron> crickets
15:05:42 <bswartz> Skipping is fine
15:05:51 <bswartz> I sounds like we would lack quorum anyways
15:06:05 <tbarron> anyone to the contrary?
15:06:15 <ganso> bswartz: +1
15:06:29 <tbarron> #action tbarron will send email that we're skipping next week's meeting
15:06:48 <dustins> Sounds good to me
15:06:50 <bswartz> Is the offsite thing a RedHat meeting?
15:07:16 <tbarron> bswartz: yeah, in Raleigh, which is offsite for all of us but dustin
15:07:22 <bswartz> Because NetApp has a big thing next week too
15:07:29 <tbarron> dustins is having and onsite offsite
15:07:37 <tbarron> bswartz: curious
15:07:55 <tbarron> bswartz: and All Things Open is overlapping I think
15:08:02 <dustins> Far enough away for it to be offsite, close enough to not get a hotel :P
15:08:09 * gouthamr a party in Las Vegas
15:08:11 * bswartz thought that dustins lived so far from town that everything is offsite
15:08:23 <dustins> bswartz: So did I :D
15:08:42 <tbarron> Moving on, summit/Forum topics are up:
15:08:47 * dustins dreads two hours of commuting everyday next week
15:08:52 <tbarron> #link https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=manila
15:08:56 <dustins> For a good reason, at least :)
15:09:06 <tbarron> ^^^^ looks like lots of manila content
15:09:40 <dustins> Oh wow, that's awesome!
15:11:03 <tbarron> Next, I want to call attention to a change to cycle-with-milestones projects like manila proper
15:11:19 <tbarron> #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/135088.html
15:11:33 <tbarron> We no longer do milestone releases
15:12:04 <tbarron> But still pay attention to milestones for tracking purposes.
15:12:15 <tbarron> Any questions/comments on this change?
15:12:17 <bswartz> Interesting
15:12:32 <bswartz> A sign of stability I guess
15:13:04 <tbarron> Any other announcements?
15:13:23 <tbarron> #topic Code Review Guideline up for review
15:13:28 <tbarron> gouthamr: you're up
15:13:47 <tbarron> #link https://review.openstack.org/#/c/609598/
15:13:51 <gouthamr> hi, ty tbarron
15:14:24 <gouthamr> i put that up last week, and have been having some good discussions on it, just a pointer for the rest of us to take a look as well :)
15:15:32 <gouthamr> that's all i had about that
15:16:14 <tbarron> Everyone should pay attention to the sections on
15:16:43 <tbarron> Affiliation, Ninja merging, and Vendor code and review.
15:17:15 <tbarron> Any other remarks on this topic now?
15:17:36 * dustins makes a point to look it over
15:17:56 <bswartz> I'm not sure we want to document the process of ninja merging
15:18:08 <bswartz> It's kind of like talking about fight club
15:18:18 <tbarron> lol
15:18:21 <gouthamr> :P
15:18:26 <ganso> bswartz: you just broke #1 rule
15:18:32 <bswartz> What is the first rule of fight club?
15:18:53 <luizbag> you never talk about fight club
15:19:09 <bswartz> I feel the same way about ninja merges
15:19:28 <tbarron> https://www.youtube.com/watch?v=dC1yHLp9bWA
15:19:47 <tbarron> let's discuss this subject some more
15:19:59 <tbarron> in the review :)
15:20:08 <bswartz> Okay
15:20:13 <gouthamr> +1 ty everyone
15:20:23 <tbarron> #topic access rule prioritization
15:20:29 <tbarron> ganso, that's you!
15:20:34 <ganso> tbarron: thanks
15:20:45 <ganso> While testing the patch, our team found something that we believe to be an issue
15:21:13 <ganso> the spec proposes that, 1) when there are conflicting rules under the same priority, the behavior will be undefined
15:21:40 <ganso> https://review.openstack.org/#/c/552935/19/specs/rocky/priority-for-access-rules.rst@82
15:22:01 <bswartz> This is intentional I think
15:22:07 <bswartz> For backwards compatibility
15:22:19 <ganso> 2) after this change merges, drivers that reorder rules should stop doing so
15:22:30 <bswartz> The prior behavior is undefined, so we preserve whatever that undefined behavior is when there's a tie
15:22:32 <ganso> https://review.openstack.org/#/c/552935/19/specs/rocky/priority-for-access-rules.rst@302
15:22:56 <ganso> the issue is: some backends do not have "undefined" behavior. Their behavior is defined and deterministic
15:23:08 <bswartz> So they match the spec then by definition
15:23:27 <ganso> I will give an example
15:23:28 <bswartz> Undefined just means you can do whatever you want and it will be considered correct by the spec
15:24:12 <ganso> if a driver reorders the rule today to achieve a certain behavior, after the priorization patch merges, and the reordering is removed from the drivers
15:24:23 <ganso> the behavior will not be the same when there are conflicting rules under the same priority
15:24:33 <bswartz> In practice we should encourage backends to break ties in exactly the way they used to handle conflicts before priorities existed
15:24:53 <tbarron> bswartz: I think the issue is that the backend won't know that there is a tie.
15:25:01 <bswartz> But the spec doesn't require this
15:25:13 <tbarron> there will be a sort before the back end sees the rule set
15:25:14 <bswartz> I see
15:25:23 * bswartz headdesk
15:25:37 <tbarron> so the back end can't preserve *exactly* the same behavior
15:25:56 <ganso> our team disagrees with removing the reordering of rules once the patch lands because we would like to retain the behavior for the scenario I described. That is, we want to continue reordering rules when there are conflicting rules with the same priority
15:26:13 <ganso> tbarron: yes
15:26:29 <tbarron> ganso: but you might violate the prioritization for non-ties!
15:26:54 <bswartz> Is there a way we can add a capability so the drivers can declare support for rule priority and do the sorting themselves?
15:26:58 <ganso> tbarron: we want to change to code to take the other priorities into consideration
15:27:18 <ganso> bswartz: if we do that, the user experience will be inconsistent
15:27:21 <bswartz> tbarron: drivers can do that anyways
15:27:48 <ganso> tbarron: s/change to code/change the code
15:27:48 <tbarron> bswartz: ?  they shouldn't, right?
15:27:59 <bswartz> tbarron: only tests cases can enforce that they don't
15:28:15 <bswartz> And tests cases can enforce correct behavior however we implement it internally
15:28:39 <bswartz> So I propose a driver capability that the manager can query before it performs the sort
15:28:58 <bswartz> Obviously the capability will default to false
15:29:00 <tbarron> Do any back ends besides NetApp sort the rules now?
15:29:34 <bswartz> We might not have the right people in the room to answer that
15:29:36 <tbarron> We may be able to just tie-break in the manager in a way that is consistent with current practice and then
15:29:54 <tbarron> not have to add extra complexity.
15:30:13 <bswartz> tbarron: if the desire is the implement tie breaking in the manager in a consistent way, then we should write that way into the spec so it's clear
15:30:17 <tbarron> All back ends would stop sorting themselves and we'd have the correct behavior.
15:30:44 <tbarron> bswartz: I agree that we should write how the manager will tie break in the spec.
15:30:55 <ganso> tbarron, bswartz: I agree with that, but apparently this was discussed in the spec and people agreed to not do that
15:31:19 <bswartz> If we want to preserve legacy behavior (or flexibility to do interesting things) then leaving it undefined makes more sense, and we should give drivers freedom to sort the list how they choose
15:31:31 <bswartz> But in any case, write tests that ensure drivers conform to the spec at least
15:32:14 <ganso> bswartz: indeed, as the spec puts it, the undefined behavior couldn't be tested consistently
15:32:57 <bswartz> You don't test undefined behavior, you test the defined behavior
15:33:19 <ganso> tbarron: it seems we don't have the spec owner here to discuss, how would we approach this?
15:33:26 <tbarron> The spec does not say drivers can just do whatever they want, only that when there are conflicts that it is undefined.
15:33:30 <ganso> bswartz: yes, it creates a test gap
15:34:11 <ganso> tbarron: I'm fine with that statement, I am against not being able to reorder the rules in the driver anymore, as stated in the spec
15:34:15 <bswartz> tbarron: agree
15:34:49 <tbarron> ganso: how will you know which rules you can re-order?
15:35:05 <tbarron> ganso: how will you know you don't violate the expressed priority?
15:35:23 <ganso> tbarron: we can read the 'priority' field within the driver
15:35:39 <tbarron> ganso: it's not in the rules given to you
15:35:45 <ganso> tbarron: we will sort only the group of rules within the same priority
15:35:56 <ganso> tbarron: according to my team tests, it is
15:36:01 <tbarron> ganso: how will you know that group
15:36:17 <ganso> tbarron: the model is being passed to the driver
15:36:44 <tbarron> ganso: oh I thought just the rules were passed, in an order, with no priority
15:37:28 <tbarron> ganso: if you have the priority info, without having to do a database lookup from the driver, then sure
15:37:31 <ganso> tbarron: and even if this is a bug and the priority shouldn't be passed, then I disagree with it not being passed, and without it we wouldn't be able to accomplish what I am proposing
15:38:30 <gouthamr> yeah, we discussed passing the priority down to the drivers on the review/spec and agreed to do it iirc
15:38:45 <tbarron> gouthamr: ok, i missed that
15:39:09 <ganso> probably the model shouldn't be passed, but a dictionary containing the regular access fields and the priority should
15:39:38 <tbarron> then there's no issue with back ends maintaining current tie-breaking behavior, right?
15:40:43 <ganso> tbarron: yes, assuming they just reorder what falls in the "undefined" behavior
15:41:00 <tbarron> I think we  can take any remaining discussioon to the review then.
15:41:16 <ganso> ok
15:41:19 <tbarron> ganso: you still need to change your back end not to do a general sort
15:41:27 <ganso> glad to reach agreement =)
15:41:30 <ganso> tbarron: yes, we will
15:41:31 <tbarron> ganso: just scope it to the ties
15:41:45 <ganso> tbarron: yup
15:41:46 <tbarron> #topic planning our work
15:42:20 <tbarron> #link https://wiki.openstack.org/wiki/Manila/SteinCycle#Priority_for_Access_Rules
15:42:38 <tbarron> Spec approval deadline is 8 November
15:42:55 <tbarron> The main thing on this topic that I want to cover today is
15:43:06 <tbarron> which specs will be proposed.
15:43:24 <tbarron> ganso you have three, two of which are in the work plan.
15:43:46 <ganso> tbarron: actually 3, if you refresh the page right now
15:43:55 <tbarron> ganso++
15:44:08 <tbarron> Who else is planning on doing a spec?
15:44:42 * tbarron thinks not all work requires specs but
15:44:43 <gouthamr> i am, for a few things that i raised BPs for
15:44:51 <gouthamr> heh, read my mind
15:45:13 <tbarron> if you are going to do a spec please post a review for it,
15:45:19 <gouthamr> sure
15:45:24 <tbarron> even if you mark it WIP and it doesn't have anything yet
15:45:32 <tbarron> and put the link in the work plan.
15:45:39 <gouthamr> yessir
15:46:16 <tbarron> I think a plan of work may be useful as a "spec" for things like OSC and SDK
15:46:40 <tbarron> where we hope to divide and conquer on the actual tasks.
15:47:02 <tbarron> That's all I have on this topic for this week.
15:47:17 <tbarron> #topic Bugs!
15:47:23 <tbarron> dustins: you are the man
15:47:23 <gouthamr> the SDK has a workplan on storyboard, i will add a link to the wiki (if it hasn't been already)
15:47:35 <tbarron> gouthamr: and that's fine, no spec needed
15:47:40 * dustins gathers items
15:48:14 <dustins> #link: https://etherpad.openstack.org/p/manila-bug-triage-pad
15:48:26 <tbarron> let's get the workplans in place by M1 or spec review time
15:48:42 <dustins> #link: https://bugs.launchpad.net/manila/+bug/1796986
15:48:42 <openstack> Launchpad bug 1796986 in python-manilaclient "[doc] No documentation on user messages" [High,Triaged]
15:49:11 <dustins> So this one has already been triaged, we just need some volunteers to work on it
15:49:42 <dustins> And we should really make sure that no new features go into Manila without the corresponding documentation for how to interact with it
15:50:18 <tbarron> unfortunately the folks who implemented user messages - ameade and jprovazn - aren't with us
15:50:20 * gouthamr it's so straightforward it doesn't need docs :P
15:50:32 <dustins> tbarron: Indeed :(
15:50:40 <tbarron> well the doc could be quite brief
15:50:54 <dustins> So I need a volunteer for someone to take up the mantle to have a look at this
15:50:58 <tbarron> show the workflow for a characteristic error
15:51:14 <dustins> And tbarron is right, there's not anything particularly difficult about this
15:51:50 <tbarron> dustins: you can give the bug to me but I disagree with High priority
15:51:58 <dustins> jgrosso_: Would be a good opportunity to get a commit into Manila and go through that workflow :)
15:52:00 <gouthamr> if anyone is inspired, i wrote this for an internal doc team: https://paste.fedoraproject.org/paste/gzbnc5Ztnm82rbR3zQV91A
15:52:01 <tbarron> dustins: if I take it it will be a bit
15:52:20 <dustins> tbarron: I can lower priority if you'd like
15:52:25 <gouthamr> omy
15:52:32 <jgrosso_> ok
15:52:47 <tbarron> jgrosso_ just got voluntold :)
15:53:07 <dustins> I just wanted to call attention to the fact that we have features in our code that have no documentation for how to use them, maybe more of a "medium" thing
15:53:15 <gouthamr> replace link: http://paste.openstack.org/show/732438/
15:53:19 <dustins> No one's data is getting destroyed after all :)
15:53:28 <jgrosso_> :)
15:53:31 <dustins> tbarron: The wonders of delegation
15:54:01 <dustins> #action: dustins to work with jgrosso_ to get the documentation in
15:54:36 <dustins> #link: https://bugs.launchpad.net/manila-ui/+bug/1624425
15:54:37 <openstack> Launchpad bug 1624425 in manila-ui ""Set as Active" button shown for replicas in transitional states" [Low,New]
15:54:47 <dustins> I've got a few UI bugs to air out, so let's start with this one
15:55:07 <dustins> And yes, most of these are quite old
15:55:24 <bswartz> Who is working on manila-ui now?
15:55:35 <dustins> bswartz: I was hoping you could tell me :)
15:55:35 <bswartz> It requires some special skills that we don't all have
15:55:45 <dustins> I know vkmc has done some work with it in the past
15:56:00 <dustins> But I wouldn't say she owns it
15:56:10 <bswartz> That one seems like an easy bug, but it needs someone familiar with the UI
15:56:28 <bswartz> Or maybe a pairing of someone with UI experience and someone with replication experience
15:57:02 <dustins> Agreed, and it need not require a NetApp backend, as it seems like it effects all replication workflows
15:57:13 <dustins> Any volunteers?
15:57:18 <tbarron> dustins: seems like we need to start by confirming that it's still an issue?
15:57:36 <dustins> tbarron: Yes, and I called that out in a comment on the bug
15:57:52 <tbarron> dustins: you need a back end that slow enough replicating to show the issue
15:57:55 <tbarron> :)
15:58:11 * tbarron is just messing around
15:58:14 <gouthamr> i think this is a low-hanging-fruit, please mark it so in case we have any wayward contributors
15:58:16 <dustins> A lot has changed in the last two years, so it's possible that this has just gone away, but I don't think that's the case
15:58:21 <dustins> gouthamr: Wilco
15:58:51 * dustins adds "low-hanging-fruit" tag
15:59:15 <dustins> #link: https://bugs.launchpad.net/manila-ui/+bug/1576776
15:59:15 <openstack> Launchpad bug 1576776 in manila-ui "Test coverage is too small" [Low,Triaged]
15:59:31 <dustins> tl;dr We want to improve test coverage in Manila UI
15:59:39 <dustins> And need volunteers for such
15:59:51 <ganso> time check
15:59:57 * tbarron doesn't like bugs with general topics like that
16:00:20 <tbarron> let's follow up in #openstack-manila
16:00:25 <tbarron> Thanks everyone!
16:00:25 <dustins> Sounds good
16:00:29 <tbarron> #endmeeting