14:05:27 <jbernard> #startmeeting cinder
14:05:27 <opendevmeet> Meeting started Wed Dec 18 14:05:27 2024 UTC and is due to finish in 60 minutes.  The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:27 <opendevmeet> The meeting name has been set to 'cinder'
14:05:31 <jbernard> #topic roll call
14:05:33 <jbernard> o/
14:05:33 <Sai> o/
14:05:35 <simondodsley> o/
14:05:37 <rosmaita> o/
14:05:41 <jhorstmann> o/
14:05:48 <whoami-rajat> hi
14:05:58 <tosky> o/
14:06:09 <rosmaita> simondodsley: i thought that cinder-tempest-plugin patch was never going to merge!
14:06:13 <akawai> o/
14:06:33 <simondodsley> rosmaita I know - it kept me up all weekend
14:07:23 <jbernard> thanks everyone for coming
14:07:33 <jbernard> #topic annoucements
14:07:45 <jbernard> very little this week
14:08:10 <jbernard> this is the last meeting of the year, the next 2 (or 3?) ill be afk
14:08:34 <jbernard> ill be around most of it though, just not in normal capacity
14:08:54 <jbernard> #topic status
14:09:05 <jbernard> rosmaita, simondodsley: how are the gate issues, is everyting okay there?
14:09:16 <rosmaita> as good as it ever is
14:09:22 <simondodsley> i think we are good
14:09:29 <jbernard> awesome
14:09:41 <jbernard> thanks for babysitting those patches over the weekened, i saw the rechecks
14:10:38 <jbernard> whoami-rajat: curious how the dm-clone review is coming
14:10:57 <whoami-rajat> jbernard, that's a good topic that i also wanted to discuss
14:11:08 <jbernard> #topic dm-clone spec
14:11:26 <whoami-rajat> so basically it's currently held at terminology, move/migrate vs transfer vs relocate
14:11:40 <whoami-rajat> currently we use migration in context of moving volumes between backends
14:11:52 <whoami-rajat> transfers for moving between projects
14:12:02 <whoami-rajat> and relocate is a new term that Jan proposed
14:12:27 <whoami-rajat> wanted to know which one will be most suitable for the operation done by the dm-clone driver
14:12:42 <whoami-rajat> i.e. moving volumes in background along with the live migrated instance
14:13:04 <simondodsley> that feels like migration is the best term
14:13:04 <whoami-rajat> the first two can cause confusion with our existing terminology
14:13:13 <rosmaita> i'm inclined to go with 'relocate'
14:13:30 <jbernard> the volume is only changing where it is located, not backend or any other metadata?
14:13:52 <jbernard> relocate rises in my mind too, personally
14:13:58 <simondodsley> but you are moving volumes between different backends (they just happen to be ypervisors) so it's technically migration
14:14:17 <jhorstmann> migration would be suitable as it moves volumes between services, but the process differs from current cinder volume migrations
14:14:41 <rosmaita> jhorstmann: can you say a bit more about that
14:15:00 <rosmaita> i think the issue is whether it's a big enough difference to not call it 'migration'
14:16:00 <jhorstmann> most important difference is that the switch of the volume objects (change of name_id) is done at the beginning of data transfer instead of at the end
14:17:14 <jbernard> iiuc, the backend is not changing, just were the volume is located, no?
14:17:42 <whoami-rajat> each compute node will have a dedicated cinder-volume service so yes service also changes
14:17:54 <whoami-rajat> s/service/backend
14:17:55 <jhorstmann> yes, the idea was to allow movement between the same backend
14:18:14 <whoami-rajat> jhorstmann, but we configure multiple backends in cinder, one for each compute right?
14:18:27 <jhorstmann> sorry I might be fuzzy on the corect terminology here
14:19:17 <whoami-rajat> so when you deploy a setup with multiple computes, do you mention multiple values in enabled_backends config option in cinder.conf?
14:19:18 <simondodsley> you are moving the volme to a different hypervisor so that is a different backend
14:20:00 <jbernard> ^ my brain sees it as different hosts/services, but the backend (dm-clone) remains the same
14:20:13 <jhorstmann> the volume service on each compute node would have the same backend name configured
14:20:23 <whoami-rajat> my main worry to not use 'migration' was, we are not calling cinder migrate operation anywhere, it just happens when we live-migrate an instance
14:20:34 <whoami-rajat> which is different from how we typically trigger volume migration
14:21:03 <whoami-rajat> in other backends, we just change the attachment reference of the volume but here we are moving the volume along with the VM
14:21:20 <jhorstmann> live-migrate and attach (in the general case)
14:21:30 <whoami-rajat> yes attach as well
14:21:46 <whoami-rajat> but that's now how cinder migration is triggered in other backends
14:22:11 <whoami-rajat> it's a separate operation on it's own triggered by the admin, this is something internally done by the backend
14:22:21 <simondodsley> the enabled_backend is the same that implies a compute AZ, but not a backend in reality
14:23:41 <simondodsley> how does this work with multiple compute AZs
14:27:42 <jhorstmann> simondodsley: is question whether it should be allowed to move the volume between AZs? Because technically I do not see a problem as long as the deployment provdes storage network between AZs. But AZs are difficult with this driver as the failure domain is the compute node
14:30:05 <jhorstmann> regarding terminology: there also the need to talk about cinder volume migration and dm-clone based data transfer in the same spec/documentation
14:30:10 <simondodsley> OK. I thinking (possibly not coherently) about DCN deployments (core/edge type stuff) where the services are very distributed and don't have direct netwrok connectivity
14:31:36 <whoami-rajat> Personally i feel if we are not asking Cinder to migrate a volume and the backend does it internally due to it's architecture, i won't consider it as a 'Cinder migration' operation
14:32:51 <jhorstmann> also none of the existing migration related methods would be involved
14:32:55 <jbernard> that's how i see it as well, it will complicate actual volume migration dicussion/logic
14:34:12 <jbernard> simondodsley: where are you on this?
14:35:25 <simondodsley> i am conflicted as this feels like a migration (mving the volume to a new physical location) but it isn't reallt a migration in the traditonal sense. Adding in a new ter, eg relocate, might just confuse users.
14:37:27 <whoami-rajat> i don't think the 'relocate' part will show up anywhere, since it's happening internally the users don't really need to care about it, it's just used for the purpose of spec
14:37:34 <whoami-rajat> jhorstmann, can correct me on this ^
14:37:43 <jbernard> how about this: since it's a terminology issue, let's let it pass and revisit in the patch review; if there's no technical issues remaining id I'd like to keep moving forward
14:38:19 <jbernard> whoami-rajat: yes, this term would only be visible if you're reading the driver code, i believe
14:38:29 <whoami-rajat> jbernard, +1
14:38:43 <jhorstmann> the term will be used in the spec, maybe in the driver code as comments or names
14:39:14 <whoami-rajat> jhorstmann, but users won't read the driver code, is there any section of user facing document that this needs to show up in?
14:39:41 <simondodsley> what about when thi goes into the cinder support matrix. how will it show there?
14:39:53 <jhorstmann> no, I don't think so. It will be hidden from users and will not need to be exposed as a new concept
14:40:39 <whoami-rajat> simondodsley, it's not a cinder operation so do we need to represent it in the support matrix?
14:41:08 <jbernard> i don't think so, it's just an internal (to the driver) term
14:41:09 <jhorstmann> I mean the whole idea is to hide this from the user and make local storage magically appear :)
14:41:16 <simondodsley> i'd rather it wasn't inthe matrix, so if it isn't planned to go in there, then we can move forward with the spec
14:41:40 <whoami-rajat> jhorstmann, that's how i see it as well
14:41:57 <whoami-rajat> simondodsley, thanks, that's really helpful
14:42:17 <jbernard> ok, i think we have a path
14:42:46 <jbernard> #topic new locations api
14:42:48 <jbernard> whoami-rajat: ^
14:43:10 <whoami-rajat> yeah so this was a discussion that was planned to happen during PTG
14:43:10 <jbernard> #link https://review.opendev.org/q/topic:%22new-location-api-support%22+status:open
14:43:30 <whoami-rajat> it's basically a feature to tackle with a OSSN which glance fixed by implementing new APIs
14:43:46 <whoami-rajat> we currently use the locations API during upload volume operation
14:44:13 <whoami-rajat> I've proposed patches (some already merged) to add this support and also test it in the gate
14:44:45 <whoami-rajat> I've verified locally and in gate that the APIs works correctly, at least from cinder perspective
14:44:57 <whoami-rajat> so if there are any doubts/concerns regarding this, I'm happy to answer
14:45:14 <whoami-rajat> otherwise it just needs reviews
14:45:52 <jbernard> just to clarify, are these something that were expected to land within the cycle, or as time allows?
14:46:11 <jbernard> (trying to guage priority)
14:46:46 <whoami-rajat> so glance just merged the feature last cycle, the idea is to adopt it this cycle by the consumers (nova and cinder)
14:46:59 <whoami-rajat> i didn't check on the nova progress but yeah would be great if we can merge it this cycle
14:47:10 <whoami-rajat> it's a small change, calling the new API
14:47:23 <whoami-rajat> if it isn't supported (older version of glance) then we fallback to old API
14:47:33 <jbernard> ok, great
14:47:48 <whoami-rajat> #link https://review.opendev.org/c/openstack/cinder/+/909513/2/cinder/image/glance.py#382
14:48:40 <whoami-rajat> thanks, that's all from my side
14:49:18 <jbernard> ok, we have review requests, but no other topics
14:49:35 <jbernard> #topic open discussion
14:49:59 <jbernard> happy holidays everyone, hopefully we all get some recovery time :)
14:50:24 <whoami-rajat> happy holidays! (though I will be around)
14:52:37 <jhorstmann> simondodsley: could you leave a comment regarding AZ/DCN on the spec, please. Might be good to have a record there
14:52:40 <whoami-rajat> jbernard, so next meetings are on 25th and 1st, both being holidays, so should we cancel those meetings?
14:52:51 <jbernard> whoami-rajat: yep, ill send a mail
14:52:58 <whoami-rajat> great, thanks
14:53:02 <jbernard> whoami-rajat: school starts back on monday, jan 6
14:53:35 <whoami-rajat> ack
14:55:01 <jbernard> ok, last call everyone
14:55:30 <jbernard> thanks, have a great next couple weeks, i wish you all well, talk again next year!!
14:55:34 <jbernard> #endmeeting