14:00:16 <rosmaita> #startmeeting cinder
14:00:16 <opendevmeet> Meeting started Wed Jul  7 14:00:16 2021 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <opendevmeet> The meeting name has been set to 'cinder'
14:00:21 <rosmaita> #topic roll call
14:00:24 <enriquetaso> hello
14:00:26 <eharney> hi
14:00:32 <geguileo> hi! o/
14:00:32 <walshh_> hi
14:00:33 <whoami-rajat> Hi
14:00:34 <fabiooliveira> hi
14:01:02 <rosmaita> #link https://etherpad.opendev.org/p/cinder-xena-meetings
14:01:03 <tosky> hi
14:01:17 <jungleboyj> I am double booked.  Will watch as I can.
14:01:49 <rosmaita> hello everyone
14:01:53 <rosmaita> #topic announcements
14:02:01 <e0ne> hi
14:02:05 <rosmaita> ok, this is week R-13
14:02:20 <rosmaita> xena milestone-2 is next week (!)
14:02:30 <rosmaita> key issue is the new driver merge deadline
14:02:43 <rosmaita> as far as i am aware, we have one new driver:
14:02:54 <rosmaita> NFS driver for Dell EMC PowerStore
14:03:02 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/797608
14:03:25 <rosmaita> it would be good for any NFS-based driver maintainers to take a look, you may have helpful comments
14:03:47 <rosmaita> would be good to get some reviews today and tomorrow to allow reasonable time for revisions
14:03:56 <rosmaita> good news is that it's not a very large patch
14:04:20 <whoami-rajat> looks like it's just using generic nfs driver for all functionalities
14:04:50 <tosky> uhm, does it need a separate driver then?
14:04:56 <rosmaita> yes, so it will bask in the goodness of our current nfs driver
14:05:00 <eharney> hmm
14:05:51 <enriquetaso> lol
14:05:52 <whoami-rajat> tosky, not really but its the same as nfs driver which seems strange to me...
14:06:03 <eharney> is the intent to CI and test it on their hardware?  hard to understand why this exists...
14:06:39 <rosmaita> the bp is a bit sparse: https://blueprints.launchpad.net/cinder/+spec/powerstore-nfs-driver
14:07:22 <rosmaita> but it does have CI: http://publiclogs.emc.com/08/797608/3/check/DellEMC_PowerStore_NFS/f03b290/DellEMC_PowerStore_NFS/13
14:08:08 <rosmaita> in any case, i don't think we have a policy that a driver must be of a certain level of complexity > generic driver in order to be accepted?
14:08:33 <hemna> mep
14:09:40 <eharney> i'll have to look deeper but i think the check for reporting multiattach support is wrong
14:10:04 <whoami-rajat> i also felt the same, if not qcow2 then multiattach = true
14:10:29 <rosmaita> ok, eharney and whoami-rajat please look more closely and leave comments on the review
14:10:50 <tosky> but if it's really the same (I haven't seen the code), they could just use the generic one on their CI
14:10:52 * tosky shuts up
14:11:41 <rosmaita> well, they will find bugs in the generic one, i guess in either case
14:12:45 <rosmaita> but this is a serious question, is the closeness to the generic driver a reason to reject this one?
14:13:24 <eharney> i think we should at least ask why they want to create one  (i.e. is it just to add this flag to support multiattach?)
14:14:40 <rosmaita> i dont' think Ivan Pchelintsev is here
14:14:52 <rosmaita> walshh_: do you know?
14:15:06 <walshh_> No, I don't have details
14:15:20 <walshh_> But I can reach out to him after the meeting
14:15:45 <geguileo> eharney: it is definitely wrong  lol
14:16:00 <geguileo> snapshot of attached volume won't work
14:16:26 <eharney> also that, which is why it's turned off in the generic nfs driver
14:16:42 <geguileo> rosmaita: I wouldn't reject a driver just because it's basically a wrapper for the generic driver
14:16:57 <rosmaita> geguileo: noted
14:17:14 <rosmaita> sounds like we already have comments for the review
14:17:15 <geguileo> rosmaita: it may be their initial implementation and they may want to add funcionality later on (eg: replication)
14:17:23 <rosmaita> that's what i was thinking
14:17:32 <geguileo> or maybe it's for branding reasons
14:17:34 <eharney> i don't necessarily think we should reject it, but we should probably see if there are enhancements they want that could just go in the base driver
14:17:36 <geguileo> I'm ok either way
14:17:45 <geguileo> eharney: +1
14:18:17 <rosmaita> #action rosmaita reach out to dell (Ivan Pchelintsev) about strategy for powerstore nfs driver
14:18:24 <rosmaita> ok, moving on
14:18:38 <rosmaita> #topic dropping lower-constraints jobs in master in all repos
14:18:57 <rosmaita> the TC has said it's up to individual projects whether to maintain these jobs or not
14:19:20 <rosmaita> there isn't anyone who actually uses the lower-constraints.txt as far as we can tell
14:19:42 <rosmaita> and, there isn't an ongoing program to maintain the l-c with the dependencies of our dependencies
14:20:05 <rosmaita> and, if we update requirements at every M-3 as we have been doing since wallaby
14:20:21 <rosmaita> we won't have to worry about stale versions in the l-c
14:20:54 <rosmaita> and, the l-c are only tested against our unit tests, so it's not clear that everything in there actually gets a good enough workout to detect problems
14:21:35 <rosmaita> so, i think we should drop the jobs and files (since the file is even more useless if we're not testing against it)
14:21:59 <eharney> i don't think we get any real benefit by trying to keep it, so i agree
14:21:59 <whoami-rajat> IIRC l-c jobs also break gate everytime a migration is done, eg: bionic->focal
14:22:11 <rosmaita> there are some patches up for this for some of our repos, i will un-block those and put up any required other patches
14:22:44 <rosmaita> i will make sure they have the topic "drop-l-c"
14:22:58 <rosmaita> so if anyone has second thoughts, look for a patch and leave a comment
14:23:21 <rosmaita> any comments?
14:23:33 <rosmaita> i guess i just said leave it on the reviews
14:23:37 <rosmaita> ok, moving on
14:23:48 <rosmaita> #topic Please land gate fix for wallaby
14:23:55 <rosmaita> this is an alert for the stable cores
14:24:03 <rosmaita> https://review.opendev.org/c/openstack/cinder/+/798671/
14:24:43 <eharney> yep, nothing else to add there really
14:24:53 <rosmaita> actually, looks like https://review.opendev.org/c/openstack/cinder/+/798696/ is the one that needs review
14:25:20 <enriquetaso> ++
14:25:40 <rosmaita> this is slightly off topic, but whoami-rajat has been doing a good job organizing the stable releases and reviewing backports
14:26:06 <rosmaita> i think i will propose him as a stable-core
14:26:14 <rosmaita> on the ML, so watch for that
14:26:21 <hemna> :)
14:26:26 <rosmaita> ok, next topic
14:26:32 <whoami-rajat> :)
14:26:39 <rosmaita> #topic Request for review (blocking glance_store change)
14:26:58 <rosmaita> we discussed this last week, and whoami-rajat has made requested revisions
14:27:14 <rosmaita> so it is time for people who made those requests to re-review
14:27:22 <rosmaita> i believe that i am one of those people :)
14:27:49 <rosmaita> we have a light agenda today, so i will use my free time after the meeting
14:28:04 <whoami-rajat> I also have some more changes in glance_store dependent on the base attachment code, just wanted to get things in on time
14:28:29 <rosmaita> good point, as a nonclient library, glance_store gets released early (like os-brick)
14:28:49 <rosmaita> so, people with interest in cinderclient, please review!
14:28:49 <whoami-rajat> yep
14:29:04 <rosmaita> #topic rbd: Add snapshot mirroring support
14:29:18 <rosmaita> there's a bp filed for an improvement to the rbd driver
14:29:26 <rosmaita> #link https://blueprints.launchpad.net/cinder/+spec/rbd-snapshot-mirroring
14:29:48 <rosmaita> apparently, there are two ways of doing replication for ceph
14:29:57 <rosmaita> the old-fashioned way, journaling
14:30:09 <rosmaita> and the recent improved way, snapshot mirroring
14:30:26 <rosmaita> this proposal is to let the operator configure which one the rbd driver will use
14:30:55 <rosmaita> my question here is: do we really want this to be a config option?
14:31:09 <rosmaita> or should we just use the better way if it's available?
14:31:28 <jbernard> i think this should be transparent, and not put onto the user
14:31:30 <rosmaita> i seem to remember that we had this discussion about a different feature, but i couldn't find the patch
14:31:34 <eharney> config option seems to make sense, but we need to ensure the behavior doesn't change between the two and that someone can actually switch back and forth
14:31:43 <rosmaita> so maybe it was a different driver
14:32:01 <hemna> eharney +1
14:32:34 <geguileo> jbernard: is there a difference in how the RBD pool must be configured?
14:33:15 <geguileo> if the RBD driver can tell which way the pool is configured, then it could do it automatically, right?
14:33:34 <rosmaita> from a quick look at the patch, it looks like you just need fast-diff available
14:33:38 <eharney> the first couple of paragraphs on https://docs.ceph.com/en/latest/rbd/rbd-mirroring/  seem to indicate that the two modes don't have the same semantics
14:34:22 <jbernard> geguileo: no, and anyway the pool configuration is expected to be performed by the installer, the driver asserts that the cluster is configured properly
14:35:00 <geguileo> jbernard: if the driver cannot tell which way the pool is configured then it must be a configuration option, right?
14:35:24 <jbernard> geguileo: we can query from the driver, i dont see that as a problem
14:35:35 <geguileo> jbernard: that's precisely what I asked
14:35:52 <jbernard> geguileo: ok, i see
14:38:31 <eharney> so, it's not clear to me that the snapshot-based replication is always the better way, from the doc
14:39:06 <rosmaita> well, if there would be actual reasons for preferring journaling, then i think we need to keep it as an option
14:39:27 <eharney> it reads to me like the snapshot-based mode has a longer RPO but hard to tell
14:40:32 <geguileo> I read that too
14:40:55 <geguileo> and if the deployer didn't configure a snapshot schedule replication wouldn't even happen
14:41:23 <rosmaita> so do we even want to allow this feature?
14:41:35 <geguileo> I think it's useful
14:41:58 <eharney> i think it makes sense to allow the admin to choose based on journal (slower overall but better RPO) and snapshot-based (probably better I/O perf, but worse RPO)
14:42:49 <rosmaita> ok, we will have to make sure the release note is clear ... and i guess the defaults should be to journaling?
14:43:34 <eharney> yes
14:45:36 <rosmaita> ok, and i guess the same deal for the rbd backup driver?
14:46:26 <eharney> i don't think this would apply there?
14:47:41 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/784956
14:49:20 <geguileo> I don't think we want that there (could be wrong though)
14:49:27 <geguileo> for backups we want them to be synchronous
14:49:52 <eharney> do we support mirroring backups at all currently?
14:51:19 <geguileo> no
14:51:38 <geguileo> people can do pool based mirroring, but the backup driver would not be aware of it
14:52:53 <enriquetaso> just to add something backup_ceph_image_journals config applies journaling and EXCLUSIVE_LOCK feature
14:56:16 <rosmaita> ok, so it sounds like we think: (1) rbd driver option to select journaling vs snapshot mirroring, (2) for rbd backup driver, journaling only when it's available, snapshot mirroring does not seem an appropriate technology for backups
14:57:11 <eharney> sounds good
14:57:26 <rosmaita> ok, the proposer should be fine with (1) because that's what's implemented in the patch
14:57:39 <rosmaita> the proposer can come to the next meeting and tell us why we are wrong about (2)
14:57:53 <rosmaita> deadline for this is M-3
14:58:04 <rosmaita> #topic open discussion
14:58:11 <eharney> i added two links to the etherpad
14:58:16 <rosmaita> all that free time i was talking about evaporated
14:58:19 <eharney> https://review.opendev.org/q/topic:%22bug%252F1926630%22+(status:open%20OR%20status:merged)
14:58:24 <eharney> https://review.opendev.org/c/openstack/cinder/+/789602
14:58:29 <eharney> https://review.opendev.org/c/openstack/cinder/+/789603/10
14:58:31 <eharney> API fixes for encryption
14:58:39 <eharney> this stuff has been waiting for more reviews
14:58:42 <rosmaita> this is about creating the types?
14:58:49 <eharney> yes
14:58:52 <rosmaita> i mean, the encryption type for a volume type
14:58:55 <rosmaita> or whatever we call it
14:59:06 <eharney> and gracefully handling previously created types that are invalid
14:59:31 <rosmaita> ok, i will put those on my list (i think i already had a look)
14:59:43 <eharney> you +2'd one of them some time ago
14:59:55 <rosmaita> even better
14:59:57 <eharney> these are pretty straightforward, would be nice to close them out
15:00:04 <rosmaita> ok, other people, please look them over!
15:00:26 <rosmaita> we are out of time
15:00:29 <rosmaita> thanks everyone!
15:00:29 <geguileo> eharney: that will not fail on the API, right?
15:00:36 <whoami-rajat> thanks!
15:00:36 <eharney> geguileo: define "fail"
15:00:44 <rosmaita> QA team is OK with the change
15:00:54 <rosmaita> decided it does not impact the API
15:01:06 <geguileo> eharney: well, it aborts the creation, so I assume it fails and goes to error state
15:01:34 <rosmaita> we need to move this over to #openstack-cinder
15:01:37 <rosmaita> #endmeeting