15:00:23 <tbarron> #startmeeting manila
15:00:24 <openstack> Meeting started Thu Jul 25 15:00:23 2019 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:27 <openstack> The meeting name has been set to 'manila'
15:00:28 <carloss> hi o/
15:00:29 <gouthamr> o/
15:00:30 <vkmc> o/
15:00:46 <dviroel> o/
15:00:53 <bswartz> .o/
15:00:55 <tbarron> courtesy ping: gouthamr xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso dviroel lseki carloss
15:01:04 <s0ru> o/
15:01:09 <xyang> hi
15:01:12 <ganso> hello
15:01:37 <vhariria> hello
15:01:38 <tbarron> well xyang and ganso are here, we can probably start in a minute :)
15:01:54 <tbarron> Agenda:
15:02:12 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:02:20 <tbarron> Hi all!
15:02:31 <tbarron> #topic announcements
15:02:48 <tbarron> Only one from me, it's Train Milestone 2
15:03:47 <tbarron> This is also the Manila driver deadline
15:04:01 <tbarron> "new backend drivers for Manila must be substantially complete, with unit tests, and passing 3rd party CI. Drivers do not have to actually merge until feature freeze."
15:04:21 <tbarron> we'll talk about the un-merged driver reviews in a little bit.
15:05:09 <tbarron> It's also spec freeze but we don't have any spec reviews pending.
15:05:52 * ganso brb someone at the door
15:05:58 <tbarron> Any other announcements?
15:07:14 <tbarron> #topic Python3 for 3rd party CI
15:08:04 <tbarron> Folks, we need to get 3rd party CI jobs running with python 3
15:08:10 <tbarron> 3.6 or higher is fine
15:08:37 <tbarron> Cinder is asking for 3.7 but I think the default with bionic is just fine
15:09:44 <tbarron> If you have a 3rd party CI please communicate back to the folks who care about what you are working on
15:09:49 <tbarron> that this is a necessity.
15:10:17 <tbarron> It may help to tell them that major distros are going to be py3 default or py3 only real soon now
15:10:31 <tbarron> for example, RH OSP 15 will be py3 only.
15:11:22 <tbarron> I think your driver's code is probably just fine but with CI still running with py27 it's not provable.
15:11:22 <gouthamr> ^ which is based on the Stein release
15:11:29 <tbarron> gouthamr: ty
15:11:36 <dviroel> ack
15:11:50 <tbarron> dviroel: Thanks for responding!
15:12:20 <tbarron> I will be following up with email to openstack-discuss but wanted to bring it up here as well.
15:12:50 <tbarron> dviroel: Has netapp had a chance to try CI with python 3 yet?
15:13:32 <dviroel> We started to test against 3.7 at this moment.
15:14:04 <tbarron> dviroel: excellent
15:14:11 <dviroel> Should have some feedback in the next week
15:14:35 <tbarron> Anyone else here today who can speak for their 3rd party CI?
15:14:56 <tbarron> crickets
15:15:08 <tbarron> Well NetApp will set a good example :)
15:15:36 <tbarron> #topic Our Work: Reviews
15:15:57 <tbarron> #link https://review.opendev.org/#/c/657775/
15:16:15 <tbarron> This is the Infortrend driver, a new driver
15:16:35 <tbarron> I want to thank gouthamr for tireless work reviewing this one.
15:17:04 <tbarron> It is passing CI now and has had lots of code improvements.
15:17:24 * ganso back
15:17:29 <tbarron> So it has made the M2 driver deadline.
15:17:35 <tbarron> ganso: hi again :)
15:18:07 <tbarron> Can we get another core to volunteer to review this one?
15:19:21 <tbarron> OK, I'll have to volunteer someone myself I guess :)
15:19:48 <tbarron> #link https://review.opendev.org/#/c/664269/
15:20:03 <tbarron> This is the Nexenta Stor 5 NFS driver refactor
15:20:17 <tbarron> gouthamr has again been the main reviewer
15:20:17 <gouthamr> ^ this one is near-ready - fails pylint, but fixes deficient
15:20:54 <tbarron> missing noun
15:20:58 <tbarron> :)
15:21:34 <tbarron> We need some more eyes on this one, gouthamr has done the heavy lifting on it already.
15:22:07 <tbarron> That's it for driver reviews, I think.
15:22:32 <tbarron> #link https://review.opendev.org/#/c/671031/
15:22:59 <tbarron> This one picks up the work that I started and then slacked off on to convert all the first party jobs to python3
15:23:18 <tbarron> I think it's ready to merge, and at M2 we really need to be doing this.
15:23:31 <tbarron> There's one anomaly.
15:23:33 * gouthamr +2
15:23:47 * gouthamr anomaly -1, patch +2
15:24:07 <tbarron> As some of you may know, the dummy job runs tempest twice, once with DHSS True and once with it False
15:24:31 <tbarron> In the second run tempest is running with python 2.7
15:24:45 <tbarron> manila is running with python 3.6 throughout
15:25:15 <tbarron> I can't figure out what is causing this but it doesn't seem a sufficient issue to hold up progress.
15:26:37 * amito walks in
15:26:39 <tbarron> xyang: ganso bswartz please review and let's move on this one today if there's no other issues found
15:26:43 <tbarron> amito: !!
15:27:00 <tbarron> amito: great to see you, you are a good driver reviewer too!
15:27:15 <tbarron> amito: don't hide, I'll catch you in a minute :)
15:27:26 <amito> Thanks :) I'll try to help and do my best
15:28:05 <tbarron> #link https://review.opendev.org/#/q/topic:CephFS-NFS-IPv6+(status:open+OR+status:merged)
15:28:30 <tbarron> bswartz: ^^ thanks for your review of these, they are ready for another pass
15:29:16 <tbarron> #link https://review.opendev.org/#/c/647538/ remove keystoneclient dependency from manilaclient
15:29:26 <bswartz> Should there be 4 changes on that link?
15:29:34 <tbarron> vkmc: this one has my +1 but it's not an area where I am strong?
15:29:40 <tbarron> strong
15:29:52 <tbarron> so I asked Colleen to take a look
15:29:57 <vkmc> tbarron++
15:30:00 <vkmc> thanks for reviewing
15:30:20 <tbarron> toabctl: 647538 is ready again
15:30:26 <vkmc> yes, also wanted to ask toabctl since he started with that work some time ago
15:30:42 <cmurphy> o/ i'll take a look today
15:30:48 <vkmc> cmurphy, \o ty
15:30:57 <tbarron> cmurphy: excellent, thanks!
15:31:14 <tbarron> bswartz: you can skip the puppet-manila patch
15:31:53 <tbarron> bswartz: but feel free to weigh in if you have a view on it of course
15:32:21 <tbarron> #link https://review.opendev.org/#/c/650986/
15:32:39 <tbarron> This is carloss pagination speed up
15:32:45 <tbarron> It has my support
15:32:52 <tbarron> Please review
15:32:52 <carloss> thanks for reviewing tbarron :)
15:33:01 <carloss> will work on the comment you posted in the patch
15:33:06 <tbarron> carloss: cool
15:33:25 <tbarron> Finally (from my list at least)
15:33:38 <tbarron> #link https://review.opendev.org/#/q/topic:bp/share-network-multiple-subnets+(status:open+OR+status:merged)
15:33:54 <carloss> we're about to update this PS with the unit tests
15:33:57 <tbarron> This is WIP but ready for constructive review
15:34:16 <tbarron> carloss: good, that saves me putting on -1 saying please add unit tests :)
15:34:17 <carloss> this PS = the one with the core changes :p
15:34:30 <carloss> tbarron: haha
15:35:27 <tbarron> We've got about a month or so to get this one done but it is non-trivial so it's time to get serious review under way.
15:35:58 <tbarron> Anyone else have reviews that they want to call attention to today?
15:36:15 <carloss> tbarron: thanks :)
15:36:41 <tbarron> #topic Bugs
15:36:57 <tbarron> vhariria: do you have some for us to consider today?
15:38:05 <vhariria> tbarron: yes some notes from jgrosso
15:38:05 <tbarron> jgrosso has a conflict but gave me this link:
15:38:07 <vhariria> https://bugs.launchpad.net/manila/+bug/1635393    Please check comments about tenacity (tbarron: I asked boden why he abandoned the proposed fix)
15:38:08 <openstack> Launchpad bug 1635393 in Manila "Replace usage of 'retrying' with 'tenacity'" [Undecided,In progress] - Assigned to Boden R (boden)
15:38:12 <tbarron> vhariria: ack
15:39:01 <tbarron> Long story short on this one, retrying library is not beiing maintained so there was a movement to replace
15:39:09 <tbarron> its usage with 'tenacity'
15:39:23 <tbarron> We only use it in one place.
15:39:41 <tbarron> A review was posted to do this but it didn't have unit test updates.
15:39:58 <tbarron> Review poster abandoned the review when it failed unit tests.
15:40:07 <gouthamr> the one place we use it is a helper function we use all over :)
15:40:19 <tbarron> gouthamr: right
15:40:31 <gouthamr> https://review.opendev.org/#/q/project:openstack/cinder+message:%255Etenacity
15:40:33 <tbarron> gouthamr: i'm just saying it's a small fix
15:40:36 <gouthamr> similar status on cinder ^
15:41:03 <tbarron> so if anyone is interested I'm sure they can pick it up
15:41:30 <vhariria> tbarron: ack
15:42:09 <tbarron> vhariria: I marked it low priiority, nothing is broken
15:42:24 <vhariria> ack, moving on to the next https://bugs.launchpad.net/manila/+bug/1514331
15:42:25 <openstack> Launchpad bug 1514331 in watcher "Replace oslo_utils.timeutils.isotime by datetime.datetime.isoformat" [Low,Fix released] - Assigned to zhongshengping (chdzsp)
15:42:37 <vhariria> looking for a bit more clarification on this one
15:42:45 <tbarron> vhariria: that one is actually fixed
15:43:13 <vhariria> tbarron: ah cool..  will sync up with jgrosso
15:43:34 <tbarron> vhariria: I added comment to that effect and indicated that it was included in 5.0.0 release
15:43:39 <vkmc> is it fixed?
15:43:44 <tbarron> vhariria: it's good that jgrosso found it
15:43:48 <vkmc> found this abandoned patch set related? https://review.opendev.org/#/c/394292/
15:43:50 <tbarron> dangling there
15:44:08 <tbarron> vkmc: there's another review that fixed this, under a different LP number
15:44:13 <vkmc> oh nice
15:44:15 <vkmc> :)
15:44:18 <vhariria> hah!
15:44:22 <vhariria> :)
15:44:23 <tbarron> https://review.opendev.org/#/c/468824/
15:45:12 <vhariria> so  looks like we have one more bug needing feedback from gouthamr :)
15:45:22 <vhariria> https://bugs.launchpad.net/manila/+bug/1607150
15:45:23 <openstack> Launchpad bug 1607150 in Manila "Tempest test for dr/readable replication fails because share has two active replicas" [Medium,New] - Assigned to NidhiMittalHada (nidhimittal19)
15:46:09 <gouthamr> jgrosso's ping went into an email blackhole
15:46:22 <vhariria> gouthamr: good he's not here :)
15:46:30 <tbarron> vhariria: let's unassign this one, nidhi isn't working on it
15:46:43 <gouthamr> okay, this bug must still be occurring occasionally on the CI, but it doesn't occur that often to annoy us
15:47:08 <gouthamr> it's a test-only issue - because the test's written pretty tightly to verify stuff on a loop
15:47:47 <gouthamr> and for a brief second, it gets pulls data before all the replicas are updated after a promotion
15:47:51 <tbarron> gouthamr: test-only in that a customer is unlikely to hit it or cannot hit it
15:48:11 <tbarron> gouthamr: seems like unlikely but possible, right?
15:48:13 <gouthamr> tbarron: even if they do, it's not a critical issue
15:48:33 <vhariria> got it, will do.. and loop back later if needed
15:48:49 <tbarron> then why is it medium importance?
15:49:05 <gouthamr> vhariria: you can pop off the assignee - i'll respond to the bug
15:49:25 <tbarron> gouthamr: please explain why it's no big deal and bump it down
15:49:37 <vhariria> gouthamr: ack
15:49:58 <vhariria> if no more thoughts .. that's all we have today
15:50:01 * tbarron is campaigning not to have so many medium and high priority bugs that no one actually  is going to work on
15:50:02 <gouthamr> this also just occurs with the dummy driver btw - never seen it occur with zfsonlinux, netapp, or huawei which do real things
15:50:15 <tbarron> gouthamr: thanks!
15:50:55 <tbarron> #topic OSC usage of set/unset logic
15:50:57 <vhariria> gouthamr and tbarron thanks
15:51:02 <tbarron> s0ru: this is you, right?
15:51:16 <s0ru> yes!
15:51:48 <s0ru> I had a question about a specific command
15:52:35 <s0ru> Seeing that 'manila update' can only change 'name', 'description' and 'is_plublic', I think the set will be for these three and unset for name and description ... because is_public can only be True or False .. Can that be weird?
15:53:52 <tbarron> s0ru: so you are saying 'is_public' cannot be unset, only set to True or False, right?
15:54:09 <s0ru> yes, for this case
15:54:23 <vkmc> hmm that wouldn't be the issue
15:54:33 <gouthamr> s0ru: "update" was for changing fields on the share
15:54:43 <vkmc> I see it more troublesome and confusing the fact that there are properties you cannot remove
15:55:08 <gouthamr> s0ru: but, when moving to OSC, i noticed that you could also use "set/unset" to change metadata of resources
15:55:09 <s0ru> oh, and that
15:55:37 <vkmc> I wonder how other services handle these cases
15:55:39 <gouthamr> s0ru: i mean, the way it's implemented currently for volumes (cinder), servers (nova), etc.
15:55:45 <vkmc> so maybe we can follow up their example
15:56:20 <gouthamr> s0ru: so, take a look at share-metadata - we have set and unset for metadata currently
15:56:57 <gouthamr> s0ru: you need both set and unset because sometimes, you don't want to just set a metadata key to "null", you'll want to remove the metadata altogether
15:57:32 <gouthamr> s0ru: i empathize with your question however, i had this myself when i was browsing the openstackclient repo :)
15:57:34 <vkmc> gouthamr, what does that mean in the db?
15:57:45 <gouthamr> vkmc: delete metadata row
15:58:04 <gouthamr> s0ru: you can have a "whitelist" of items you're allowed to "unset"
15:58:22 <gouthamr> s0ru: so in our case, it would be name, description, metadata items
15:58:49 <gouthamr> s0ru: if users attempt to unset anything else, you'd raise an error...
15:59:12 <s0ru> alright, I think I got it
15:59:26 <tbarron> s0ru: cool, anything else on this topic?
15:59:48 <tbarron> Well thanks everyone, we're out of time for today.
15:59:48 <s0ru> for now, it's ok
15:59:57 <s0ru> thanks :)
15:59:59 <tbarron> See you on #openstack-manila !!
16:00:04 <tbarron> #endmeeting