15:00:29 <tbarron> #startmeeting manila
15:00:36 <openstack> Meeting started Thu Apr 26 15:00:29 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:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:39 <openstack> The meeting name has been set to 'manila'
15:00:45 <bswartz> .o/
15:00:46 <tbarron> manila courtesy ping:  gouthamr zhongjun xyang markstur vponomaryov cknight toabctl bswartz ganso
15:00:47 <dustins> \o
15:00:50 <ganso> hello
15:00:52 <zhongjun_> hi
15:00:54 <markstur> hi
15:01:06 <tpsilva> hi
15:01:21 <tbarron> Hi all
15:01:38 <xyang> hi
15:01:41 <tbarron> #topic announcements
15:01:46 <vgreen> hi
15:01:56 <tbarron> PTG will be in Denver
15:02:06 <tbarron> #link http://lists.openstack.org/pipermail/openstack-dev/2018-April/129564.html
15:02:08 <ganso> tbarron: choo choo again?
15:02:17 <bswartz> Stapleton
15:02:26 <tbarron> they say the train situation has improved
15:02:28 <amito> ganso: should be less noisey this time
15:02:31 <tbarron> we will see
15:02:55 <tbarron> I haven't started a topics etherpad yet but it's on my list so stay tuned
15:03:15 <tbarron> I responded to the poll indicating that we do plan to meet there physically rather than
15:03:21 <tbarron> have a virtual PTG for manila.
15:03:34 <tbarron> Does anyone have any issues with that?
15:03:44 <tbarron> (It's not too late to correct my response)
15:03:46 <bswartz> We're barely past milestone 1 -- we don't need to do PTG planning for a long while
15:03:53 <tbarron> bswartz: ack
15:04:05 <bswartz> But +1 on physical rather than virtual
15:04:27 <tbarron> I may put up an etherpad soon just so it can gradually accumulate ideas as they occur to people but
15:04:29 <bswartz> Virtual was only ever a good idea if we were meeting at the summits, and very few of us are
15:04:35 <tbarron> then push for filling it out later.
15:04:46 <tbarron> Anyone for virtual?
15:05:04 <tbarron> I think the physical meetings in Dublin were pretty successful.
15:05:10 <vkmc> o/
15:05:20 <zhongjun_> +1
15:05:40 <amito> +1 for physical
15:05:44 <ganso> +1 for phys
15:05:45 <vkmc> +1 for physical
15:05:53 <tbarron> OK, hearing no objections, plan of record stands that we will meet in "Denver" (Stapeleton)
15:06:11 <tbarron> Vancouver Forum Schedule is posted
15:06:29 <tbarron> #link http://lists.openstack.org/pipermail/openstack-dev/2018-April/129867.html
15:06:47 <tbarron> I messed up and copied our topics over late so we only got one into the forum.
15:07:06 <tbarron> So consider running for PTL next cycle and use that defect against me if I run :)
15:07:42 <tbarron> But the topic is a good one
15:07:56 <tbarron> "running manila at scale & barriers to deployment"
15:08:10 <tbarron> it consolidates two that we suggested and the remaining ones
15:08:32 <tbarron> running with non nova instance clients and share-type-quotas experience
15:08:45 <tbarron> can be covered under this general topic as well
15:08:52 <tbarron> so it will be OK I think
15:09:01 <markstur> should say "ovecoming barriers" or something like that to spin it positive
15:09:28 <tbarron> markstur: sure, dunno if I can change it at this point but I'll see
15:09:36 <tpsilva> tbarron: is this the final schedule or it may change after community review?
15:10:16 <tbarron> This is supposed to be set except for schedule conflicts but I'll write
15:10:31 <tbarron> Jimmy McArthur with markstur's suggested tweak on title
15:10:54 <tbarron> tpsilva: is that time bad for you?
15:11:23 <tpsilva> tbarron: no, it's good
15:11:25 <tbarron> Monday 11:35-12:15
15:11:34 <tbarron> ok, moving on
15:11:56 <tbarron> Technical Committe elections have started
15:12:13 <tbarron> and voting ends 1018-04-30 @ 23:45 UTC
15:12:24 <tbarron> #link http://lists.openstack.org/pipermail/openstack-dev/2018-April/129260.html
15:12:32 <tbarron> Be sure to vote!
15:13:01 <tbarron> Anyone have anything to say about the election, any candidates, issues, etc?
15:13:33 <tbarron> I'll just say that having a good turnout is perceived as an indicator of OpenStack community health
15:13:51 <tbarron> and I think it's in all our interests that we get lots of participation.
15:14:18 <tbarron> Any other announcments?
15:14:43 <tbarron> ok, hearing none ....
15:14:54 <tbarron> #topic Spec reviews
15:15:06 <tbarron> #link https://review.openstack.org/#/c/546301
15:15:25 <tbarron> on this one just a reminder to slackers gouthamr and dustins that they
15:15:44 <tbarron> are going to do the git move here and then we can approve it
15:15:54 <tbarron> just a bookkeeping thing, no big deal
15:16:01 * dustins writes that on a post-it
15:16:12 <tbarron> #link https://review.openstack.org/#/c/552935
15:16:22 <tbarron> This is the access-list priority spec
15:16:37 <tbarron> I argued for an alternative solution but
15:16:53 <tbarron> there wasn't exactly a ground swell of support for it :)
15:17:15 <tbarron> If we were starting green field I think I might be inclined to dig in more,
15:17:16 <bswartz> Simpler is better
15:17:42 <tbarron> ah, now you are baitiing me, that's what I was saying with the alternative :)
15:17:56 <tbarron> but what isn't simpler given our history
15:18:05 <tbarron> is the backwards compatability issue
15:18:11 <bswartz> In this case I mean simpler regarding the implementation
15:18:29 <tbarron> the sort is simpler but the user interface is messier
15:18:34 <bswartz> The core issue is that the existing interface has undefined behavior
15:18:46 <tbarron> and there is still potential ambiguity unresolved
15:18:54 <tbarron> only end user can resolve
15:19:06 <tbarron> and back ends may still treat ties differently
15:19:10 <bswartz> There are multiple ways to resolve that, and I'd prefer the one we talked about in Dublin
15:19:29 <tbarron> but I think we can live with those matters, just want them spelled out a
15:19:29 <bswartz> Because I think it's the most straightforward to implement and understand, even if the interface is more complex
15:19:34 <tbarron> better in the spec.
15:19:59 <tbarron> Work can proceed for this spec but let's fill out some areas in it for the record.
15:20:07 <tbarron> I put my +1 on it.
15:20:15 <zhongjun_> It spelled out in driver impact in spec
15:20:36 <ganso> tbarron: your improvement suggestions haven't been addressed. So you wouldn't +2 it without those improvements, right?
15:20:39 <tbarron> zhongjun_: you'll see several areas that I think need a bit more explanation
15:21:02 <tbarron> ganso: I don't want to get hung up on process.  We're going to go ahead with this approach.
15:21:17 <zhongjun_> tbarron: still now?
15:21:24 <tbarron> We can work out some of the answers to my questions in code review.
15:21:37 <tbarron> zhongjun_: yes, I just updated in the last hour or two.
15:21:58 <tbarron> zhongjun_: but the issues are relatively minor.
15:22:11 <tbarron> zhongjun_: I don't think they are just nitpicks however.
15:22:31 <tbarron> zhongjun_: for instance, are we going to do the UI the way bswartz suggested, where
15:22:50 <tbarron> a list of rules is presented and the user doesn't see priority numbers
15:23:34 <tbarron> just an example of something worth writing down as we figure it out
15:24:00 <tbarron> So people who are +2 please put your votes back on the spec.
15:24:12 <tbarron> zhongjun_: Know that I am not blocking this.
15:24:59 <zhongjun_> Could we add the detail in the code ?
15:25:22 <tbarron> zhongjun_: yes, but why not also have the answers to these questions in the spec?
15:25:32 <ganso> I'd like to see in the spec the UI approach chosen, if it is not there already. I haven't checked the latest update
15:25:57 <tbarron> We can merge it and revise it if that's the consensus but there are at least some typos that should be fixed :)
15:26:16 <tbarron> So core reviewers and other reviewers please do one more pass.
15:27:03 <tbarron> zhongjun_: but I am not going to block eventual merge so if you have other reviewer's support as well
15:27:21 <tbarron> and I think no one is expressing show-stop objections
15:27:31 <tbarron> then your work can move ahead.
15:27:37 <tbarron> Any more on this for this week?
15:27:57 <bswartz> Isn't there a deadline on this?
15:27:59 <bswartz> Like today?
15:28:26 <zhongjun_> tbarron: Cloud we fix this patch today?
15:29:15 <tbarron> bswartz: why be artificial on process about this?
15:29:30 <tbarron> zhongjun_: be my guest to respond again today, it's just late for you.
15:29:43 <bswartz> tbarron: for deadlines to have any meaning they must be enforced
15:30:26 <tbarron> bswartz: well why don't you pick this one up and respond to the open questions then
15:30:38 <tbarron> There are no votes but mine on the latest iteration.
15:30:49 <tbarron> But I don't want to scuttle this spec because of that.
15:30:51 <zhongjun_> tbarron: thanks for not going to block eventual merge
15:31:11 <bswartz> I will add comments if it helps others
15:31:29 <tbarron> We just went a week with only zhongjun_ and me updating I think.
15:32:21 <bswartz> I had a long talk with zhongjun_ last night before I fell asleep
15:32:35 <bswartz> I feel like we're on the same page
15:32:43 <tbarron> bswartz: ty, and she updated after that, and I reviewed after that.
15:33:16 <tbarron> So we need a little more time on a very important spec.  Access control has
15:33:28 <tbarron> been a painful area for manila and I donn'
15:33:47 <tbarron> don't want us to do less than we can here to get it right this time.
15:34:09 <tbarron> So let's extend this one one more week but turn around reviews on it every day.
15:34:16 <tbarron> I will ping people to review.
15:34:31 <tbarron> Anything else on this one?
15:35:00 <tbarron> #topic Forum timing
15:35:20 <tbarron> I just interjected this b/c we just got a request to swap our Forum time from Monday at
15:36:00 <tbarron> 11:35 to Thursday at
15:36:20 <tbarron> 1:50
15:36:43 <tpsilva> tbarron: works for me and erlon
15:36:43 <tbarron> tpsilva: ^^^ any issues with that?
15:36:56 <tbarron> Anyone else?
15:37:18 <tbarron> dustins: vkmc ^^^ ?
15:37:27 <dustins> No complaints here
15:37:46 <tbarron> OK, I will do some checking myself but will agree to the swap if we don't have conflicts.
15:38:06 <tbarron> #topic Bugs
15:38:15 <tbarron> dustin, you are up
15:38:30 <tbarron> #link https://etherpad.openstack.org/p/manila-bug-triage-pad
15:38:41 <dustins> thanks, tbarron
15:38:47 <dustins> #link https://bugs.launchpad.net/manila/+bug/1755795
15:38:48 <openstack> Launchpad bug 1755795 in Manila "manila_tempest_tests.tests.scenario.test_share_basic_ops create share failed because share type not found" [Undecided,New]
15:39:40 <dustins> Looking at the comments, it looks like this might have been resolved?
15:40:30 <tbarron> dustins: I'm not sure it was.
15:41:03 <tbarron> I think shuali is just saying that the report of default-share-type w/o DHSS attribute was mistaken
15:41:48 <dustins> Interesting
15:42:46 <dustins> We may have to try this scenario test to see if we see the same results
15:42:50 <dustins> Any volunteers?
15:43:13 <tbarron> dustins: is comment #3 the steps to reproduce?
15:43:31 * bswartz finishes review comments
15:43:37 <dustins> tbarron: Looks that way, yeah
15:43:38 <tbarron> bswartz: ty!
15:43:57 <bswartz> I've never liked usage of the default share type in tests
15:44:21 <bswartz> We need some tests to verify that the default share type functionality actually works, but every other test should create the share types it requires
15:44:53 <tbarron> agree
15:44:54 <bswartz> Group setup/teardown is the appropriate place for that kind of thing, IMO
15:45:17 <vkmc_> bswartz++
15:45:30 <bswartz> Or individual test setup/teardown for tests that have special requirements
15:45:44 <tbarron> dustins: maybe just update indicating that there is ongoing work to do what bswartz just said that should fix this issue
15:45:59 <tbarron> and leave the bug open
15:46:17 <bswartz> +1
15:46:34 <bswartz> Maybe link back to the bug so whoever does fix this remembers to close the bug
15:46:45 <vkmc_> same thing is happening in tempest tests in which we rely to some pre setup for the environment
15:47:05 <vkmc_> for the share type creation
15:47:49 <ganso> vkmc_: I kinda lost track of that patch you were working on. Has it merged?
15:48:06 <vkmc_> ganso: no
15:48:12 <tbarron> #link https://bugs.launchpad.net/manila/+bug/1755795
15:48:13 <openstack> Launchpad bug 1755795 in Manila "manila_tempest_tests.tests.scenario.test_share_basic_ops create share failed because share type not found" [Undecided,New]
15:48:19 * dustins updated the bug
15:48:27 <vkmc_> I had to give prio to other work
15:48:30 <ganso> vkmc_: ok I'll look for it again and see the updates
15:48:52 <vkmc_> ganso: thanks!
15:48:58 <tbarron> bswartz: oh, you mean in vkmc_ 's review, right?
15:49:19 <bswartz> tbarron: I'm not sure where I mean
15:49:24 <tbarron> :)
15:49:27 <bswartz> Just somewhere so that the bug isn't forgotten
15:50:00 <dustins> ready for the next one?
15:50:02 <tbarron> dustins: can you add a backlog or don't forget section to this etherpad and add it there?
15:50:15 <tbarron> then yeah, next :)
15:50:39 <dustins> tbarron: done
15:50:42 <ganso> tbarron: I believe vkmc_ 's could add a closes-bug for that one, if it isn't
15:50:48 <tbarron> dustins: ty
15:51:06 <dustins> #link https://bugs.launchpad.net/manila/+bug/1753630
15:51:07 <openstack> Launchpad bug 1753630 in Manila "The net, router, and subnet created in the Manila tempest test process are not cleared" [Undecided,New]
15:52:01 * bswartz cringes
15:52:13 <dustins> This is our classic "tempest doesn't clean up after itself" bug
15:52:47 <bswartz> Well there is the more basic question of what should we assume to exist prior to tempest vs what tempest should create itself
15:53:10 <bswartz> Certain types of objects are awkward to create inside the test framework
15:53:21 <dustins> bswartz: Like what?
15:53:30 <bswartz> It's reasonable to require the user to create them and specify them in tempest.conf
15:53:37 <bswartz> Networks in particular
15:54:01 <bswartz> If the network has any physical component
15:54:03 <ganso> bswartz: for DHSS=true it shouldn't be awkward
15:54:22 <tbarron> but this bug is about nets routers and subnets *created* in the tests
15:54:24 <ganso> bswartz: the generic driver creates those and clears them
15:54:39 <dustins> ganso: Assuming tests don't fail
15:54:40 <bswartz> Yeah I didn't dig into this specific issue
15:54:54 <ganso> dustins: yes
15:54:55 <bswartz> Hopefully this one is as simple as just remembering to cleanup stuff the test creates
15:55:20 <bswartz> But I recall some test discussion (probably with ganso regarding ipv6) about situations where networks really should be created before tempest runs
15:55:23 <tbarron> we've had some cleanup of these lately and the bug is for newton
15:55:27 <ganso> dustins: but it still should clear stuff if it fails, whenever able to
15:55:36 <dustins> ganso: Totally!
15:55:46 <tbarron> we're not going to backport fixes for this to newton
15:56:25 <tbarron> but tatyana is presumably working on a newer release?
15:56:46 <gouthamr> "create_networks_when_multitenancy_enabled" doesn't mean manila is going to create them, no? this code's in tempest
15:57:14 <gouthamr> and is part of the credential we acquire to run the test
15:58:20 <ganso> gouthamr: I need to double check this but I think it does create networks yes
15:59:26 <gouthamr> sure thanks ganso, i was planning on setting up the container driver to respond to another similar bug request
15:59:30 <tbarron> ok, we're about out of time, let's resolve this one in #openstack-manila
15:59:42 <tbarron> Any last minute remarks?
16:00:02 <gouthamr> ganso: but it might be a simple thing for you with NTAP dhss=true :P i'll ping you with a few qs
16:00:20 <tbarron> OK, thanks everyone -- review the access list priority spec!!!
16:00:29 <tbarron> #endmeeting