15:01:30 <tbarron> #startmeeting manila
15:01:31 <openstack> Meeting started Thu Jul 18 15:01:30 2019 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:35 <openstack> The meeting name has been set to 'manila'
15:01:36 <bswartz> .o/
15:01:37 <carloss> o/
15:01:39 <tbarron> courtesy ping: gouthamr xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso dviroel lseki carloss
15:01:44 <ganso> hello
15:01:45 <dviroel> o/
15:01:52 <tbarron> ganso!
15:02:09 <amito> o/
15:02:31 <s0ru> o/
15:02:31 * tbarron waits a couple minutes
15:02:32 <vkmc> o/
15:03:21 <tbarron> Hi all!
15:03:22 <jgrosso> hi\
15:03:41 <gouthamr> o/
15:03:52 <tbarron> Here's our agenda for today:
15:04:00 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings#Weekly_Manila_team_meeting
15:04:10 <tbarron> #topic announcements
15:04:22 <tbarron> Just a reminder that M2 is next week.
15:05:02 <tbarron> Also, you can vote for OpenInfra summit presentations here:
15:05:09 <tbarron> #link https://www.openstack.org/summit/shanghai-2019/vote-for-speakers
15:05:23 <tbarron> voting closes Monday iirc
15:05:52 <tbarron> It works kinds 'murican style, you can vote and the vote might or might not count for something
15:06:04 <bswartz> Hah
15:06:35 <tbarron> But if you have candidates you like it might help to vote for them.
15:06:51 <tbarron> Any other announcements?
15:06:54 <gouthamr> can we have a debate first?
15:07:12 <tbarron> gouthamr: we don't have enough participants
15:07:17 <ganso> tbarron: lol best analogy
15:07:43 <tbarron> #topic Our work: reviews
15:08:41 <tbarron> #link https://review.opendev.org/#/c/657775/
15:08:51 <tbarron> This is the Infortrend driver
15:09:05 <tbarron> gouthamr: thanks for your good work reviewing this one
15:10:06 <tbarron> My impression is that the code is pretty good at this point but that they are failing CI still.
15:10:29 <tbarron> also thanks to lseki for reviewing
15:11:30 <tbarron> Mostly I just want to get attention from others on this one.  It's the only new driver outstanding.
15:11:40 <tbarron> Although there's a big refactor for nexenta.
15:12:16 <tbarron> #link https://review.opendev.org/#/c/664269/
15:12:58 <tbarron> ok, if no one has remarks on these ....
15:13:28 <tbarron> #link https://review.opendev.org/#/c/647538/
15:13:36 <tbarron> This one is yours, vkmc
15:13:49 <vkmc> yas!
15:14:00 <tbarron> Is it all ready for review?
15:14:04 <vkmc> all ready
15:14:25 <vkmc> with that we get rid of keystoneclient and we use keystoneauth instead, it's an old tech debt we had
15:15:16 <tbarron> Yup, good stuff.
15:15:30 <vkmc> there is more work to do on the unit tests front to make this cleaner, they need some refactoring, I can propose a follow up patch
15:15:47 <tbarron> toabctl: I know you reviewed this in April but it's ready for review again now.
15:16:09 <tbarron> vkmc: cleaner or to get adequate coverage?
15:16:17 <vkmc> tbarron, cleaner
15:16:33 <tbarron> vkmc: yeah, I don't have a sense that coverage slips with this patch.
15:17:12 <vkmc> we could add more tests to try different paths though, I'm open to discussion for this
15:17:38 <tbarron> vkmc: so followup work is fine on that front.  Coverage job is passing and unit tests are passing.
15:17:50 <tbarron> Let's get some non red hat reviewers on this one please.
15:18:30 <tbarron> #link https://review.opendev.org/#/c/667744/
15:18:41 <tbarron> s0ru: this one is yours
15:18:48 <s0ru> :o
15:18:54 <tbarron> s0ru: tell us all what it does please
15:19:58 <s0ru> it catches the error for manila list --count True with zero shares
15:20:24 * tbarron reminds everyone that s0ru is our outreachy intern, let's help her help us succeed!
15:20:51 <tbarron> s0ru: and this one is ready except maybe an issue with a unit test?  or did you get that resolved yet?
15:20:57 <s0ru> *me sweats
15:21:06 <tbarron> heh
15:21:13 <bswartz> The command is /me
15:21:36 * bswartz ducks
15:21:45 <vkmc> s0ru and I discussed about that yesterday
15:21:46 * s0ru know I sweat
15:22:13 <s0ru> yes, I'm working with vkmc on that
15:22:23 <tbarron> s0ru: we appreciate your hard work and you are permitted to throw fish at bswartz when he ducks under his desk
15:22:29 <vkmc> I had to try her patch in my local env and then see in which unit tests this could be added or if we need to add a new unit test
15:22:55 <tbarron> s0ru: vkmc: ok, seems like you are making good progress and aren't blocked then
15:23:23 * s0ru throwing fish somewhere(?
15:23:24 <vkmc> :D
15:23:26 <tbarron> s0ru: is there any more help you need on this or on the OSC work?
15:23:36 <tbarron> s0ru: we'll explain afterwards :)
15:23:58 <s0ru> I guess for the unit test since I've never did one
15:24:22 <s0ru> on OSC I'm making good progress, at least I'm not feeling stuck :)
15:24:37 <s0ru> (real stuck)
15:24:39 <tbarron> s0ru: ok, and vkmc is helping with that so she'll let us know ...
15:24:48 <tbarron> s0ru: good, don't be shy :)
15:24:58 <s0ru> yes n.n
15:25:00 <tbarron> Finally
15:25:15 <tbarron> #link https://review.opendev.org/#/c/670510/
15:25:28 <tbarron> #link https://review.opendev.org/#/c/671027/
15:25:42 <tbarron> These are for IPv6 support for CephFS/NFS back end
15:25:59 <tbarron> I think gouthamr is going to review them but I'd also like some other eyes
15:26:18 <tbarron> bswartz: you in particular please.  Not a whole lot of code and it's territory you know well.
15:26:32 <bswartz> ack
15:26:37 <tbarron> bswartz: thanks
15:27:16 <tbarron> OK, I don't have any more on this topic today, anyone else want to bring attention to
15:27:25 <carloss> me
15:27:27 <tbarron> our discuss pending reviews?
15:27:37 <carloss> I have one patch that needs review... It's the fix for the pagination operation
15:27:38 <tbarron> carloss: go ahead please
15:27:47 <tbarron> carloss: ah yes
15:27:48 <carloss> https://review.opendev.org/#/c/650986/
15:27:59 <carloss> :)
15:28:21 <tbarron> carloss: thank you for that one, I'll review it but we need others too!
15:28:36 <carloss> ty
15:29:11 <tbarron> carloss: looks like you had this ready almost a couple weeks ago, sorry to let it slip.
15:29:20 <carloss> no problem :)
15:29:26 <tbarron> Any others?
15:29:30 <carloss> also we've started submitting the patches that implements the share network with multiple subnets spec...
15:29:42 <carloss> it's still a work in progress
15:30:00 <carloss> we are still finishing the unit tests
15:31:08 <carloss> https://review.opendev.org/#/q/topic:bp/share-network-multiple-subnets+(status:open+OR+status:merged)
15:31:22 <tbarron> carloss: but these patches can benefit from review at this point, so it's good to remind.
15:31:44 <carloss> yes, thanks tbarron
15:32:07 <tbarron> Any others?
15:32:22 <carloss> not from our side
15:32:25 <carloss> :)
15:32:34 <tbarron> #topic Bugs
15:32:41 <tbarron> jgrosso: nice to see you!
15:32:53 <jgrosso> tbarron good to be back from vaca
15:33:00 <tbarron> vhariria: and you, thanks for filling in!
15:33:08 <jgrosso> yes vhariria thanks!
15:33:20 <jgrosso> https://etherpad.openstack.org/p/manila-bug-triage-pad
15:33:26 <vhariria> tbarron, jgrosso: np :D
15:33:40 <jgrosso> I wanted to start with an older one
15:33:48 <jgrosso> https://bugs.launchpad.net/manila/+bug/1492211
15:33:50 <openstack> Launchpad bug 1492211 in Manila "Generic driver: error deleting shares if service_instance is not created" [Low,In progress] - Assigned to Lucian Petrut (petrutlucian94)
15:34:06 <jgrosso> should i just ask Lucian to re-submit his fix ?
15:34:21 <jgrosso> not sure why this is abandoned
15:35:02 <jgrosso> looks like a trivial fix
15:36:33 <tbarron> jgrosso: I'm not sure Lucian is actively working on Manila anymore.
15:36:46 <jgrosso> ok will close it then
15:36:55 <tbarron> jgrosso: hold on
15:36:57 <jgrosso> I will verify if he is working
15:37:09 <jgrosso> with manila I thought he was
15:37:21 <tbarron> jgrosso: if he doesn't want to re-take it (do check) you could take it
15:37:35 <jgrosso> ok sounds good
15:37:37 <tbarron> but does anyone understand what Valeriy was saying on this one?
15:38:05 <bswartz> What he was saying where?
15:38:20 <jgrosso> https://review.opendev.org/#/c/224102/
15:38:32 <tbarron> bswartz: he -1-ed this one
15:38:54 <tbarron> bswartz: comment on PS#2
15:39:14 <bswartz> Yeah I think he's concerned about recovering from inconsistent states
15:39:20 <bswartz> Perhaps he observed this happening one time
15:40:25 <gouthamr> but if the flavor is incorrect, we won't have an instance ID
15:40:25 <tbarron> to me it sounds like he was asking for a deeper investigation more than objecting to allowing the deletion
15:41:03 <gouthamr> i think this fix is for a case when nova API fails right away, instead of asynchronously?
15:41:56 <tbarron> jgrosso: ok, move it ahead, we can discuss Valeriy's objection further in review if we need to.
15:42:08 <jgrosso> tbarron great thanks
15:42:22 <jgrosso> https://bugs.launchpad.net/manila/+bug/1836310     I need some help translating :)
15:42:23 <openstack> Launchpad bug 1836310 in Manila "Space savings from efficiency could be lost druing migrations" [Undecided,New]
15:43:32 <gouthamr> 详细信息 (Details), 事件 (Event) :)
15:43:44 <gouthamr> https://translate.google.com/ jgrosso
15:43:47 <jgrosso> haha thanks gouthamr
15:44:10 <tbarron> Is this for a particular back end?  messages are from: mgmt.vopl.move.cutover....
15:44:18 <jgrosso> I am thinking we need more info
15:44:36 <gouthamr> okay, this is intentional
15:44:47 <gouthamr> afaik anyway :)
15:44:51 <tbarron> *what* is intentional?
15:44:51 <jgrosso> :)
15:45:15 <gouthamr> the bug refers to this message from ONTAP: Space savings from efficiency could be lost.
15:45:37 <tbarron> gouthamr: right
15:45:44 <gouthamr> we've a two phased migration in manila; but ONTAP vol moves are nondisruptive
15:45:46 <tbarron> that's why I asked the first question
15:45:52 <tbarron> the bug doesn't say that
15:45:59 <tbarron> train the bug reporter
15:46:04 <jgrosso> :)
15:46:11 <tbarron> ask if this is for a particular back end or
15:46:23 <tbarron> say this looks like a netapp issue, right?
15:46:24 <gouthamr> so during implementation, i had to "wait_for_cutover" explicitly, because we wanted to give the administrator an option to cancel the migration
15:46:31 <tbarron> and tag it
15:46:48 <jgrosso> go it will do
15:47:12 <tbarron> jgrosso: gouthamr: and after that you can go on and explain that you talked to the guy who wrote that
15:47:18 <gouthamr> ofcourse it's going to affect their backend if they wait too long before invoking "migration-complete"; i.e., data is going to be on two aggregates for a longer time
15:47:20 <tbarron> and it's intentional.
15:47:48 <tbarron> and talk to current netapp maintainers to see if they agree etc.
15:47:57 <tbarron> maybe this goes to INVALID then
15:48:00 <gouthamr> i wonder if this is the concern ONTAP has too; though - carloss, you may be able to confirm
15:49:10 <carloss> I can take a look here
15:49:43 <tbarron> well you can't guarantee de-dupe efficiency when you move to a new aggregate, right?
15:50:01 <tbarron> it will initially be worse and eventually be, who knows?
15:51:22 <tbarron> The message is in any case about how ONTAP will work, not something under manila's control, right?
15:51:56 <tbarron> gouthamr: note that the reporter isn't concerned about the wait for cutover, he's concerned about possible loss of
15:52:04 <tbarron> space-efficiency
15:52:11 <gouthamr> i don't recall; sis parameters may be preserved; in any case, we recheck in the driver at the end of the migration and set them appropriately
15:52:15 <carloss> tbarron: I think so
15:53:09 <tbarron> gouthamr: my point isn't about preservation of parameters but rather about how much de-dupe will be possible on a new aggregate which has other data blocks in the background
15:53:11 <gouthamr> yes, if we're able to confirm this, we can tell him it works as intended; and if he wants to avoid the issue, they can watch "migration-get-progress" and issue "migration-complete" immediately
15:53:43 <tbarron> gouthamr: how would that affect the space-efficiency?  I'm not following.
15:53:52 <tbarron> but we can take this offline if we need to
15:54:34 <gouthamr> well, my theory is that there are duplicate data blocks, and ONTAP (at least until 9.as_long_as_i_was_there) doesn't do dedupe across aggregates
15:55:54 <tbarron> gouthamr: i'm just saying the de-dupe will be against a different totality of blocks in the new aggregate no matter what
15:55:56 <gouthamr> there's ofcourse a KB on this :) https://kb.netapp.com/app/answers/answer_view/a_id/1028830/~/troubleshooting-workflow%3A-vol-move-command-failure-
15:56:53 <jgrosso> should I add that to the ticket :)
15:57:11 <gouthamr> jgrosso: nope, i'd let carloss reproduce this and respond :)
15:57:24 <jgrosso> ok shall I assign it to carloss?
15:57:24 <tbarron> that's a KB about failed volume move, not about successful volume move wjth loss of space efficiency :)
15:57:25 <carloss> will do
15:57:48 <dviroel> jgrosso: yes :)
15:58:01 <carloss> jgrosso: yep
15:58:04 <jgrosso> ok that is all the time I have :)
15:58:12 * gouthamr doesn't understand what tbarron is saying, but will defer Qs to #openstack-manila
15:58:19 <tbarron> gouthamr: ack
15:58:33 <tbarron> #topic open-discussion
15:59:02 <tbarron> Thanks everyone!  See you in #openstack-manila
15:59:06 <tbarron> #endmeeting