15:01:17 <gouthamr> #startmeeting manila 15:01:18 <openstack> Meeting started Thu Jan 30 15:01:17 2020 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:21 <openstack> The meeting name has been set to 'manila' 15:01:24 <vkmc> o/ 15:01:25 <dviroel> hi 15:01:26 <lseki> o/ 15:01:28 <carloss> hi 15:01:42 <amito> o/ hello! 15:01:44 <maaritamm> o/ 15:01:44 <tbarron> \o/ 15:02:08 <gouthamr> courtesy ping: xyang toabctl ganso jgrosso 15:02:32 <gouthamr> hello everyone o/ 15:02:44 <vhari> o/ 15:02:52 <carthaca> hi 15:02:58 <gouthamr> Here's the meeting agenda: https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting 15:03:16 <gouthamr> let's get started! 15:03:19 <gouthamr> #topic Announcements 15:03:40 <gouthamr> sticky announcement topic regarding the release schedule: 15:03:49 <gouthamr> #link https://releases.openstack.org/ussuri/schedule.html (Ussuri Release Schedule) 15:04:16 <gouthamr> We're two weeks away from new specification freeze 15:04:34 <gouthamr> and the code submission/testing freeze for brand new drivers 15:05:14 <gouthamr> Thanks for all teh reviews so far on the specs, we'll talk about a couple in a bit 15:05:37 <gouthamr> next, we have a date/venue announcement for the next PTG 15:06:09 <gouthamr> OpenDev+PTG event will be in Vancouver between June 8-11, 2020 15:06:22 <lseki> 🎉 15:06:30 <dviroel> \o/ 15:06:30 <gouthamr> couple of useful links that were shared on the openstack-discuss mailing list: 15:06:33 <gouthamr> #link https://openstackfoundation.formstack.com/forms/opendev_vancouver2020_volunteer (Volunteer for Program Committee, Track Moderation and Suggest topics for Moderated discussions) 15:06:38 <gouthamr> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012239.html (Relevant mailing list thread) 15:06:55 <gouthamr> i'm especially proud that the OpenStack community made the right choice with the name 15:07:27 <gouthamr> personally think it's in honor of a rockstar amongst us :) 15:07:29 <vkmc> yaay Vancouver 15:07:57 <tbarron> heh 15:08:14 <gouthamr> we'll release Victoria in Vancouver 15:08:36 <gouthamr> or start working on it there at least :P 15:08:41 <tbarron> watch out Vancouver 15:08:44 <vkmc> hahaha 15:08:54 <gouthamr> that's all i had in terms of announcements 15:09:01 <gouthamr> anyone else got any? 15:09:34 <gouthamr> #topic Rocky release is going to Extended Maintenance (EM) 15:09:40 <gouthamr> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012207.html (Extended Maintenance Announcement for OpenStack Rocky) 15:09:46 <gouthamr> #link https://etherpad.openstack.org/p/manila-stable-rocky-em (Manila Etherpad tracking unreleased Rocky changes) 15:10:09 <gouthamr> ^ couple of pointers and a heads-up to those on the Rocky release 15:10:39 <gouthamr> if you have any bugfixes that need to make it into the last release, let me know or update ^ etherpad 15:11:28 <gouthamr> i think there are a couple of fixes that are making their way back through train and stein, we'll see if they make it by Feb 24th 15:12:33 <gouthamr> a reminder that we will no longer tag a release when marked as being in "extended maintenance" 15:13:44 <gouthamr> also, CI will be best effort - if testing/infrastructure projects break on such releases, we will not prioritize fixing them 15:14:22 <gouthamr> backports ofcourse will be welcome as long as we can test them reasonably 15:14:54 <gouthamr> alright, that's all the back of the label said 15:15:18 <gouthamr> #topic Third Party CI check (dviroel) 15:15:31 <dviroel> o 15:15:33 <dviroel> o/ 15:15:34 <gouthamr> you're up dviroel - i'll play support cast to this topic 15:16:19 <dviroel> alright, at the end of the train release we started a spreadsheet with all third party drivers and their status 15:17:06 <dviroel> some changes were triggered for master and stable branches to check CIs status and also their python versions 15:17:29 <dviroel> the spreadsheet is the following 15:17:37 <dviroel> #link https://docs.google.com/spreadsheets/d/1dBSCqtQKoyFMX6oWTahhP9Z133NRFW3ynezq1CItx8M/edit#gid=0 15:18:39 <dviroel> regarding stable branches, there isn't too much to say, it seems that only NetApp and INFINItDAT are reporting tests results 15:19:17 <dviroel> In master we have a few more drivers running tests and Dell that was still running on py2.7 15:19:17 <amito> And we seem to be failing on those... 15:19:26 <dviroel> amito: yep 15:20:18 <amito> dviroel: I'll look into this... and also change the contact email to my email instead of the general "support@..." one 15:20:19 <dviroel> Dell CI seems stable lately so the python version may be outdated 15:21:13 <gouthamr> dviroel: thank you for taking the effort to put this information together so diligently 15:21:39 <dviroel> Now, I want to know from you the next steps on this. 15:21:52 <gouthamr> dviroel: do we edit stuff, or just comment? 15:22:35 <dviroel> It is looked for edit, but I can change the permission so you all can edit 15:22:36 <gouthamr> dviroel: i may have updates regarding Dell/EMC because i spoke to a bunch of their developers over email right before PTG 15:23:18 <gouthamr> there may be an update on the list of owners/emails for those drivers 15:23:29 <dviroel> gouthamr: cool, thanks 15:24:04 <dviroel> should we move forward now and send a email to the maintainers asking for updates? 15:24:09 <gouthamr> this link is useful on the manila wiki 15:24:55 <gouthamr> dviroel: yes, we could post this to openstack-discuss and allow maintainers to comment 15:25:14 <amito> dviroel: we'll look into the failures on the stable/* branches. 15:25:36 <gouthamr> amito: +1 15:25:51 <dviroel> gouthamr: sure, this is an important info to be added to the wiki 15:26:10 <dviroel> amito: thanks 15:26:17 <gouthamr> a few releases ago, we decided to relax the CI requirements on stable branches, especially because of fast-changing and flaky test infrastructure 15:27:16 <gouthamr> we still look for a vendor/maintainer to assure us that they've tested a patch before we merge it to stable branches 15:27:57 <gouthamr> so if the CI isn't working for a particular reason, let us know - we can possibly also help you find a fix 15:28:08 <dviroel> ++ 15:28:49 <dviroel> so, thats it for now 15:29:16 <gouthamr> test infrastructure has gotten a whole lot more stable: devstack-gate is frozen, tempest-lib got us away from compatibility issues, if you're using zuulv3 - it's been far more stable than v2/v2.5 imo 15:29:16 <dviroel> we'll update the table again and send an email on the list and to the maintainers 15:29:36 <gouthamr> dviroel++ thank you 15:29:50 <dviroel> gouthamr: yw 15:30:09 <gouthamr> dviroel: be sure to remind folks in your email that Train+ is expected to be run with python3 15:30:23 <dviroel> gouthamr: ok 15:31:28 <gouthamr> here's a link: https://governance.openstack.org/tc/goals/selected/train/python3-updates.html 15:31:52 <gouthamr> Train is expected to be tested on 3.6 and/or 3.7, because that's what customers will be running it on 15:32:32 <gouthamr> Ussuri's python support is going to be the same, expect changes in the Victoria cycle.. 15:32:39 <gouthamr> alright, anything else for the moment on this $topic? 15:33:27 <gouthamr> thanks, moving on... 15:33:27 <gouthamr> #topic Replication quotas (carloss/carthaca) 15:33:46 <gouthamr> thanks for joining us, carthaca, carloss - floor is yours.. 15:33:54 <carloss> thanks, gouthamr 15:34:05 <carloss> we have had some discussions about this topic previously... 15:34:43 <carloss> it was basically: fix the issue using share type extra specs x existent quota system 15:35:09 <carloss> in the remote-only PTG we have had further discussions and agreed to use the share type extra specs as a solution 15:35:34 <carloss> I've opened a bug few months ago and we have been updating it with some details and suggestions... 15:35:41 <carloss> #link https://bugs.launchpad.net/manila/+bug/1850545 15:35:41 <openstack> Launchpad bug 1850545 in Manila "Manila allows the creation of unlimited share replicas" [Medium,In progress] - Assigned to Carlos Eduardo (silvacarlose) 15:36:03 <carloss> carthaca noticed the bug and saw a comment of mine talking about the solution 15:36:28 <carloss> also, added a suggestion in an administator point of view, justifying that would be nice if we implement both approaches since they aren't mutually exclusive 15:36:30 <carloss> #link https://bugs.launchpad.net/manila/+bug/1850545/comments/6 15:37:50 <carloss> so we wanted to bring this topic to the meeting and have more people discussing about the B solution 15:38:58 <tbarron> I think B needs to be given some weight since the request for it comes from a real deployment, not just from us thinking about the problem a priori 15:39:32 <dviroel> tbarron++ 15:39:36 <tbarron> but A is is independent, right? that is, A could merge without having to wait for B 15:39:38 <vkmc> tbarron++ 15:39:42 <carloss> tbarron++ 15:39:55 <carthaca> yes, I think it is independent 15:40:11 <carloss> yes, tbarron... 15:40:12 <vkmc> seems that A fixes the problem easily in the short term, but B is a better (but more complex to implement) solution 15:40:26 <vkmc> imho 15:40:49 <gouthamr> makes sense 15:41:02 <tbarron> vkmc: s/imho/imo/ you are a rockstar now 15:41:03 <dviroel> A also fixes the problem of having backends with limited replicas per share, that may be another issue to be addressed 15:41:11 <vkmc> tbarron, lol 15:41:39 <gouthamr> carthaca: quota of share replicas per *project* - do you mean a total count of replicas alone, or sizes as well? 15:42:38 <gouthamr> we have both number and size in our quotas 15:42:52 <carloss> good question, gouthamr 15:43:01 <dviroel> ++ 15:43:02 <carthaca> sizes as well, its important for capacity planning 15:44:08 <carloss> gouthamr, does the implementation for B needs a spec or lite-spec? 15:44:18 <carloss> or just a blueprint is enough? 15:44:51 <gouthamr> yeah, thinking about that for a minute, there doesn't seem to be an issue to include this in our quota system - especially because the "secondary" backends are also managed by manila, perhaps elsewhere 15:45:54 <gouthamr> carloss: up to you, i don't see any API changes - so i don't mind you including this in your current spec too 15:46:29 <carloss> great 15:46:58 <carloss> I've noticed that you have created a blueprint in the past (https://blueprints.launchpad.net/manila/+spec/add-share-replica-quotas) which seems somehow related to B solution 15:47:10 <carloss> is it correct? or is this something different? 15:47:11 <gouthamr> carloss: have you checked the feasibility of this with our user and share type quotas? 15:47:59 <carloss> not deeply 15:48:05 <gouthamr> carloss: yes, this tenant wide quota was the initial proposal 15:48:18 <carloss> but I don't see any issues coming at moment 15:48:55 <gouthamr> carloss: cool, we can brainstorm this when you take a look - things to consider would be to provide teh consistency we currently have with project quotas, share type and user quotas 15:49:46 <carloss> alright 15:50:50 <gouthamr> thanks for bringing the questions here carloss, carthaca - looks like we are in agreement that the two part solution that we have can be implemented - and done so independently 15:51:15 <carloss> yes... yw, gouthamr 15:51:21 <carloss> that's all I had for this topic 15:51:27 <carloss> thank you all :) 15:51:37 <carthaca> thanks 15:52:05 <gouthamr> you're welcome.. let's chase the next topic 15:52:10 <gouthamr> #topic Tracking our work 15:52:32 <gouthamr> First up, specifications that need reviews: 15:52:33 <gouthamr> #link https://review.opendev.org/#/c/700776/ (Update Create Share from Snapshot in Another Pool) 15:53:07 <gouthamr> i had a couple of questions on that dviroel - although i agree with the general direction this spec is taking 15:53:23 <gouthamr> carthaca - your inputs would be valuable as well 15:53:33 <dviroel> gouthamr: sure, will answer all comments soon 15:53:43 <dviroel> thank you all for reviewing it 15:54:16 <gouthamr> ack, more reviews are welcome - i'd like to get this spec merged before the deadline.. 15:54:37 <gouthamr> #link https://review.opendev.org/#/c/704793/ (Add lite spec to fix unlimited share replicas per share) 15:54:43 <gouthamr> ^ deja vu 15:54:52 <carloss> haha 15:55:22 <dviroel> carloss: could you mention quotas as an alternative solution in this spec? 15:55:44 <carloss> yes, gouthamr 15:55:52 <carloss> I'll add a comment on the change 15:55:55 <gouthamr> dviroel: not an alternative, supplementary 15:56:18 <dviroel> gouthamr: yep 15:56:38 <gouthamr> Reviews needing attention: 15:56:42 <gouthamr> Noop interface driver (mnaser) 15:56:46 <gouthamr> #link https://review.opendev.org/#/c/704807/ 15:56:48 <mnaser> hola 15:56:52 <gouthamr> hey mnaser 15:57:08 <mnaser> so with my work on this i actually found a bunch of other tidbits and ended up with a stack here - https://review.opendev.org/#/c/705034/4 15:57:12 <vkmc> hola mnaser, bienvenido! 15:57:17 <mnaser> hi vkmc gouthamr :) 15:57:30 <gouthamr> #link https://review.opendev.org/#/q/topic:manila/generic-improvements+(status:open+OR+status:merged) 15:57:58 <mnaser> some are very trivial (i.e. flavor id assumption) and some are a bit more convuluted. but the overall idea is moving more stuff from service_instance out to linux interface 15:58:01 <mnaser> so the noop can be a real noop 15:58:05 <tbarron> fwiw i reloaded the agenda with the other patches too 15:58:27 <mnaser> (the whole idea behind it is that this is an environment where manila-share is *ALREADY* inside the admin network) 15:58:29 <tbarron> but wanted mnaser to explain his overall project/goals and get eyes on these 15:58:57 <mnaser> so there's no need to have neutron-(openvswitch|linuxbridge)-agent wiring things back and forth, because it's already sitting on the correct network 15:58:58 <tbarron> it's great to see work on the neglected generic driver service instance module 15:59:24 <mnaser> o/ 15:59:33 <mnaser> yep, it's actually pretty well setup and laid out tbh 16:00:14 <mnaser> given time constraints, i hope to improve the image elements too, they're pretty old and actually we can just use built in diskimage-builder stuff at this point 16:00:39 <mnaser> but i'm trying to get these bits to work for now. i'm just trying to get it to work first, once i get that, i'll try to fix up the tests if any and what not 16:01:06 <mnaser> but uh, how do we feel about the overall idea about generic driver possibly not controlling network bits on the host 16:01:26 <gouthamr> nice, thank you mnaser 16:02:29 <tbarron> mnaser: i think our intent was to have a plugin model that allows lots of network options and 16:02:31 <gouthamr> mnaser: i don't see a problem with the noop driver - how would you test this on a devstack though? 16:02:38 <tbarron> that what you are doing is consistent with that 16:03:07 <tbarron> we're overtime and may need to move to #openstack-manila 16:03:16 <gouthamr> oh wow :O 16:03:20 <gouthamr> lost track, ty tbarron 16:03:33 <gouthamr> sorry we can't get to bugs today vkmc 16:03:36 <gouthamr> vhari ^ 16:03:41 <mnaser> given time constraints, we can discuss the details later if need be 16:03:43 <vhari> gouthamr, nw :D 16:03:56 <gouthamr> thanks all of you for joining, see you on #openstack-manila 16:04:00 <gouthamr> #endmeeting