15:01:26 #startmeeting manila 15:01:26 hi 15:01:27 Meeting started Thu Dec 21 15:01:26 2017 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:30 The meeting name has been set to 'manila' 15:01:37 hello all 15:01:43 Hi 15:02:00 hello 15:02:16 courtesy ping: tbarron gouthamr toabctl xyang markstur vponomaryov cknight 15:02:23 hi 15:02:29 o/ 15:02:54 bswartz: you should include vkmc in that list :P 15:02:57 hmm we might be short of a quorum today 15:02:58 \o 15:03:17 bswartz: and dustins 15:03:19 =) 15:03:21 ganso: true -- I just constructed the courtesy ping list from the core reviewers 15:03:25 :) 15:03:36 But I could add anyone who wants to be on it 15:03:48 Cinder actually has their courtesy ping list on the wiki 15:04:21 * gouthamr_ sneaks in 15:04:28 bswartz: maybe we could do that as well 15:04:33 * bswartz marks gouthamr tardy 15:04:58 okay well I don't have any announcements for this week 15:05:05 hi 15:05:19 and no specific agenda items 15:05:34 however I am aware of the limited time until feature freeze, and the upcoming holidays 15:05:35 @! 15:05:36 <_pewp_> jungleboyj (;-_-)ノ 15:05:59 perhaps we should go over the list of features remaining for queens 15:06:51 ... 15:06:58 I thought we had more specs merged for queens 15:07:18 why do I only see 2? 15:07:40 We only merged 2 15:07:53 What about specs for community goals? 15:08:08 We didn't need specs for those 15:08:21 There isn’t a spec for community goals 15:08:51 okay I thought we talked about it and agreed to have a stub spec that pointed to the community spec 15:09:00 I could be misrememering though 15:09:07 misremembering 15:10:07 Well let's discuss the major things left to be done 15:10:13 #topic queens priorities 15:10:38 The ensure share stuff looks good to me at this point 15:11:12 I wish we could have automated testing that covered the upgrade/reconfiguration case for this feature 15:11:38 how are we doing on the policy-in-code goal? 15:11:53 pretty well! nearly done. 15:12:24 https://review.openstack.org/#/c/523819/ needs to merge for code-completion 15:12:33 We only have two partches need to be merged 15:12:42 okay 15:12:44 https://review.openstack.org/#/c/525115 is the last patch in the series 15:13:00 and the tempest plugin? 15:13:27 #link https://review.openstack.org/#/c/512300/ 15:13:28 We tested it, it is work 15:13:36 LGTM 15:13:40 Can we merge this today? 15:13:57 +1 15:13:58 We could have merged it last week but we held off because some vendors wanted time to test 15:14:18 I think so 15:14:36 I get that some CIs might blow up over the holidays, but holding off at this point is unlikely to help anyone 15:15:36 +1 15:15:43 we need the devstack-plugin-glusterfs and devstack-plugin-ceph folks to merge predecessor changes 15:15:53 #link https://review.openstack.org/#/c/514374/ 15:16:02 #link https://review.openstack.org/#/c/514381/ 15:16:11 who can make that happen? 15:16:39 gouthamr: i just did the ceph one 514381 15:16:39 any of you redhat guys have workflow power on those repos? 15:16:54 tbarron has ze powers :) 15:17:07 not on 514374 though 15:17:15 really? 15:17:19 i'll see if I can chase people down 15:17:21 who has the powers for that repo? 15:17:45 bswartz: probably csaba 15:18:00 rraja too, but he may be asleep 15:19:20 #link https://review.openstack.org/#/admin/groups/565,members 15:19:44 there's 4 people on the list 15:20:05 bswartz: I think maybe only csaba and rraja are around 15:20:09 tbarron, you think any of them are awake still? 15:20:25 I just pinged csaba since he's in Hungary but he's not on irc right now 15:20:31 we may want to clean up this group membership 15:20:58 Worst case I'll catch rraja tomorrow morning. Will ask that they add vkmc or me or something like that too. 15:21:00 why do we depend at all on the glusterfs change? 15:21:20 oh the CI is still running I see 15:21:20 tbarron: we need to fix manila rpm package also otherwise RDO and tripleo ci will break 15:21:26 we have the ci 15:21:26 yes 15:21:41 hi. I'm late 15:21:45 chandankumar: ack, did you just post a review for this? 15:21:56 xyang: hi 15:21:57 hey xyang! :D 15:22:04 tbarron: new package review is up https://review.rdoproject.org/r/#/c/11032/ 15:22:34 thanks chandankumar and tbarron 15:22:50 chandankumar: I read that specfile and it looks good to me; someone else has workflow powers there though. 15:23:09 please let's get this one workflowed today so anyone who needs to fix their 3rd party CI can start to do so right when they return from holidays 15:23:26 tbarron: it needs a proper review from RDO guys, i have pinged amoralej on #rdo 15:23:33 chandankumar: ack 15:23:45 are there any other big things still in the pipe? 15:23:49 IPv6-related changes? 15:24:00 Changes for replication? 15:24:02 yep a patch from ganso 15:24:13 none for replication.. 15:24:19 vkmc: you are here tomorrow - would you follow up with rraja and chandankumar if we don't get all this done today? 15:24:28 tbarron, sure 15:24:35 #link https://review.openstack.org/#/c/529142/ 15:24:40 tbarron: i will be around tomorrow 15:24:41 I see an unmerged spec related to replication 15:24:47 chandankumar: thanks 15:24:49 my changes will have to merge after the tempest plugin change 15:24:50 vkmc: thanks 15:25:13 bswartz: yes, we didn't plan on finishing that in queens 15:25:35 okay just checking 15:25:50 On IPv6 we have put in some tripelo deployment patches, basically just to toggle neutron plugin options if IPv6 environment files are chosen for the deploy 15:25:51 need to rewrite that spec with changes to dual IP networking 15:26:04 tbarron 15:26:06 I don't know if any of you were following the MASSIVE thread on openstack-dev about the rocky release 15:26:08 tbarron: nice 15:26:11 I'm now unclear on what will happen 15:26:12 vendors who are enabling ipv6 in their backends may want to test with these 15:26:31 * tbarron looks at VNX and NetApp 15:27:15 we'll be doing the same where possible 15:27:40 tbarron: is that expected to affect DHSS=true deployments only? 15:27:58 I think Huawei has backend support for IPv6 as well and would want to test with their deployment tool of choice. 15:28:42 tbarron: no now, but will be 15:28:45 bswartz: well the options for those plugins were put in before you added DHSS=True support 15:28:59 bswartz: I'd have to check exactly how they are used though. 15:29:21 tbarron: well for DHSS=false, there really aren't any config options related to ipv6 15:29:53 it would be worth testing that IPv6 literals are not rejected by any of the config building tools 15:30:04 bswartz: yeah, I guess the plugins don't get invoked 15:30:45 bswartz: but the options were merged in pike while we were saying we had support only for DHSS=false, future-proofing I guess 15:31:27 Who on the NetApp side plans to look at the OSP changes? 15:31:30 ganso has an interesting scenario test in review for IPv6 15:31:53 I know there will be a certification effort at some point, but IIRC 12 hasn't happened yet, so 13 would be after that 15:31:59 tbarron: =) 15:32:02 bswartz: to whom is your question addressed? 15:32:18 To NetApp 15:32:23 k 15:32:42 I'm not aware of any plans to test unreleased OSP 13 bits, so we could have a problem 15:33:32 We could have a test coverage gap and we might need to sound the alarm on that 15:33:52 bswartz: We may add support for IPv6 for CephNFS back end in which case we can test it end to end entirely ourselves but for now that's only DHSS=False 15:34:36 From what I know, NetApp is testing the heck out of driver with upstream queens bits, but there's no plans to test anything from tripleo 15:34:56 until after osp 13 is released and the cert tests happen 15:35:37 bswartz: ack, maybe just mention the issue. tripleo partners get pre-release bits. 15:35:51 bswartz: we can talk about it early in the new year. 15:35:57 okay 15:36:07 anything else then for today? 15:36:15 dustins: do you have bugs to cover? 15:36:39 bswartz: Yeah, just a few that we've gone over already that I wanted to check in on 15:36:55 #link: https://etherpad.openstack.org/p/manila-bug-triage-pad 15:36:56 #topic Let's go over new bugs 15:37:33 #link https://bugs.launchpad.net/manila/+bug/1717261 15:37:34 Launchpad bug 1717261 in Manila "NetApp drivers don’t create share of requested size when creating from snapshot" [Low,In progress] - Assigned to Goutham Pacha Ravi (gouthamr) 15:37:47 gouthamr: How's this going? 15:38:06 this seems like a duplicate 15:38:30 let me find the other bug (that was fixed) and mark this one duplicate 15:38:40 Sounds good to me 15:39:04 #link https://bugs.launchpad.net/manila/+bug/1708491 15:39:05 Launchpad bug 1708491 in Manila "tempest api migration tests very long" [Undecided,New] 15:40:13 Looks like this one we looked at and might not have decided what to do with it 15:40:17 we have discussed that one in the past and we never reach a conclusion about what to do with those tests 15:40:27 ganso: do we know what the issue is? 15:40:38 I feel like we should do something 15:41:03 at first I thought it was the periodic task, but gouthamr confirmed that the periodic task is already running as fast as possible 15:41:08 Either migrate less data (if it's a pure I/O bottleneck) or fix wherever the bottleneck is 15:41:18 bswartz: it is migrating an empty share 15:41:49 okay so there's really no reason for it to be so slow 15:42:06 we could increase the waiters polling rate 15:42:11 this will increase the stress on the host 15:42:23 I think it's worth fixing 15:42:29 what's the polling rate now? 15:42:39 it might end up not gaining much time as other parallel tests will be impacted by this stress 15:42:46 bswartz: lemme check 15:43:27 bswartz: "time.sleep(tries ** 2)" 15:43:31 bswartz: that on the server side 15:43:59 oh exponential backoff could be the culprit 15:44:20 bswartz: time.sleep(self.build_interval) on the tempest side 15:44:44 exponential backoff with an exponent of 2 means that the test can easily take twice as long as it needs to 15:45:00 bswartz: build_interval defaults to 3 seconds 15:45:06 ok 15:45:28 well what we really need is for someone to volunteer to own the bug and to track down the problem 15:45:39 it won't help much to theorize about it here 15:45:59 But it sounds like it's at least triaged 15:46:03 bswartz: well we supposedly have a fairly good lead of what the problem is 15:46:13 this is the kind of bug I'd like to work on myself after I wrap up the other scenario test work I have 15:47:03 dustins: any other? 15:47:23 next one is https://bugs.launchpad.net/manila/+bug/1713062 15:47:24 Launchpad bug 1713062 in Manila "Missing ability to automatically build configuration reference artifacts" [High,Triaged] 15:47:37 yeah this came from the PTG 15:47:41 ganso can copy and paste faster than me ;) 15:48:08 the plan of record was to copy what cinder did related to this docs change 15:49:20 Right, so who wants to do it? 15:49:21 jungleboyj: ^^ is this done now on the cinder side? 15:49:54 tbarron: To do it automatically out of the driver? 15:50:28 jungleboyj: to have something invoked by tox that builds these tables from the code for each driver 15:50:36 there is some code change so the doc building scripts can find the config options, but most of the change is in the docs themselves 15:50:57 tbarron: No, that isn't done yet. Kendall was working on that stuff and then dropped off the radar. 15:51:12 * tbarron blames kendall then :-) 15:51:14 I am hopefully going to have some people that can help out next year and start working on that kind of stuff. 15:51:41 We still have a lot of work to do on our config options. Making incremental progress. 15:51:47 I've been busy with other stuff and haven't looked at it myself yet. 15:52:08 well it's a docs improvement 15:52:09 Would be good to get it done this cycle. 15:52:11 tbarron: Actually, you know what you, probably shouldn't blame her. I think that one is my fault. 15:52:21 there's a window of time after feature freeze to tackle docs issues 15:52:21 I was doing the doc stuff and was supposed to look at that. 15:52:31 jungleboyj: I'm just joking anyways to be clear. 15:52:39 Anyway, long story short, not done. 15:52:59 I have been off in stand alone Cinder land for the last few months. 15:53:12 #link https://bugs.launchpad.net/manila/+bug/1733494 15:53:13 Launchpad bug 1733494 in python-manilaclient "Failed to allow user group access to the share" [Undecided,In progress] - Assigned to kedy (kedy) 15:53:52 kedy is working this? 15:53:55 I don't know who kedy is 15:53:57 Looks like it's in progress, just checking in on it 15:54:08 and abandoned by infra, nice :) 15:54:14 I put it up for the bug squish, IIRC 15:54:17 He is from h3c 15:54:22 okay 15:54:29 (restored now, no panic) 15:54:33 ok 15:54:50 #link https://bugs.launchpad.net/manila/+bug/1591357 15:54:51 Launchpad bug 1591357 in Manila "generic driver cannot remove user rule for NFS share" [Medium,New] 15:55:06 we shouldn't have user rules for NFS... 15:55:24 Is this obsolete? 15:55:38 ganso: ?? 15:55:38 ganso: you filed this 15:55:51 bswartz: we didn't modify the API to disallow user rules for nfs shares 15:56:05 we might need to retest 15:56:19 we didn't have the folks in the room that had user/ip access on NFS shares when we last discussed this 15:56:26 it could have been fixed with the access rules refactor we did back in ocata 15:56:54 I think it's decided already 15:56:59 no user-based access for NFS 15:57:11 wouldn't we do "user" for NFS using a sidecar security service, e.g. kerberos? 15:57:13 we should just fix the API to enforce it 15:57:31 tbarron: that's not how it works 15:57:49 the manila access is based on IP only 15:57:50 bswartz: I don't mean this kind of user access rule 15:58:12 file-based access can be per-user, handled in-based through the NFS protocol 15:58:22 it's a different kind of thing though 15:58:43 ack, really didn't mean to be suggesting otherwise 15:59:00 okay 15:59:06 #topic open discussion 15:59:10 we were talking share access and I went on a tangent 15:59:30 we managed to use up the whole hour 15:59:38 next week's meeting is cancelled 15:59:42 I'll make a note on the wiki 16:00:08 we're planning to meet Jan 4 unless I send out an ML post saying otherwise 16:00:21 enjoy your holidays everyone! 16:00:25 Happy Holidays! :) 16:00:33 Happy holidays! 16:00:34 and Happy New Year! 16:00:59 happy holidays! 16:00:59 enjoy, all! 16:01:02 #endmeeting