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