| *** mhen_ is now known as mhen | 02:52 | |
| whoami-rajat | hi | 14:05 |
|---|---|---|
| jbernard | #startmeeting cinder | 14:05 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:05 |
| opendevmeet | The meeting name has been set to 'cinder' | 14:05 |
| jbernard | #topic roll call | 14:05 |
| jbernard | o/ | 14:05 |
| Sai | o/ | 14:05 |
| simondodsley | o/ | 14:05 |
| rosmaita | o/ | 14:05 |
| jhorstmann | o/ | 14:05 |
| whoami-rajat | hi | 14:05 |
| tosky | o/ | 14:05 |
| rosmaita | simondodsley: i thought that cinder-tempest-plugin patch was never going to merge! | 14:06 |
| akawai | o/ | 14:06 |
| simondodsley | rosmaita I know - it kept me up all weekend | 14:06 |
| jbernard | thanks everyone for coming | 14:07 |
| jbernard | #topic annoucements | 14:07 |
| jbernard | very little this week | 14:07 |
| jbernard | this is the last meeting of the year, the next 2 (or 3?) ill be afk | 14:08 |
| jbernard | ill be around most of it though, just not in normal capacity | 14:08 |
| jbernard | #topic status | 14:08 |
| jbernard | rosmaita, simondodsley: how are the gate issues, is everyting okay there? | 14:09 |
| rosmaita | as good as it ever is | 14:09 |
| simondodsley | i think we are good | 14:09 |
| jbernard | awesome | 14:09 |
| jbernard | thanks for babysitting those patches over the weekened, i saw the rechecks | 14:09 |
| jbernard | whoami-rajat: curious how the dm-clone review is coming | 14:10 |
| whoami-rajat | jbernard, that's a good topic that i also wanted to discuss | 14:10 |
| jbernard | #topic dm-clone spec | 14:11 |
| whoami-rajat | so basically it's currently held at terminology, move/migrate vs transfer vs relocate | 14:11 |
| whoami-rajat | currently we use migration in context of moving volumes between backends | 14:11 |
| whoami-rajat | transfers for moving between projects | 14:11 |
| whoami-rajat | and relocate is a new term that Jan proposed | 14:12 |
| whoami-rajat | wanted to know which one will be most suitable for the operation done by the dm-clone driver | 14:12 |
| whoami-rajat | i.e. moving volumes in background along with the live migrated instance | 14:12 |
| simondodsley | that feels like migration is the best term | 14:13 |
| whoami-rajat | the first two can cause confusion with our existing terminology | 14:13 |
| rosmaita | i'm inclined to go with 'relocate' | 14:13 |
| jbernard | the volume is only changing where it is located, not backend or any other metadata? | 14:13 |
| jbernard | relocate rises in my mind too, personally | 14:13 |
| simondodsley | but you are moving volumes between different backends (they just happen to be ypervisors) so it's technically migration | 14:13 |
| jhorstmann | migration would be suitable as it moves volumes between services, but the process differs from current cinder volume migrations | 14:14 |
| rosmaita | jhorstmann: can you say a bit more about that | 14:14 |
| rosmaita | i think the issue is whether it's a big enough difference to not call it 'migration' | 14:15 |
| 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:16 |
| jbernard | iiuc, the backend is not changing, just were the volume is located, no? | 14:17 |
| whoami-rajat | each compute node will have a dedicated cinder-volume service so yes service also changes | 14:17 |
| whoami-rajat | s/service/backend | 14:17 |
| jhorstmann | yes, the idea was to allow movement between the same backend | 14:17 |
| whoami-rajat | jhorstmann, but we configure multiple backends in cinder, one for each compute right? | 14:18 |
| jhorstmann | sorry I might be fuzzy on the corect terminology here | 14:18 |
| 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 |
| simondodsley | you are moving the volme to a different hypervisor so that is a different backend | 14:19 |
| jbernard | ^ my brain sees it as different hosts/services, but the backend (dm-clone) remains the same | 14:20 |
| jhorstmann | the volume service on each compute node would have the same backend name configured | 14:20 |
| 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 |
| whoami-rajat | which is different from how we typically trigger volume migration | 14:20 |
| 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 |
| jhorstmann | live-migrate and attach (in the general case) | 14:21 |
| whoami-rajat | yes attach as well | 14:21 |
| whoami-rajat | but that's now how cinder migration is triggered in other backends | 14:21 |
| 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 |
| simondodsley | the enabled_backend is the same that implies a compute AZ, but not a backend in reality | 14:22 |
| simondodsley | how does this work with multiple compute AZs | 14:23 |
| 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:27 |
| 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 |
| 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:30 |
| 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:31 |
| jhorstmann | also none of the existing migration related methods would be involved | 14:32 |
| jbernard | that's how i see it as well, it will complicate actual volume migration dicussion/logic | 14:32 |
| jbernard | simondodsley: where are you on this? | 14:34 |
| 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:35 |
| 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 |
| whoami-rajat | jhorstmann, can correct me on this ^ | 14:37 |
| 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:37 |
| jbernard | whoami-rajat: yes, this term would only be visible if you're reading the driver code, i believe | 14:38 |
| whoami-rajat | jbernard, +1 | 14:38 |
| jhorstmann | the term will be used in the spec, maybe in the driver code as comments or names | 14:38 |
| 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 |
| simondodsley | what about when thi goes into the cinder support matrix. how will it show there? | 14:39 |
| 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:39 |
| whoami-rajat | simondodsley, it's not a cinder operation so do we need to represent it in the support matrix? | 14:40 |
| jbernard | i don't think so, it's just an internal (to the driver) term | 14:41 |
| jhorstmann | I mean the whole idea is to hide this from the user and make local storage magically appear :) | 14:41 |
| 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 |
| whoami-rajat | jhorstmann, that's how i see it as well | 14:41 |
| whoami-rajat | simondodsley, thanks, that's really helpful | 14:41 |
| jbernard | ok, i think we have a path | 14:42 |
| jbernard | #topic new locations api | 14:42 |
| jbernard | whoami-rajat: ^ | 14:42 |
| whoami-rajat | yeah so this was a discussion that was planned to happen during PTG | 14:43 |
| jbernard | #link https://review.opendev.org/q/topic:%22new-location-api-support%22+status:open | 14:43 |
| whoami-rajat | it's basically a feature to tackle with a OSSN which glance fixed by implementing new APIs | 14:43 |
| whoami-rajat | we currently use the locations API during upload volume operation | 14:43 |
| whoami-rajat | I've proposed patches (some already merged) to add this support and also test it in the gate | 14:44 |
| whoami-rajat | I've verified locally and in gate that the APIs works correctly, at least from cinder perspective | 14:44 |
| whoami-rajat | so if there are any doubts/concerns regarding this, I'm happy to answer | 14:44 |
| whoami-rajat | otherwise it just needs reviews | 14:45 |
| jbernard | just to clarify, are these something that were expected to land within the cycle, or as time allows? | 14:45 |
| jbernard | (trying to guage priority) | 14: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 |
| whoami-rajat | i didn't check on the nova progress but yeah would be great if we can merge it this cycle | 14:46 |
| whoami-rajat | it's a small change, calling the new API | 14:47 |
| whoami-rajat | if it isn't supported (older version of glance) then we fallback to old API | 14:47 |
| jbernard | ok, great | 14:47 |
| whoami-rajat | #link https://review.opendev.org/c/openstack/cinder/+/909513/2/cinder/image/glance.py#382 | 14:47 |
| whoami-rajat | thanks, that's all from my side | 14:48 |
| jbernard | ok, we have review requests, but no other topics | 14:49 |
| jbernard | #topic open discussion | 14:49 |
| jbernard | happy holidays everyone, hopefully we all get some recovery time :) | 14:49 |
| whoami-rajat | happy holidays! (though I will be around) | 14:50 |
| jhorstmann | simondodsley: could you leave a comment regarding AZ/DCN on the spec, please. Might be good to have a record there | 14:52 |
| whoami-rajat | jbernard, so next meetings are on 25th and 1st, both being holidays, so should we cancel those meetings? | 14:52 |
| jbernard | whoami-rajat: yep, ill send a mail | 14:52 |
| whoami-rajat | great, thanks | 14:52 |
| jbernard | whoami-rajat: school starts back on monday, jan 6 | 14:53 |
| whoami-rajat | ack | 14:53 |
| jbernard | ok, last call everyone | 14:55 |
| jbernard | thanks, have a great next couple weeks, i wish you all well, talk again next year!! | 14:55 |
| jbernard | #endmeeting | 14:55 |
| opendevmeet | Meeting ended Wed Dec 18 14:55:34 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:55 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/cinder/2024/cinder.2024-12-18-14.05.html | 14:55 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/cinder/2024/cinder.2024-12-18-14.05.txt | 14:55 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/cinder/2024/cinder.2024-12-18-14.05.log.html | 14:55 |
| whoami-rajat | thanks! | 14:55 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!