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