14:00:07 #startmeeting cinder 14:00:07 Meeting started Wed Jun 15 14:00:07 2022 UTC and is due to finish in 60 minutes. The chair is whoami-rajat. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:07 The meeting name has been set to 'cinder' 14:00:17 #topic roll call 14:00:29 hi o/ 14:00:45 o; 14:00:52 o/ 14:01:03 o/ 14:01:03 o/ 14:01:07 hi 14:01:17 o/ 14:01:18 hi 14:01:35 o/ 14:02:11 o/ 14:02:22 #link https://etherpad.openstack.org/p/cinder-zed-meetings 14:02:36 o/ 14:02:48 hi 14:04:17 looks like a good turnout 14:04:23 let's get started 14:04:31 hi 14:04:36 #topic announcements 14:04:52 SRBAC Berlin discussion 14:05:24 so I'm not sure about the date or times of the sessions but i believe one related to service role was conducted on thursday and related to operator feedback was conducted on friday 14:05:39 hey 14:05:49 anyway, we had a ops meetup in berlin which had a topic to discuss about our issues with the current SRBAC strategy 14:06:38 majorly being the scopes since it has changed quite a few times in design and still the current one is not satisfactory 14:07:01 gmann, has described this in a ML thread 14:07:03 #link http://lists.openstack.org/pipermail/openstack-discuss/2022-June/028878.html 14:07:28 the feedback etherpad for SRBAC in ops meetup is here 14:07:29 #link https://etherpad.opendev.org/p/rbac-operator-feedback 14:07:47 honesty, i wasn't able to derive any conclusion or major points to highlight here 14:08:04 so feel free to take a look at the etherpad discussion section 14:08:21 another session related to service role was held on thursday last week 14:08:31 #link https://etherpad.opendev.org/p/deprivilization-of-service-accounts 14:09:05 again, the etherpad says very less and until a recording is available, I couldn't derive much concrete items from the etherpad 14:09:32 me neither 14:09:57 i was hoping rosmaita would but hard luck :/ 14:10:06 let's see if TC posts an update about it 14:10:20 the policy pop-up team did not meet yesterday, so hoping to get some info on thursday at the TC meeting 14:10:46 yeah, I am consolidating about all the feedback from various place and ops meetup/forums etc 14:11:09 gmann, great thanks 14:11:12 and also will send the meeting schedule soon to decide the next step 14:11:54 sounds like a plan so let's wait for further discussions 14:12:01 thanks gmann for an update 14:12:02 gmann: my impression is that ironic absolutely wants scope, but maybe it can be optional for other projects? 14:12:44 (if it's too complicated to answer, we can discuss at the tc meeting) 14:12:54 rosmaita: may be but ironic can be exception but any other inter-dependent projects should not have scope as individual. but let's discuss in policy popup meeting 14:12:55 yeah 14:13:37 thanks again, let's move on to our next announcement 14:13:44 next, cinderlib for yoga must be released by 23 June 14:13:51 rosmaita, that's you 14:14:19 just wanted to remind everyone, i will talk about some issues later 14:14:48 ack, I received one reminder from herve about the cinderlib release 14:14:51 they've proposed a patch 14:14:54 #link https://review.opendev.org/c/openstack/releases/+/845701 14:15:15 yeah, please put a -1 on that 14:15:28 and I've told him that after discussing all the issues we've in cinderlib, me or rosmaita will add a comment to the patch 14:15:51 also, there's https://review.opendev.org/c/openstack/releases/+/842105 14:16:21 ah, this one is old ... 14:16:35 I will ask him to abandon the new one in favor of this one then 14:17:01 sounds good, just -1 both so that there's no confusion 14:17:20 yep, will do, thanks 14:17:35 next annoucement, spec freeze is 24 June 14:18:43 so i see the quota spec by geguileo still needs an update 14:18:55 has anyone looked at the task status field proposal? 14:18:58 also this one needs to be addressed: https://review.opendev.org/c/openstack/cinder-specs/+/818551 14:19:06 that's the one 14:19:08 that's the one 14:19:13 jinx!!! 14:19:27 also the SRBAC one needs to be updated after we've all the discussion points from ops meetup (maybe will get a Spec feeze exception) 14:19:28 Walt has an issue with it 14:19:48 hemna are you here? 14:20:17 whoami-rajat: yeah, sorry I was busy with the nvmeof and backup memory usage stuff 14:20:23 * fabiooliveira oh no, you're jinxed -- kidding 14:20:28 whoami-rajat: those are ready now, so I should be able to go back to it 14:21:07 the task status one really needs to be either approved or not so they can start the coding. This has been hanging around since Yoga 14:21:17 geguileo, np, just wanted to know we're on track as next week is spec freeze 14:21:20 next time someone sees hemna in #openstack-cinder, please ask him to go back to https://review.opendev.org/c/openstack/cinder-specs/+/818551 and respond to their responses 14:21:25 geguileo, great 14:21:41 whoami-rajat: who needs sleep!! 14:22:19 :D sorry about all the work items you've got in this cycle ... and everything is IMPORTANT!! 14:22:52 lol 14:23:06 there are a lot of old specs out there - we need to either kill them or retarget to zed 14:23:07 as rosmaita said, please followup with hemna on the spec and i will also take a look by this week 14:23:18 speaking of the memory usage stuff, geguileo has an interesting patch up: https://review.opendev.org/c/openstack/devstack/+/845805 14:24:19 the numbers look fascinating, 1GB -> 130 MB 14:24:37 plus, it's not cinder-backup's fault! 14:24:43 (that's the best part) 14:24:44 ++ 14:24:46 lol 14:24:54 yeah, not our fault for once 14:25:11 yeah, another not a cinder issue 14:25:12 \o/ 14:26:33 simondodsley, good idea, i will take a look at specs that are not relevant for Zed and ask them to be retargeted or abandoned 14:26:54 ok so let's move on to topics 14:26:55 i've already asked for retargets but there have been no responses 14:27:24 oh, then we probably should abandon them after a certain amount of time but not too sure about it 14:27:32 rosmaita, what do you think ? ^ 14:28:15 whoami-rajat: yes, we should abandon anything maybe older than 2 cycles 14:28:23 rosmaita: ++ 14:28:30 with a note, "feel free to restore if you want to keep working on this" 14:28:47 we've got 2 PTLs approval on this so let's move on with this strategy ^ 14:29:16 ok moving on to topics 14:29:18 #topic Reviews request 14:29:22 enriquetaso, that's you 14:29:32 Hey 14:29:33 #link https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/782624/ 14:29:50 Just asking for reviews again :P 14:29:51 I really need some reviews in this to continue working on more tempest patches. 14:30:16 I'd like to see the mimic client on the CI before submitting more tempest test 14:30:20 reminder: all cinder-core are also devstack-plugin-ceph cores 14:30:33 thanks! That's all for me! 14:30:45 I think we discussed this patch a few time ago on this meeting 14:30:52 and could be ready to merge 14:31:20 the comment i read in the patch might not be too accurate 14:31:21 # Enables new features such as Clone v2 API, which allows proper handling of 14:31:21 # deleting snapshots with child clone images. 14:31:33 but will add a comment to the patch 14:31:45 so cores, please take a look as it's blocking work ^ 14:31:59 whoami-rajat++ 14:32:08 thanks, I'll update the commit msg after your review 14:32:23 ack thanks 14:32:29 moving on 14:32:31 #topic Four issues with cinderlib 14:32:35 rosmaita, that's you 14:32:39 lot to talk about here, but mostly informative (i believe everything is close to a solution if we agree) 14:32:47 so, the previous PTL seems to have left cinderlib in a heck of a state 14:32:52 issue #1: cinderlib CI 14:32:59 cinderlib is a cycle-trailing release, so master is still yoga development 14:33:05 hasn't been a problem in the past, but zed doesn't support py36 anymore, while yoga does 14:33:15 so we started hitting gate failures due to testing cinderlib (yoga development) with master (zed development) upper-constraints 14:33:23 fixed by including overrides in .zuul.yaml 14:33:30 part one (merged): https://review.opendev.org/c/openstack/cinderlib/+/845170 14:33:37 part two: https://review.opendev.org/c/openstack/cinderlib/+/845272 14:33:44 (job wasn't failing, but I think that was luck, and we should be consistent about these changes) 14:34:02 so, just need reviews on part two ^^ 14:34:10 and the issue will be solved! 14:34:17 issue #2: unconstrained builds 14:34:22 tox.ini is set up so that we install cinder and os-brick from source 14:34:29 os-brick is in upper-constraints, so if we use upper-constraints, we can't install it 14:34:35 (because the development version exceeds what's in upper-constraints) 14:34:44 at the same time, if we don't constrain cinderlib for testing, we really don't know what library versions are actually being used 14:34:51 so we really do want to constrain it 14:34:58 proposed solution is https://review.opendev.org/c/openstack/cinderlib/+/845607 14:35:04 (which needs reviews) 14:35:11 it creates a local-upper-constraints.txt that doesn't include os-brick 14:35:16 it gets generated as part of the tox install_command 14:35:24 you can override the file that's used with the CINDERLIB_CONSTRAINTS_FILE environment var 14:35:30 I decided not to hide local-upper-constraints.txt in the tox temp dir so you can see exactly what's being used 14:35:36 that filename is added to .gitignore, so it shouldn't bother you at all 14:35:43 the reason why we're not using the standard TOX_CONSTRAINTS_FILE environment var is to make this change work with zuul 14:35:50 zuul always overrides TOX_CONSTRAINTS_FILE to use upper-constraints directly from its install of openstack/requirements 14:35:57 (this makes it possible to use Depends-on when testing upper-constraints changes) 14:36:05 and it overrides it aggressively, can't change this in our .zuul.yaml 14:36:11 so we have to use CINDERLIB_CONSTRAINTS_FILE 14:36:16 the downside is that we can't use Depends-on to test upper-constraints changes in the gate 14:36:22 but i don't think this is a big deal because cinderlib is a cycle-trailing release 14:36:30 so any problems will most likely be caught earlier by cinder 14:36:38 and you can always test locally by downloading the patched u-c file and setting CINDERLIB_CONSTRAINTS_FILE 14:36:44 (though you have to remember to remove os-brick from the patched file) 14:36:55 so that's how the patch works, please review and leave questions etc: 14:37:00 https://review.opendev.org/c/openstack/cinderlib/+/845607 14:37:30 the nice thing is that that patch works for both tox and zuul 14:37:50 issue #3: not running requirements-check job 14:37:55 the standard requirements check template is not set up to handle trailing releases 14:38:04 but we only have 3 requirements: 14:38:10 https://opendev.org/openstack/cinderlib/src/branch/master/requirements.txt 14:38:25 so, this file ^^ is interesting because it contains cinder 14:38:30 it's needed for when someone installs cinderlib from pypi 14:38:37 we don't actually use the requirements.txt in the cinderlib tox.ini 14:38:43 because we install cinder and os-brick from source 14:38:49 and importlib-metadata is used by cinder, so we get it that way 14:38:59 so my proposal is that the PTL just check manually to make sure that requirements.txt is correct 14:39:09 os-brick and importlib-metadata are in global-requirements 14:39:14 but ... cinder is not 14:39:19 and it's not allowed in there 14:39:30 for info about this if you care, see this discussion in #openstack-requirements: 14:39:37 https://meetings.opendev.org/irclogs/%23openstack-requirements/%23openstack-requirements.2022-06-08.log.html#t2022-06-08T15:36:55 14:39:44 if cinderlib starts using more requirements, we can revisit this 14:39:50 but for now, I propose we do nothing 14:39:59 (just wanted to make sure everyone understands what's going on) 14:40:11 ok, finally 14:40:18 issue #4: not using released versions of cinder, os-brick in CI 14:40:25 we probably had this discussion when cinderlib CI was first set up for the train release, but I don't remember the reasons 14:40:31 so the issue is that all our CI is using cinder and os-brick source, so possibly using unreleased changes 14:40:39 we could add more jobs 14:40:46 or, we could just make sure that when we release yoga cinderlib 14:40:53 we also release yoga cinder and os-brick (if they contain any unreleased changes) 14:41:00 then we'll know that cinderlib has not been relying on any unreleased code to pass its CI 14:41:26 that's it ... so to summarize 14:41:33 issue #1 pretty much solved 14:41:45 issue #2 probably solved? 14:42:00 issues #3, #4 ... i propose we do nothing 14:42:18 sorry that was a lot of text to dump in here 14:42:26 any questions? 14:42:32 (I voted -1 on the second patch of #1 but it's either easily solvable or I'm plainly wrong) 14:42:34 rosmaita: regarding the cinderlib requirements, it should *never* have any more than what we currently have 14:42:49 so it should be ok leaving it as it is (like you propose) 14:42:56 works for me! 14:42:57 for #3, i think it's OK to manually check if right versions of cinder and os-brick are mentioned in requirements.txt unless someone thinks otherwise 14:43:35 yeah, the alternative is to hack the requirements file like i did with upper-constraints ... don't think it's worth it, though 14:43:56 rosmaita: I don't see the issue for #4 14:44:34 for 3 requirements? don't think so and doesn't add much burden on me as well so no problem at all 14:44:50 rosmaita: when both are working on the same release it makes sense to run it against master, since we want them to keep in sync and not find surprises 14:45:25 rosmaita: once os-brick releases we pin it to in cinderlib tox.ini to the stable branch, and the same thing when cinder releases 14:45:40 and then once cinderlib releases we can unpin those 2 14:45:50 right, it's just that it could be possible that some stuff has been merged to cinder or os-brick stable/yoga that we are testing with 14:45:57 I believe that's mostly what we've been doing 14:46:19 and if someone installs cinderlib from pypi, they get released versions of cinder, os-brick 14:46:37 true 14:46:44 it's pretty unlikely 14:46:57 I don't anticipate many issues there though 14:46:59 but to be safe, we can just release new cinder and os-brick at the same time 14:47:09 yeah, i am just being over-cautious 14:47:31 yeah, I just feel bad giving extra work with those 2 additional releases 14:47:43 rosmaita, do you mean releasing stable/yoga of cinder and os-brick? 14:47:47 releases are cheap ... testing is hard! 14:47:50 whoami-rajat: yes, exactly 14:47:56 :-) 14:48:25 by the way, i meant to say something about cinderlib for people here who are unfamiliar with it 14:48:26 we can do it but if we think we're good with what we currently have then maybe not required 14:49:34 ok that doesn't seem like a big issue to discuss right now, i think the focus should be more on #1 and #2 14:49:47 cinderlib is used by Ember-CSI which is a container storage interface for kubernetes 14:49:50 and thanks rosmaita for finding out the issues and providing a verbose summary 14:50:03 so you can use the cinder drivers without having to run cinder as a service 14:50:17 yeah, verbosity is my middle name 14:50:25 that's all from me 14:50:30 lol 14:50:51 great, so i guess that's all we had for topics 14:50:56 let's move to open discussion 14:51:00 Anyone else seeing tempest test `tempest.api.compute.admin.test_volume_swap.TestMultiAttachVolumeSwap` failing with `ValueError: Multiple pingable or sshable servers not supported at this stage`? Seems to be ever since https://review.opendev.org/c/openstack/tempest/+/842921 merged 14:51:12 #topic open discussion 14:51:45 Hi, I am representing Fungible (https://www.fungible.com/product/nvme-over-tcp-fungible-storage-cluster/) and attending this meeting for the first time. 14:51:54 Just wanted to talk about a new driver for Fungible storage backend. 14:52:02 I have submitted a blueprint for the new driver (https://blueprints.launchpad.net/cinder/+spec/fungible-volume-driver) 14:52:09 CI setup in progress. Expected to be ready by end of this month. Planning to submit a patch once the CI is ready. 14:52:17 Can this be targeted for Zed? 14:52:27 aneeeshp1: welcome! 14:52:42 aneeeshp1, Welcome! 14:52:44 aneeeshp1: welcome to the cinder meetings! 14:52:55 Thank you! 14:52:55 Welcome. :-) 14:52:59 welcome \o/ 14:53:05 aneeeshp1, sine you've filed a blueprint, you're already on the right track, one question, do you have a patch up for the new driver? 14:53:32 aneeeshp1: https://releases.openstack.org/zed/schedule.html#cinder-new-driver-merge-deadline 14:53:36 ah you already said it will be pushed once CI is ready, my bad 14:53:36 whoami-rajat: not yet. Will be ready by end of this month. 14:54:38 aneeeshp1, so currently our deadline for driver merging is 15th July, maybe enough time to review the change but will be good if you can try to get it done earlier 14:54:47 #link https://releases.openstack.org/zed/schedule.html#z-cinder-driver-deadline 14:55:15 how many drivers are proposed at this point? i am losing count 14:55:17 ah, rosmaita shared this already, I'm skipping some messages ... 14:55:30 more than we can review? 14:55:32 aneeeshp1: you can push the patch before upstream CI is ready 14:55:36 6-7 probably 14:55:38 Can the patch review start before the CI is ready. I might be able to submit the patch earlier, but CI will take some time (end of the month) 14:55:46 yes it can 14:55:59 Thank you geguileo. I will do that 14:56:09 yes, it won't be merged unless the CI is reporting but that doesn't block reviewing the driver patch 14:56:19 Okay thanks 14:56:28 I will create patch ASAP. 14:56:50 great, thanks for your contribution 14:56:59 thank you all 14:57:03 looks like 8 new drivers 14:57:07 make sure to add it to the work items section in your blueprint 14:57:13 sure 14:57:41 rosmaita, wow, maybe the highest I've seen in a cycle 14:57:51 Yes. 14:58:07 Since the old days when we were the hot new thing in town. 14:58:15 I will create etherpad for spec and drivers to prioritize them 14:58:21 cool 14:58:29 hi, so real quick (I hope... unless there are any objections and maybe I should have put this in the schedule)... so you may remember that in the May 25h video meeting I brought up a problem with the StorPool driver keeping Glance images in a different Cinder pool (underlying StorPool template) than the volumes the users wish to create, and there seemed to be some consensus that instead of 14:58:35 every driver reimplementing half of the workflow for creating an image out of a volume, it might be easier to add a driver capability "I know how to clone volumes efficiently even into a different pool"... so today I filed https://blueprints.launchpad.net/cinder/+spec/clone-across-pools and what do people think about the name of the capability? 14:59:09 I have already started working on it (we have to do something like this at a customer installation and this option, a driver capability, will be *much* cleaner than what we have now), I guess I will have something ready for review in a day or two 14:59:11 also one announcement i forgot ... we've the festival of XS reviews this Friday, but i will be sending a reminder to ML anyway 15:00:27 oh,i wont attend this XS review festival because i'm on AR Holiday :( 15:00:39 wow, third friday of the month has arrived really fast! 15:01:07 rosmaita: Yeah, how did that happen already? :-) 15:01:08 Roamer`, thanks for providing the update 15:01:23 enriquetaso, ah shoot, but no problem 15:01:44 rosmaita, yeah really, i thought it was the second one this Friday 15:01:57 we've passed the time limit for the meeting 15:02:03 so let's wrap it up 15:02:08 thanks everyone 15:02:09 #endmeeting