14:00:14 <rosmaita> #startmeeting cinder
14:00:15 <openstack> Meeting started Wed Apr 22 14:00:14 2020 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <openstack> The meeting name has been set to 'cinder'
14:00:20 <rosmaita> #link https://etherpad.openstack.org/p/cinder-ussuri-meetings
14:00:20 <rosmaita> #topic roll call
14:00:22 <smcginnis> o/
14:00:25 <whoami-rajat> hi
14:00:26 <jungleboyj> o/
14:00:29 <tosky> o/
14:00:33 <walshh_> hi
14:00:36 <LiangFang> o/
14:00:51 <rajinir> hi
14:00:57 <eharney> hi
14:01:06 <Kvisle> hi
14:01:18 <ganso> hello
14:01:20 <sfernand> hi
14:01:33 <e0ne> hi
14:01:35 <enriquetaso> hi
14:01:41 <lseki> hi
14:01:47 <m5z> hi
14:01:53 <rosmaita> wow, big turnout
14:02:13 <rosmaita> #topic announcements
14:02:27 <rosmaita> ok, the big announcement is that RC-1 gets released tomorrow
14:02:33 <rosmaita> and the stable/ussuri branch is cut
14:02:56 <rosmaita> that means all bugfixes must go to master
14:03:05 <jungleboyj> Wow, how did we get here so fast?
14:03:06 <rosmaita> and then be proposed as backports to stable/ussuri
14:03:16 <rosmaita> if they are going to be included in the release
14:03:22 <rosmaita> so, if you have such a bug
14:03:33 <rosmaita> please tag it with 'ussuri-rc-potential'
14:03:50 <rosmaita> and better yet, add it to this etherpad so it gets visibility:
14:04:02 <rosmaita> #link https://etherpad.opendev.org/p/cinder-ussuri-rc-backport-potential
14:04:23 <rosmaita> but yeah, it did seem to sneak up kind of fast
14:04:35 <jungleboyj> :-)
14:05:00 <smcginnis> Reviewers should also keep in mind string freeze.
14:05:13 <rosmaita> smcginnis: thanks for mentioning that
14:05:34 <rosmaita> we aren't supposed to change any translatable strings any more in ussuri
14:05:49 <rosmaita> unless they contain profanity
14:05:54 <rosmaita> but i haven't seen any of those
14:06:01 <rosmaita> (please don't take it as a challenge)
14:06:04 <smcginnis> :)
14:06:39 <rosmaita> i think that's basically it -- please test and look for bugs as time allows
14:07:08 * jungleboyj start getting creative.
14:07:12 <rosmaita> i will watch the gate to see that things in flight have merged and then put up a release patch for RC-1
14:07:37 <rosmaita> last item is the victoria PTG
14:07:42 <rosmaita> (virtual ptg)
14:08:08 <rosmaita> #link https://etherpad.openstack.org/p/cinder-victoria-ptg-planning
14:08:29 <rosmaita> no one put any suggested good/bad times on it
14:08:49 <rosmaita> sometime tomorrow i will put in our requests for time slots
14:09:02 <rosmaita> so if you have a preference to express, please say so on the etherpad
14:09:20 <rosmaita> look at last week's meeting log for details about the available slots, etc
14:09:30 <rosmaita> #topic macrosan driver situation
14:09:45 <rosmaita> #link https://etherpad.opendev.org/p/cinder-ussuri-driverstuff
14:09:59 <rosmaita> ok. so this is a strange situation
14:10:12 <rosmaita> they've got the third party CI running more or less reliably
14:10:29 <rosmaita> but are having trouble with their "mark as supported again" patch
14:10:36 <rosmaita> which is backwards from what we usually see
14:11:06 <rosmaita> anyone here from macrosan?
14:11:43 <whoami-rajat> i will just repeat what he said in the channel earlier today
14:11:58 <rosmaita> ok, thanks
14:12:21 <whoami-rajat> on the revert patch, the CI isn't able to work on the code
14:12:42 <whoami-rajat> but after some refactoring, adding lines
14:12:46 <whoami-rajat> the CI seems to work
14:13:02 <whoami-rajat> see PS2
14:13:03 <whoami-rajat> https://review.opendev.org/#/c/721428/2/cinder/volume/drivers/macrosan/devop_client.py
14:13:05 <jungleboyj> Ugh.
14:13:48 <rosmaita> yeah, that's a 1358 line change just on that file
14:13:55 <jungleboyj> And we asked them to just do the revert.
14:14:03 <whoami-rajat> i'm not really familiar with CI system, but i think the only way to allow CI to function is to let them do the refactor which is just adding lines
14:14:24 <whoami-rajat> or change the CI functionality
14:14:28 <whoami-rajat> i'm not sure
14:14:31 <jungleboyj> Can we have them submit the refactor as a dependent follow-up patch?
14:15:09 <rosmaita> whoami-rajat: this is ruffian-sheep working on this, right?
14:15:24 <whoami-rajat> but i see more changes
14:15:27 <whoami-rajat> rosmaita, yep
14:15:44 <whoami-rajat> some function name changes and parameters as well
14:15:49 <rosmaita> yeah, i see him in the cinder channel all the time
14:16:40 <rosmaita> so whoami-rajat, as you understand it, the situation is that the revert-only patch passes all *our* CI, but not theirs
14:17:13 <whoami-rajat> yep
14:18:10 <rosmaita> i don't know what to do ... they have worked really hard on the CI, which is great, we want to encourage that
14:18:24 <rosmaita> but we don't want to merge something that doesn't pass their own ci
14:18:31 <whoami-rajat> even the logs aren't available to check the failure
14:19:22 <whoami-rajat> yeah, it's important for them that their driver is marked supported for ussuri
14:20:14 <rosmaita> smcginnis: how much would the release team scream if we try to get this as an RC-2 ?
14:20:42 <smcginnis> That should be fine.
14:21:04 <smcginnis> And if small updates are needed to the revert to get it to work now, that is fine.
14:21:11 <rosmaita> ok, thanks
14:21:19 <smcginnis> But it can't be changing ever single line in the file like they've been doing.
14:21:35 <rosmaita> right, i don't know how that is even happening
14:21:51 <rosmaita> whoami-rajat: you are probably closest to their time zone
14:22:00 <smcginnis> At least part I'm assuming is changing LF to CRLF.
14:22:43 <rosmaita> whoami-rajat: can you work with ruffian-sheep a bit more
14:22:51 <whoami-rajat> rosmaita, yeah, i will update him but it would be great if any driver maintainer helps them as i think the main issue is regarding the CI
14:23:07 <rosmaita> good point
14:23:19 <rosmaita> any driver maintainer volunteers?
14:24:14 <rosmaita> c'mon, it's worth karma points
14:24:49 <whoami-rajat> i will try to help him work it out
14:25:21 <rosmaita> ok, and hopefully some driver maintainer will remember that what goes around, comes around, and will also help
14:26:00 <rosmaita> ok, so our official stance for the record is:
14:26:08 <whoami-rajat> :D
14:26:37 <rosmaita> we will give them until early next week to get this sorted out
14:26:43 <jungleboyj> smcginnis:  How is that generic CI setup coming?  ;-)
14:26:48 <rosmaita> i guess must merge by tuesday?
14:27:09 <smcginnis> jungleboyj: Haha, nowhere.
14:27:13 <whoami-rajat> i think that's reasonable time to work it out
14:27:19 <jungleboyj> :-)
14:27:50 <rosmaita> ok, i already see some bugs nominated on the rc-potential etherpad, so we're most likely going to have an RC-2
14:28:03 <rosmaita> which will allow me to procrastinate on the release note
14:28:26 <rosmaita> ok, thanks everyone, i know it's a boring discussion, but very important to the party concerned
14:28:43 <rosmaita> #topic NetApp E-series driver discussion
14:28:44 <whoami-rajat> rosmaita++
14:28:50 <rosmaita> Kvisle: that's you
14:28:59 <rosmaita> i think most of this has been discussed on the agenda?
14:29:08 <Kvisle> Hi
14:29:22 <Kvisle> It seems so, but if I understand it right:
14:29:53 <Kvisle> - Someone needs to step up and take driver maintainer and CI-responsibility for a new driver which CAN be based on the old code.  That someone is very unlikely to be Netapp.
14:30:09 <Kvisle> (needs, as in ... for me to get what I want)
14:30:46 <Kvisle> Have I understood things correct?
14:30:54 <rosmaita> yes
14:31:16 <rosmaita> only thing i would add is "extremely very unlikely"
14:31:37 <rosmaita> but in any case, if you want to use it for lenovo hardware
14:31:50 <rosmaita> would be better testing it on an actual lenovo backend anyway
14:31:57 <jungleboyj> Whoa, did someone say Lenovo?
14:32:05 <Kvisle> Yes
14:32:20 <rosmaita> jungleboyj: line 90 on the agenda
14:32:25 <Kvisle> Lenovo DE-Series are based on Netapp E-series, that's the case in point why I want to revive the driver
14:32:51 <jungleboyj> Whoa.  So you are reviving the E-Series driver for DE-Series?
14:33:01 <rosmaita> Kvisle: your interest is mainly as a driver consumer, is that correct?
14:33:42 <Kvisle> I could probably do this for a week a year at most
14:33:48 <Kvisle> so yes, consumer
14:33:56 <Kvisle> I have a question regarding the deprecation announcement which I found odd -- it was suggested that one should use the LVM driver in stead.  I have no idea how that would solve any problems whatsoever.  Is there anything I don't understand about how the LVM driver works?
14:35:00 <smcginnis> Maybe the suggestion was to use LVM on top of a pool of storage provided by the E-Series?
14:35:18 <lseki> smcginnis: yes
14:35:28 <jungleboyj> Ah, interesting.
14:35:40 <smcginnis> That's certainly an option for any storage that doesn't have its own driver.
14:35:50 <jungleboyj> ++
14:36:30 <rosmaita> jungleboyj: is there any interest at lenovo in doing this?
14:36:35 <lseki> Or ceph. I don't have the telemetry results right now but our customers tends to use eseries w/ lvm or ceph
14:36:37 <jungleboyj> Though, I was frustrated when the e-series driver got deprecated for this reason.
14:36:43 <rosmaita> this == create a DE-series driver
14:37:16 <jungleboyj> :-)  I would love to say yes but I pushed this internally a while back, when they were deprecating, and got no traction.
14:37:43 <rosmaita> Kvisle: you don't happen to represent a transnational telco, do you?
14:38:10 <jungleboyj> He he.
14:38:22 <Kvisle> I represent a service provider in Norway, which is pretty large in Norwegian sense :D
14:39:09 <rosmaita> i guess your best bet is talk to your lenovo rep and see if you can get something rolling
14:39:20 <Kvisle> That seems like the next step for me, yes.
14:39:42 <rosmaita> ok, thanks for bringing this up.  anything else?
14:39:52 <Kvisle> No - that's it. Thank you.
14:39:58 <jungleboyj> Kvisle: Please feel free to reach out to me.  I am at Lenovo and can do my best to get you in touch with the right people.
14:40:11 <Kvisle> jungleboyj: that's great!
14:40:24 <rosmaita> #topic Continued discussion of: Cinder throws error creating incremental backup from parent in another project
14:40:27 <jungleboyj> jbryant1@lenovo.com  Will need to involve your account team as well though.
14:40:37 <rosmaita> ganso: the floor is yours
14:40:52 <ganso> ok so, I included as much info as I could in the agenda etherpad
14:40:58 <ganso> I submitted patches for 2 possible fixes
14:41:04 <ganso> they are very simple
14:41:15 <ganso> but their semantics are ultimately different
14:41:26 <ganso> and I don't see any technical disadvantage to any of them
14:41:34 <ganso> so I think we need to decide which we will go with
14:41:53 <eharney> can we state what the (a) and (c) options are again?
14:42:03 <ganso> yes
14:42:18 <ganso> so (a) will create the backup always in the same project as the volume
14:42:33 <ganso> regardless of who creates it
14:43:32 <ganso> (c) will have separate trees
14:44:07 <ganso> The admin or anybody else that is not running the same project as the volume's project will not be able to create an incremental backup and will create a new full one, which the new incremental backups (for that project) will follow
14:45:04 <enriquetaso> #link https://review.opendev.org/#/c/720741/
14:45:06 <eharney> i think (a) is just the wrong thing to do
14:46:19 <ganso> eharney: semantically feels wrong to me too. I actually was not sure (c) was simple until I implemented it
14:46:36 <ganso> in the analisys etherpad I listed their dependencies. I intend to backport this to queens
14:47:21 <enriquetaso> I can't find the patch for solution (c)
14:47:22 <ganso> I also found 2 more bugs, and both (a) and (c) require different fixes (one of each of those 2 new bugs). So it is double bug-fix, and the fixes are already included in the WIP pathces I submtited
14:47:35 <enriquetaso> would you mind to share it ganso ?
14:47:42 <ganso> WIP Patches: https://review.opendev.org/#/c/720741/ and https://review.opendev.org/#/c/720833
14:47:48 <enriquetaso> thanks
14:48:10 <ganso> I listed the 2 new bugs in the agenda etherpad as well
14:48:39 <ganso> so, do we all incline to (c)? do we vote?
14:48:56 <eharney> option (c) makes sense, if we have to patch up some things along the way, that sounds ok to me
14:48:56 <ganso> btw, the CI is green on both. I got 2 runs on the (c) fix but CI failed in different voting jobs
14:49:08 <ganso> I didn't trigger it again to spare CI resources
14:50:40 <rosmaita> i may be misunderstanding this, but (c) seems to be much different from the current model, where any user can create an entry in the backup chain
14:50:57 <rosmaita> (C) will give each user their own complete backup chain
14:51:05 <eharney> i'm not sure it is
14:51:30 <eharney> is it actually possible for a user to create a backup in the same chain as another user?  i.e. an incremental based on someone else's full?
14:51:35 <eharney> that seems like it should fail now
14:51:44 <ganso> rosmaita: I believe the current model is kinda glitchy, as it causes the bug we are trying to fix, but it would be good for us to discuss what the proper expectations are
14:51:45 <enriquetaso> I agree with Eric on (a), that patch means that the demo user can delete backups created by the admin
14:52:00 <smcginnis> eharney: User yes I think, but not different project. Is that what you mean?
14:52:18 <ganso> eharney: yes, but they land in different projects. The chain (if you consider parent-child backups) is indeed just one currently
14:53:32 <ganso> enriquetaso: but why exactly shouldn't this be allowed, if the volume owner is the demo user?
14:54:05 <eharney> i meant different projects
14:55:15 <ganso> if we want to have a single chain that can involve different projects, I think the fix is neither (a) or (c)
14:55:21 <rosmaita> ok, so volume V in project P.  User A and B in P. A creates a full backup of V, B then creates an incremental -- that sould be ok
14:55:38 <eharney> ganso: i don't think we want that at all
14:55:51 <ganso> rosmaita: yes that is ok. As users A and B are in P
14:55:59 <rosmaita> yes, no cross-project shenanigans
14:56:16 <rosmaita> ganso: ok, so on model (c), that will not be possible
14:56:20 <tosky> also: would it make sense to have an tempest-like test to check those issues are (finally) working as expected, when the final decision is made?
14:56:25 <rosmaita> A must create the incremental
14:56:38 <rosmaita> or, B must do another full before creating an incremental
14:57:00 <smcginnis> tosky: That would be great.
14:57:03 <rosmaita> tosky: +++++++++++++++++
14:57:15 <whoami-rajat> ganso, what will be the state of backup if a user from some other project tries to create a backup? i guess it should be error
14:57:32 <ganso> rosmaita: actually no, they are in the same project. When the admin creates the backup in the use case reported in the bug, the admin is not part of the project
14:57:58 <eharney> ganso: right
14:57:59 <ganso> rosmaita: I can double check that use case, but I am 99% sure it works for (c)
14:58:03 <jungleboyj> It is nice to have a test oriented person here!
14:58:17 <rosmaita> ganso: i will read through the etherpad and leave some questions
14:58:24 <rosmaita> we are just about out of time again
14:58:38 <ganso> whoami-rajat: if the user of that other project can see the volume, then it will create another tree for fix (c)
14:59:16 <rosmaita> so the current summary is eharney thinks that (a) is too restrictive
14:59:33 <eharney> (a) is just the wrong model of ownership
14:59:56 <jungleboyj> 1 minute warning.
14:59:57 <tosky> ganso: even if you don't have time to write a series of tempest tests for this, could you please make sure to document the expected workflow and some negative tests which covers the discovered bugs are well documented in one of the etherpads, so that tests can be created based on them?
14:59:57 <ganso> ok I will abandon (a) and focus on (c)
15:00:25 <ganso> tosky: sure, but I think we are still debating on the expected workflow
15:00:31 <tosky> yep, that's for the after
15:00:34 <tosky> thanks!
15:00:36 <jungleboyj> ++
15:00:50 <rosmaita> ok, have to close now, continue in cinder channel
15:00:53 <rosmaita> #endmeeting