14:00:14 <rosmaita> #startmeeting cinder
14:00:15 <openstack> Meeting started Wed Apr 29 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:18 <openstack> The meeting name has been set to 'cinder'
14:00:20 <smcginnis> o/
14:00:27 <rosmaita> #link https://etherpad.openstack.org/p/cinder-ussuri-meetings
14:00:27 <rosmaita> #topic roll call
14:00:28 <whoami-rajat> Hi
14:00:35 <bojleros> Hi
14:00:43 <lseki> o/
14:00:44 <walshh_> Hi
14:01:07 <sfernand> Hi
14:01:13 <e0ne> hi
14:01:14 <enriquetaso> hi
14:01:17 <LiangFang> hi
14:01:34 <jungleboyj> o/
14:01:36 <rosmaita> looks like a good turnout
14:01:41 <rosmaita> #topic updates
14:01:52 <jungleboyj> I read that as 'it looks like a burnout'
14:01:59 <jungleboyj> :-)
14:02:04 <m5z> hi =]
14:02:13 <rosmaita> jungleboyj: you are about a week off from 4/20
14:02:23 <jungleboyj> *Laughing*
14:02:34 <rosmaita> let's start with a quote from smcginnis:
14:02:35 <rosmaita> "Keep in mind that all work should now be transitioning to stabilization and getting things ready for the final RC deadline on May 7"
14:02:42 <jungleboyj> I was thinking workwise, but I will let you go that direction.
14:02:45 <rosmaita> so that's the focus right now
14:02:53 <smcginnis> ;)
14:02:58 <rosmaita> upcoming deadlines:
14:03:05 <rosmaita> May 7 (Thursday next week): Final RC deadline
14:03:14 <rosmaita> we will go over the RC stuff a bit later
14:03:22 <rosmaita> May 13: Final Ussuri release
14:03:43 <e0ne> rosmaita: what about cinderlib? it doesn't have stable/ussuri branch yet
14:03:49 <rosmaita> we can celebrate by skipping the weekly meeting on may 13
14:03:59 <rosmaita> e0ne: cinderlib is cycle-trailing
14:04:11 <rosmaita> so won't get stable branch until a few weeks from now
14:04:14 <e0ne> rosmaita: got it, thanks
14:04:40 <rosmaita> there will be a "community meeting" at our cinder meeting time on may 13
14:04:45 <rosmaita> mostly project updates
14:04:54 <rosmaita> so you can attend that to get your weekly meeting fix
14:05:06 <rosmaita> June 1-5: Victoria (Virtual) PTG
14:05:17 <rosmaita> #link https://etherpad.opendev.org/p/cinder-victoria-ptg-planning
14:05:34 <rosmaita> i've got the proposed cinder meeting times on the etherpad ^^
14:05:55 <rosmaita> there's also a link there the the main ethercalc where all the teams are scheduling stuff
14:06:08 <rosmaita> we are light on topics, so please add some
14:06:20 <rosmaita> or else we can have a tempest scenario test hackathon
14:06:35 <rosmaita> final deadline i want to mention
14:06:42 <rosmaita> June 18: Victoria milestone 1
14:06:50 <rosmaita> which seems amazingly close
14:06:59 <rosmaita> i see LiangFang has an item on the topics later
14:07:14 <rosmaita> but it would be good to get the volume local cache stuff done before then
14:07:18 <rosmaita> at least the os-brick changes
14:07:36 <rosmaita> i'm mentioning it now because M-1 is only 2 weeks after the ptg
14:07:48 <enriquetaso> probably the NFS encryption patch too...
14:07:56 <rosmaita> that's right
14:08:03 <rosmaita> what enriquetaso said
14:08:17 <rosmaita> but this week is rc reviews and bugfixes
14:08:32 <rosmaita> ok, that's all the announcements
14:08:39 <rosmaita> #topic victoria community goals
14:09:14 <rosmaita> ok, usually we discuss at ptg, but the actual model is that they should be selected by now and we discuss how to implement at ptg
14:09:37 <rosmaita> so, i want to do a quick runthrough so that we don't get surprised by a goal that we absolutely hate
14:09:50 <rosmaita> https://etherpad.opendev.org/p/YVR-v-series-goals
14:10:04 <rosmaita> good thing is, tosky's goal has already been selected and approved
14:10:12 <tosky> and we are in a good shape
14:10:15 <rosmaita> and he's done most of the work on it already for cinder!
14:10:20 <rosmaita> tosky: ++
14:10:29 <enriquetaso> tosky ++
14:10:57 <rosmaita> ok, i will not be coy
14:11:05 <rosmaita> i am worried about goal #6
14:11:08 <rosmaita> add container images
14:11:09 <tosky> if I'm not mistaken, after merging https://review.opendev.org/#/c/709780/, there is just one legacy job left
14:11:26 * tosky shuts up for now
14:11:38 <rosmaita> my feeling is that container images is a distro thing
14:11:56 <rosmaita> and i can see getting bindep worked out correctly for all distros being a big time-waster
14:12:22 <rosmaita> because the goal is portrayed as "just add a dockerfile to your repo"
14:12:35 <rosmaita> but, that's just me
14:13:05 <rosmaita> but unless we have someone here who is really interested in working on this, i don't know that it's a good allocation of cinder resources
14:13:10 <rosmaita> i would rather harden our testing
14:13:20 <rosmaita> rather than have buggy code in a nice container
14:13:34 <e0ne> I still don't understand why we need it
14:13:38 <smcginnis> Would be good to comment on that proposed goal.
14:13:38 <tosky> on the other hand, if just one or two goals at most are going to be select, I would bet on 4 and 7
14:13:50 <e0ne> thare are loci and kolla around
14:13:55 <rosmaita> 4 and 7 would be great
14:14:02 <rosmaita> e0ne: exactly
14:14:18 <rosmaita> my fear of #6 is primarily the goal champions
14:14:29 <rosmaita> they are very enthusiastic
14:14:43 <e0ne> https://github.com/openstack/cinder/tree/master/contrib/block-box - we've got something:)
14:14:45 <jungleboyj> :-)  So, there has been a lot of back and forth in the TC on that goal.
14:14:57 <jungleboyj> If people have an opinion it would be good to comment.
14:15:23 <rosmaita> i'll leave a comment right after the meeting
14:15:40 <bojleros> i have just reconnected since my uplink was down
14:15:53 <rosmaita> just wanted to get a sense of the cinder community, because when i leave a comment, it could be taken as a comment on behalf of the team
14:16:22 <bojleros> rosmaita please let me know when we can discus my proposal
14:16:39 <rosmaita> bojleros: 2 topics away
14:16:49 <bojleros> ok
14:17:01 <smcginnis> bojleros: https://etherpad.opendev.org/p/cinder-ussuri-meetings
14:17:09 <rosmaita> ok, like tosky pointed out, the other goals look fine for cinder and not too resource intensive
14:17:50 <rosmaita> and as jungleboyj pointed out, if you have an opinion on any of the goals, please leave a comment on that etherpad
14:18:02 <rosmaita> #topic review of rc-critical patches
14:18:15 <rosmaita> #link https://etherpad.opendev.org/p/cinder-ussuri-rc-backport-potential
14:18:18 <jungleboyj> Wow, dynamic config changes on there.  How long have we been talking about that?
14:19:19 <rosmaita> ok, i need some help with some of these
14:19:49 <e0ne> btw, it's not a list of approved goals
14:20:06 <rosmaita> e0ne: that's right, these are proposed goals
14:20:18 <rosmaita> but it's not clear what the timeline for selection is
14:20:21 <rosmaita> and the tc selects
14:20:32 <whoami-rajat> i would need to do some testing on the rbd patch, my understanding and testing was a little off on that
14:20:42 <rosmaita> so if there are any you hate, it is really important to make that known pre-selection
14:20:58 <rosmaita> whoami-rajat: please put a note on the etherpad
14:21:10 <whoami-rajat> rosmaita, ok
14:21:12 <rosmaita> now about these patches
14:21:16 <e0ne> #link https://governance.openstack.org/tc/goals/selected/victoria/index.html
14:21:34 <rosmaita> we can still do backports and do a point release
14:21:51 <rosmaita> what we want to get in now are critical fixes
14:21:51 * jungleboyj should know when the selection is.  It is soon.
14:22:43 <rosmaita> so i wanted to look at the "controversial" list
14:22:51 <rosmaita> https://review.opendev.org/#/c/720722/
14:23:18 <rosmaita> this is a change to the virtuozzo driver to support a feature that is being delivered in ussuri
14:23:56 <rosmaita> virtuozzo is 'unsupported' , but i think we still want it to be a working driver if we're keeping it in repo
14:24:13 <rosmaita> so i thnk this bugfix really needs to get into RC-2
14:24:40 <rosmaita> any thoughts?
14:25:19 <whoami-rajat> since we've added the feature in this realease, it would be better to have it in all drivers but that's just my opinion
14:26:03 <smcginnis> I don't think we should be adding new features to unsupported drivers.
14:26:09 <jungleboyj> Well, if we aren't removing it then we should make sure it work.
14:26:18 <e0ne> smcginnis: good point
14:26:24 <rosmaita> well, it's not a driver feature, really
14:26:32 <rosmaita> it's a cinder feature that entails a driver change
14:26:33 <smcginnis> How are we going to make sure the new features work if the driver isn't being tested?
14:26:41 <rosmaita> unit tests
14:26:47 <rosmaita> best we can do
14:26:52 <jungleboyj> Hmmm.
14:27:04 <smcginnis> Then I change my stance on the decision to keep these drivers in tree. They should be removed.
14:27:22 <rosmaita> good ptg topic
14:27:41 <rosmaita> but i think at this point in the cycle, we are stuck with it
14:28:00 <smcginnis> Unit tests are not failing due to that driver right now. Therefore according to what we had agreed to do with unsupported drivers, it really should not be touched.
14:28:29 <jungleboyj> rosmaita:  Yeah ... should discuss at the PTG.
14:29:04 <rosmaita> well, we could deny the patch and list it as a "known issue"
14:29:21 <rosmaita> but we will probably be facing this kind of situation again if we carry these unsupported drivers
14:29:46 <rosmaita> we have whoami-rajat's patch if someone really wants to use the driver
14:30:37 <rosmaita> but this is a good example of what we are up against, so should help us focus the discussion at the PTG
14:31:13 <rosmaita> i have checked all the other drivers we have in-tree, this is the only one affected by the glance multi-store support
14:31:27 <rosmaita> but that was mostly a matter of luck
14:31:52 <whoami-rajat> do we have other unsupported drivers in which this change exists?
14:32:07 <jungleboyj> Good question.
14:32:11 <rosmaita> not sure, would have to look
14:32:23 <rosmaita> actually, probably we do
14:32:34 <rosmaita> any of the ones being marked unsupported in ussuri are candidates
14:32:53 <rosmaita> the other removed-then-restored drivers used an inherited method
14:33:18 <rosmaita> so when that was fixed in the base class, everything was fine, no changes needed to the driver code
14:33:56 <rosmaita> i don't want to drag this out, should we vote?
14:34:10 <whoami-rajat> also one more thing i want to point out
14:34:39 <whoami-rajat> this is the last change to happen in drivers regarding image as we've a wrapper now which will handle these changes from future
14:34:49 <whoami-rajat> s/image/upload image
14:35:01 <jungleboyj> I personally think if this is needed for the driver to work and it is an outlier from the other restored drivers we should fix it and then discuss how we handle this in the future at the PTG.
14:35:13 <rosmaita> jungleboyj: ++
14:35:28 <e0ne> jungleboyj:+1
14:35:31 * jungleboyj ducks to avoid the tomatoes smcginnis  is throwing
14:35:40 <smcginnis> :)
14:36:12 <rosmaita> smcginnis: are you ok with that? you can -1 the patch
14:37:16 <rosmaita> i just would like to know in advance if you are going to -2 the backport
14:38:29 <rosmaita> i think smcginnis is in a simultaneous meeting, we can return to this before end of meeting
14:38:46 <rosmaita> ok, the other controversial patch is having trouble with it's own CI
14:39:00 <rosmaita> so i'm inclined to hold off on it
14:39:03 <jungleboyj> That is always a good sign.
14:39:05 <smcginnis> rosmaita: Yeah. I didn't downvote the patch, I just didn't want to approve it.
14:39:22 <rosmaita> smcginnis: understood, i can respect that
14:39:39 <rosmaita> and you have definitely identified an issue we need to have a policy on
14:39:56 <rosmaita> ok, so my final point here
14:40:26 <rosmaita> you can see that i am not convinced any of the proposed-as-release-critical patches really need to get in
14:40:49 <rosmaita> so if you have a counterargument, please either tell us now or on the etherpad *today*
14:41:34 * rosmaita is waiting a minute to hear any counterarguments
14:42:10 <rosmaita> oh yeah, one more point
14:42:19 <rosmaita> about the approved for backport patches
14:42:38 <rosmaita> if you are the owner of one of these in master, you are responsible for proposing the backport to stable/ussuri
14:42:56 <rosmaita> just so we are clear about that
14:43:24 <rosmaita> they need to merge to master first, though
14:43:33 <rosmaita> just so we are also clear about that
14:44:11 <rosmaita> ok, so reviewers, please keep an eye on the approved for backport patches and i will propose RC-2 as soon as they land
14:44:21 <rosmaita> any questions?
14:44:53 <rosmaita> #topic improvement proposal for LVM volume driver
14:44:57 <rosmaita> bojleros: that's you
14:45:00 <bojleros> yep
14:45:06 <whoami-rajat> rosmaita, ++
14:45:09 <bojleros> what do you think about this proposal ?
14:45:35 <bojleros> well , i'd like to keep it as small as possible in term of a change footprint , reuse as much as i can
14:45:56 <bojleros> without breaking functionalitiest that already exists and are in production use
14:46:28 <bojleros> so therefore we are not talking about a new driver just new target_helper for lvm driver
14:46:44 <rosmaita> this looks very interesting
14:46:58 <rosmaita> can we discuss in more detail at the PTG?
14:47:09 <bojleros> it has some limitations pointed in README.md but that's how the local storage works
14:47:13 <bojleros> sure
14:47:17 <rosmaita> or is that too far in the future?
14:47:34 <bojleros> well , my primary point of interest is stein
14:47:37 <smcginnis> This seems similar to the block device driver that was removed because it couldn't support all base functionality.
14:47:40 <smcginnis> https://github.com/openstack/cinder/blob/icehouse-eol/cinder/volume/drivers/block_device.py
14:48:11 <bojleros> since this is the relase we are running right now , but idk if you will allow backporting so many releases behind
14:48:45 <jungleboyj> We don't allow backporting new drivers/features.
14:48:45 <e0ne> smcginnis: that was my question
14:49:00 <bojleros> smcginnis what are the exact functionalites you are talinkg about ?
14:49:07 <smcginnis> Unfortunately no, new features would not be eligible for backport. So this would be a feature of victoria, if we do it.
14:49:23 <rosmaita> yeah, you may have to carry this as a local patch for stein, but you can look forward to having it there when you upgrade to victoria
14:49:26 <LiangFang> bojleros: seems volume local cache can fit your requirement
14:49:34 <smcginnis> bojleros: Looks like you may have it covered in the "Tested functionalities"
14:49:35 <bojleros> i am fine with that , we will have victoria one day, till then we will patch
14:50:06 <bojleros> i know the list but i want to know it exactly
14:50:36 <smcginnis> Anyone remember the benchmarking the Griffith did for the LVM driver? I thought with some configuration tweaks he was able to show the existing LVM driver was at or close the performance level of a local block device.
14:50:39 <bojleros> local storage will have some limitations that will not work , other can only be a nifty tricks as I described in my paper
14:51:08 <bojleros> it is not the lvm that gives a performance drop , it is iscsi
14:51:17 <e0ne> smcginnis: AFAR, lv,+LIO was pretty close to block device briver
14:51:19 <smcginnis> bojleros: Here are the minimum required features: https://docs.openstack.org/cinder/latest/contributor/drivers.html#minimum-features
14:51:39 <smcginnis> So it would need to support those operations at a minimum.
14:51:49 <e0ne> bojleros: did you test with LIO target on the same node?
14:51:55 <bojleros> create/delete/attach/detach works
14:52:02 <bojleros> create volume from snapshot works
14:52:10 <bojleros> ach pardon
14:52:19 <bojleros> i ment image to volume and volume to image
14:52:29 <bojleros> extend works
14:53:02 <bojleros> it is greately inherited from lvm functionality itself , not only by target helper
14:53:02 <e0ne> bojleros: what about snapshots?
14:53:12 <bojleros> i havent tested it yet
14:53:16 <bojleros> since i do not use it
14:53:34 <e0ne> it's a hard requirement to support snapshots
14:53:35 <smcginnis> This concerns me a lot "you must ensure that vm is pinned or running in a single-host-AZ (you may also want to limit Cinder to a particular AZ) or without it your vm can be started on a host that does not contain your volumes"
14:53:36 <bojleros> changing volume type works with some remarks
14:54:14 <rosmaita> ok, let's continue this discussion after reading through the paper
14:54:16 <bojleros> yep but that's the fundamental question about if cinder is going to deliver a direct attached storage or not
14:54:19 <e0ne> bojleros: also, your. driver must support remote volumes attachements
14:54:28 <smcginnis> bojleros: Did you see e0ne's earlier question? Did you test LVM with LIO?
14:54:35 <bojleros> yep , tested
14:55:04 <e0ne> I was a maintainer of BlockDeviceDriver and I was happy to remove it:)
14:55:05 <bojleros> in term of performance we lose ~60% of rd iops
14:55:23 <bojleros> so you do not like this idea dont you ?? :)
14:55:40 <rosmaita> bojleros: please add this to the PTG list ... that doesn't mean we can't discuss prior, though
14:55:43 <smcginnis> I don't think it can work the way a Cinder driver is expected to behave.
14:55:53 <smcginnis> Seems like maybe something that should be done in Nova and without Cinder.
14:56:09 <bojleros> that's what we do right now as a workaround
14:56:17 <e0ne> smcginnis: +1
14:56:28 <bojleros> i have highligted some cons already
14:56:50 <rosmaita> sounds like e0ne and smcginnis have some things you will need to look into
14:57:00 <bojleros> and this target_helper is a kind of option , you give user a freedom of choice
14:57:29 <smcginnis> Almost out of time. This does seem like it needs a larger PTG discussion.
14:58:07 <rosmaita> LiangFang: looks like we will not have time for discussion, but we do have the links on the agenda
14:58:11 <bojleros> ok , gonna add it
14:58:28 <LiangFang> rosmaita: I'm OK:)
14:58:58 <rosmaita> ok, well you and enriquetaso have the priority items after RC-time is over in a week
14:59:08 <rosmaita> #topic open discussion
14:59:19 <rosmaita> for 45 seconds ... anyone?
14:59:30 <bojleros> thank you for discussing my proposal ;)
14:59:30 <e0ne> :)
14:59:49 <rosmaita> bojleros: thanks for bringing it to us
14:59:55 <LiangFang> bojleros: maybe you can take a look of volume local cache
15:00:07 <rosmaita> #endmeeting