15:00:17 <tbarron> #startmeeting manila 15:00:18 <openstack> Meeting started Thu Sep 6 15:00:17 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:22 <openstack> The meeting name has been set to 'manila' 15:00:31 <bswartz> .o/ 15:00:35 <zhongjun2_> Hi 15:00:44 <gouthamr> o/ 15:00:56 <tbarron> ping xyang 15:01:02 <tbarron> ping ganso 15:01:07 <tbarron> ping erlon 15:01:08 <ganso> hello 15:01:11 <tbarron> ping tpsilva 15:01:15 <tbarron> ping vkmc 15:01:27 <tbarron> Hi all 15:01:36 <tpsilva> hello 15:01:46 <tbarron> Agenda: https://wiki.openstack.org/wiki/Manila/Meetings 15:01:59 <tbarron> Probably a short meeting today ... 15:02:20 <tbarron> #topic Announcements 15:02:28 <tbarron> Next week is PTG! 15:02:51 <tbarron> Amit just pinged me, he's in SFO on his way to the rockies ... 15:03:06 <tbarron> We won't have *this* meeting next week. 15:03:21 <tbarron> But we'll meet for PTG on Monday and Tuesday. 15:03:42 <tbarron> Tune in to #openstack-ptg for real-time updates. 15:04:07 <tbarron> ganso: are you still planning on bringing the webcam? 15:04:17 <ganso> tbarron: yes! 15:04:36 <tbarron> ganso: excellent. We'll do remote connectivity the way we did in Dublin then. 15:04:52 <bswartz> What meeting platform will you use? 15:05:13 <tbarron> In dublin we ended up with bluejeans iirc. 15:05:22 <tbarron> vkmc got it going. 15:05:51 <tbarron> I will check with her. 15:05:56 <bswartz> +1 for the AV club 15:06:01 <ganso> afaik bluejeans is easier to convert to a video format than webex. I remember gouthamr saying it was a lot of effort to convert the videos to upload to youtube 15:06:22 <tbarron> she mad some nice youtube recordings for us. 15:06:45 <tbarron> people can set up webex for an additional voice channel if useful. 15:06:47 <gouthamr> yeah, cisco had a proprietary converter that stopped working for the latest webex 15:07:03 <gouthamr> don't know if they released/fixed the converter 15:07:14 <tbarron> but bluejeans has a perfectly good dialin for phone 15:07:37 <bswartz> No complaints about bluejeans 15:07:43 <tbarron> and you can run it on android, etc. if you don't want to pollute your notebook. 15:07:51 <tbarron> kk 15:08:05 <tbarron> Reminder that the planning etherpad is: 15:08:12 <tbarron> in the channel topic 15:08:14 <tbarron> and 15:08:14 <bswartz> Although bluejeans has the distinction of being the only app to ever cause a kernel panic on my laptop 15:08:30 <tbarron> #link https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018 15:08:36 <tbarron> bswartz: it eats ram 15:09:12 <tbarron> I'll spend some time cleaning up that page but go on and dump ideas into it. 15:09:31 <tbarron> Also indicate there or ping me with any time restriction/topic interestes. 15:09:50 <tbarron> Remember we're on mountain time, UTC-6 I think. 15:10:09 <bswartz> Do you plan to go 9AM-5PM local time? 15:10:21 <tbarron> zhongjun2_: we'll be sure to talk about access-list-prio early 15:10:30 <zhongjun2_> Thanks 15:10:44 <tbarron> bswartz: yes, at least start at 9. Maybe we don't have to go till 5. 15:11:06 <tbarron> There will be lots of remotees to the east of us. 15:11:31 <tbarron> We might do some working sessions towards the end of the day Monday and Tuesday. 15:11:40 <bswartz> I'll miss being able to hang out with you guys 15:12:01 <tbarron> bswartz: we are going to miss you! It will feel really different. 15:12:04 <bswartz> But I'll stay as late as I can on the remote connection 15:12:28 <tbarron> We'll have a team dinner with the Cinder folks Tuesday night at 7:30. 15:12:37 <ganso> bswartz: :'( 15:12:44 <tbarron> jungleboyj and amito are planning where. 15:12:45 <bswartz> At that place with the pork wings? 15:12:51 <tbarron> so stay tuned ... 15:13:13 <ganso> bswartz: not sure if the dinner will be there, but I'll surely head there grab some pork wings 15:13:15 <tbarron> We'll start Monday with a retrospective on rocky. 15:13:37 <tbarron> I set up an etherpad which you can start filling out *now*! 15:13:56 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-retrospective 15:14:18 <tbarron> Please take a little time to think about what went well and what we can do better in Stein. 15:14:54 <tbarron> Also, we have through Tuesday to brainstorm on topics for the Berlin Forum. 15:15:17 <tbarron> Pls. think of stuff that we should discuss with Operators. 15:15:27 <tbarron> And note ideas here: 15:16:00 <tbarron> #link https://etherpad.openstack.org/p/manilap-berlin-forum-brainstorm 15:16:38 <gouthamr> tbarron, typo in the title :) 15:16:39 <tbarron> In Vancouver we had several high performance / scientific sig type folks in the room for this 15:17:02 <tbarron> gouthamr: I'll make a new etherpad in a moment w/o the typo 15:17:07 <tbarron> gouthamr++ 15:17:42 <tbarron> and I'll add a bit of context to the pad 15:17:59 <tbarron> #link https://etherpad.openstack.org/p/manila-berlin-forum-brainstorm 15:19:13 <tbarron> anyways, the Vancouver session was worth it for meeting the people who showed up, Minn Supercomputing Center, the big array telescope whose acronym is escaping me, and CERN of course 15:19:25 <tbarron> SKA 15:19:32 <tbarron> square kilometer 15:20:14 <tbarron> I'll email the dev and ops lists with these etherpad links. 15:20:23 <tbarron> And solicit input. 15:20:37 <tbarron> Any other announcements? 15:21:02 <tbarron> #topi Open Discussion 15:21:09 <tbarron> #topic Open Discussion 15:21:14 <ganso> I have a topic 15:21:24 <tbarron> ganso: go for it 15:21:35 <ganso> my team is working for a functional test for a specific bug we are fixing 15:22:04 <ganso> the test involves creating an additional neutron subnet and then creating 1 share on each subnet (2 total) 15:22:30 <ganso> there is a cleanup problem to delete the neutron subnet 15:22:38 <ganso> it says it has a port in use 15:22:56 <bswartz> Any nova VMs involved? 15:22:57 <ganso> it needs a sleep of 20 seconds to pass the test without complaining about ports in use 15:23:02 <ganso> bswartz: no VMs 15:23:11 <bswartz> What happens during those 20s? 15:23:29 <tbarron> ganso gets quick coffed 15:23:32 <tbarron> coffee 15:23:44 <ganso> bswartz: I believe that it gives time to delete the share server and clear out all allocated neutron ports 15:23:48 <gouthamr> ganso: are you explicitly cleaning up the share server? 15:24:00 <bswartz> 20s isn't much time to get coffee 15:24:14 <ganso> gouthamr: at the moment, we aren't. We are doing experiments on another class with admin client to do that 15:24:28 <gouthamr> s/coffed/covfefe 15:24:36 <ganso> bswartz: if the coffee machine is right beside you, it is 15:24:37 <bswartz> I think gouthamr is onto the right idea 15:25:00 <bswartz> In a testing context, you need to use an admin credential to force deletion for cleanup purposes 15:25:11 <bswartz> Otherwise the required wait time is hard to guess 15:25:39 <bswartz> Even if you had a proper wait loop that queried on readiness for deletion, you can't bound how long that loop will run 15:25:41 <ganso> bswartz: yes, but I believe our mechanism is a bit flawed, in the sense that it is a bit incompatible with our current cleanup strategy 15:25:50 <ganso> when we delete shares, share servers are not deleted instantly 15:26:04 <bswartz> But they should be 15:26:06 <ganso> I tried to set that flag "delete_share_server_with_last_share" and it still did not work 15:26:07 <gouthamr> ganso: all test classes that create a share should have an admin client now, thanks to vkmc's latest work.. 15:26:41 <bswartz> ganso that last thing might be a bug 15:26:56 <ganso> gouthamr: hmmm I didn't know that in detail. Will test to see if I have access to admin client now 15:26:57 <bswartz> Or if the deletion is asynchronous, it might have started but not finished 15:27:19 <bswartz> You need a way to synchronously delete for testing purposes 15:27:39 <ganso> so, one thing I know, is that when deleting a share server, after the teardown, the driver returns, and then the manager does some stuff, and lastly, it sends an asynchronous (AFAIK) request to neutron to deallocate the ports 15:28:04 <ganso> but I was still surprised that it took 20 seconds for the ports to be cleared up. That's too much 15:29:01 <ganso> the sleep proves that there is nothing wrong other than things that should be cleared immediately instead of relying on a timer to do so (or at least be configurable (and working, as "delete_share_server_with_last_share" seems to not be working properly)) 15:29:06 <gouthamr> i'm surprised the share server was always cleaned up with a 20s delay 15:29:18 <ganso> bswartz: the delete is not asynchronous as we have a waiter right after the delete 15:29:21 <gouthamr> because the default automatic cleanup interval is 10 mins 15:29:52 <gouthamr> oh wait, you mentioned you turned off automatic cleanup, and set "delete_share_server_with_last_share" instead 15:29:53 <ganso> gouthamr: yea I found in the config options saying that the "minimum is 10 min", clearly it is being deleted in less than 10 minutes 15:30:49 <ganso> I am actually confused as to what is causing the share server to be deleted. With "delete_share_server_with_last_share" set to False, it still gets cleared within 20 seconds 15:30:54 <gouthamr> ganso: 10 mins absolute with best effort, that begins with manila/share process.. so some lag might occur 15:31:44 <bswartz> Ah 15:32:05 <bswartz> I bet that delete_share_server_with_last_share is what's ensuring that it happens relatively quickly (20 seconds instead of 10 minutes) 15:32:16 <ganso> right now, I am investigating this https://github.com/openstack/manila-tempest-plugin/blob/master/manila_tempest_tests/tests/api/admin/test_share_servers.py#L245 15:32:21 <ganso> as it could lead me to the answer 15:32:30 <ganso> bswartz: but that flag is disabled 15:32:30 <gouthamr> ganso: you're using pre-provisioned test credentials and not dynamically creating them? 15:32:38 <ganso> gouthamr: I tried with both, result is the same 15:32:41 <bswartz> Maybe the wait loop is waiting on the wrong thing 15:33:36 <ganso> bswartz: could be 15:33:55 <ganso> but I get the feeling that this cleanup of share servers will need some refactoring 15:34:09 <ganso> as it is not working as it is intended to be 15:35:02 <ganso> anyway this is what I had to say 15:35:21 <tbarron> ganso: thanks for bringing the issue to our attention 15:35:32 <tbarron> ganso: and thanks in advance for fixing it 15:35:37 <tbarron> :) 15:35:40 <ganso> =) 15:35:40 <gouthamr> +1 15:35:48 <ganso> gotta squash those bugs 15:35:56 <tbarron> Anything else today? 15:36:11 <tbarron> 3 15:36:17 <tbarron> 2 15:36:24 <tbarron> 1 15:36:27 <bswartz> ty! 15:36:31 <tbarron> OK, thanks all!! 15:36:36 <tbarron> #endmeeting