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