14:02:17 <rosmaita> #startmeeting cinder
14:02:17 <opendevmeet> Meeting started Wed Feb  5 14:02:17 2025 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:17 <opendevmeet> The meeting name has been set to 'cinder'
14:02:26 <rosmaita> #topic roll call
14:02:27 <whoami-rajat> hi
14:02:35 <akawai> o/
14:02:38 <nileshthathagar> o/
14:02:40 <sp-bmilanov> hello!
14:02:44 <Sai> o/
14:02:50 <rosmaita> hello sfernand, say hi again so you get into the minutes
14:02:56 <kpdev> hi
14:02:57 <sfernand> hi
14:03:04 <sfernand> ;)
14:03:13 <rosmaita> thanks!
14:03:31 <jhorstmann> hi
14:05:08 <rosmaita> ok, let's get started
14:05:44 <rosmaita> the school bus broke down this morning and Jon had to take his kids to school, so that's why he's not here
14:06:08 <rosmaita> but, there's a kind of light agenda (except for the review requests)
14:06:40 <rosmaita> I'm not aware of anything to announce ... anyone got anything?
14:07:48 <rosmaita> ok, one thing ... looks like PTL self-nomination season is oepn today at 23:45 UTC
14:09:08 <rosmaita> if you are interested in becoming cinder PTL, either for Flamingo or G or H or something
14:09:29 <rosmaita> we have several still-active PTLs you can talk to and find out what the job entails
14:09:58 <rosmaita> (also, i believe that Jon will stand for election again, but i haven't actually asked him)
14:10:10 <rosmaita> but, might as well think about the future
14:10:33 <rosmaita> anyone got anything else?
14:11:43 <rosmaita> ok, on to the topics
14:12:02 <rosmaita> #topic help to review the powermax bug fixes which are important for third party CI
14:12:09 <rosmaita> not sure who put this on?
14:12:22 <rosmaita> possibly nileshthathagar ?
14:13:07 <nileshthathagar> yes that was me
14:13:08 <rosmaita> it is awful quiet in here ... am i netsplit?
14:13:17 <rosmaita> ok, the floor is yours
14:13:32 <whoami-rajat> we can see you rosmaita
14:13:45 <rosmaita> :D
14:13:52 <rosmaita> i am wearing blue today
14:14:32 <whoami-rajat> :D
14:14:49 * whoami-rajat sorry for interrupting, nileshthathagar please go ahead
14:15:24 <nileshthathagar> sure thanks there are few patches which required when powermax CI is ready to run
14:15:29 <rosmaita> nileshthathagar: it sounds like these particular patches are important to get your 3rd party ci working again?
14:15:43 <rosmaita> (or am i thinking of a different dell driver)
14:16:33 <nileshthathagar> when powermax CI will get fixed. this patches also required to CI get passed.
14:17:18 <nileshthathagar> we have all CI gets broken but these patches will help to smooth run of CI when It will get fixed.
14:17:29 <nileshthathagar> for powermax
14:17:33 <rosmaita> ok, the cinder community encourages third party ci, so it makes sense to prioritize these reviews
14:17:59 <nileshthathagar> great. thanks
14:18:19 <rosmaita> i will commit to looking at the 3 on lines 76-78 in the etherpad immediately following the meeting
14:18:31 <rosmaita> can i get a commitment from someone else?
14:19:01 * sp-bmilanov added the the three lines with changes, maybe nileshthathagar can add more if there are any
14:19:19 <rosmaita> ty sp-bmilanov
14:20:23 <rosmaita> i still think i may be netsplit, though that doesn't seem to happen much with OFTC
14:20:27 <nileshthathagar> all added. thanks
14:20:29 <rosmaita> used to happen all the time on freenode
14:20:35 <rosmaita> ok, next item
14:20:52 <rosmaita> #topic old patch of the week
14:20:56 <rosmaita> that's me
14:21:06 <rosmaita> not my patch, but a patch I came across
14:21:16 <rosmaita> Record the original size when creating an image from a volume
14:21:25 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/804584
14:21:46 <rosmaita> seems very straigthtforward, so i am wondering if i am missing something
14:22:03 <rosmaita> basically, the idea is that glance has this 'min_disk" image property
14:22:23 <rosmaita> cinder and nova pay attention to it when you request to do something with an image
14:22:28 <whoami-rajat> nileshthathagar, i wanted to know more details about the os-brick patch, maybe we can discuss in open-discussion
14:23:00 <rosmaita> the issue is that if you upload a volume as an image to glance, and it's a qcow2 or something
14:23:16 <rosmaita> the virtual size of the volume may be bigger than it's actual size in glance
14:23:37 <rosmaita> and when you request to do an image-to-volume operation in cinder, it can fail
14:23:55 <rosmaita> if the user picks a size that looks big enough, but really isn't
14:24:11 <rosmaita> so the proposal is that since we know how big the volume is that we are uploading from cinder
14:24:15 <nileshthathagar> whoami-rajat, we can discuss in direct chat. I am also in another meeting as well.
14:24:20 <rosmaita> and since min_disk is in GB
14:24:21 <sp-bmilanov> this sounds like a Tempest test case as well?
14:24:35 <whoami-rajat> nileshthathagar, sure
14:24:49 <whoami-rajat> rosmaita, so when we upload the volume to glance, doesn't glance calculate the virtual_size?
14:24:50 <rosmaita> cinder can add the min_disk property when the image is uploaded to glance
14:25:16 <rosmaita> whoami-rajat: i am not sure if it does that in the normal upload path
14:25:23 <rosmaita> that may be an image import thing
14:25:29 <rosmaita> (though that may have changed)
14:28:13 <rosmaita> in any case, we have min_disk tooling already in place (on the download side), so maybe it makes sense to do it on upload?
14:28:38 <whoami-rajat> certainly adding min_disk property would make volume create from image request fail fast
14:29:07 <rosmaita> ok, just got confirmation that whoami-rajat is correct, glance does compute virtual_size on the upload path we use
14:29:28 <whoami-rajat> that was quick!
14:29:46 <rosmaita> i think fail-fast is the key thing, if we can fail in the REST API response, that's a better user experience
14:30:06 <rosmaita> whoami-rajat: i just happened to be talking to dansmith in another channel
14:30:20 <whoami-rajat> yep, also the min_disk property would act as a data point for end user to know what size they should provide for the volume create
14:30:24 <whoami-rajat> if users are able to see it
14:30:35 <rosmaita> it's a standard glance property
14:30:55 <rosmaita> the other thing about min_disk is that it is the same unit as cinder volumes
14:31:07 <rosmaita> whereas i believe the virtual_size is bytes
14:32:09 <rosmaita> #link https://docs.openstack.org/api-ref/image/v2/index.html#image-schemas
14:33:11 <rosmaita> so if it is populated in the database, it will be in the image-show response
14:34:38 <rosmaita> ok, well we can continue this discussion on the patch ... it would be good to move that along, because requesting a volume create, and getting a 204, and then having the volume go to error status, is not a good user experience
14:35:25 <rosmaita> now we come  to my least favorite part of the meeting
14:35:34 <rosmaita> #topic review requests
14:35:39 <yuval> :)
14:35:46 <rosmaita> we already discussed the dell PowerMax
14:36:01 <rosmaita> does anyone have anything helpful to point out about the others
14:36:17 <rosmaita> i think sp-bmilanov did put a comment on line 88 that is helpful
14:36:27 <sp-bmilanov> yep, I've got one from me
14:36:30 <rosmaita> (as an explanation of why we need to review quickly)
14:37:09 <sp-bmilanov> yes, in a nutshell, os-brick now uses the internal API client for communicating with StorPool
14:37:40 <sp-bmilanov> because the change is merged, but the change that switches the client over inside Cinder is this one, and still not merged
14:38:22 <sp-bmilanov> it would be really nice not to have a release in which we have to be careful that one is using one, and the other -- another
14:39:04 <rosmaita> yes, it makes sense to get everything in order
14:40:07 <rosmaita> just to be clear, this is an "all-or-nothing" patch, i mean, once the cinder patch is merged, you *must* be using os-brick >=6.10.0
14:40:10 <sp-bmilanov> the change is 80% a search and replace of the API calls, and 20% inits and stuff that are done differently with the internal client
14:40:36 <rosmaita> what i mean is, there is not a provision to fall back to look for the old storpool packages
14:40:39 <sp-bmilanov> yes, I need to check if the requirements.txt reflects this
14:40:52 <rosmaita> yes, you did update requirements.txt on your patch
14:41:29 <sp-bmilanov> ah, right, yes, there is no planned fallback, we would like to support the internal client only, not both
14:42:22 <rosmaita> that's fine, what i am getting at is maybe you should word the release note more strongly
14:42:50 <rosmaita> to make it clear that not only are the storpool packages not required, they are ignored, you must use the correct version of os-brick
14:42:56 <rosmaita> (but maybe that's overkill)
14:43:25 <sp-bmilanov> good point, it should at least mention that it's only the internal client, nothing else
14:43:51 <sp-bmilanov> it see how you could read it as either-or currently
14:44:12 <rosmaita> and maybe in the docs, instead of deleting that section, maybe turn it into a note
14:44:24 <rosmaita> mainly for people upgrading, new users won't care
14:44:49 <rosmaita> but those are nits and could certainly be a follow up
14:45:23 <sp-bmilanov> turn it into a note inside the docs? sth like "previously you had to install X, now you need os-brick Y"?
14:45:40 <sp-bmilanov> or like a proper releasenote with an "upgrade" classifier?
14:45:49 <sp-bmilanov> the latter sounds better
14:46:07 <rosmaita> that sounds good to me
14:46:32 <sp-bmilanov> nice, thanks
14:46:41 <rosmaita> old users will see the upgrade note, and new users don't need to know anything
14:47:09 <rosmaita> ok, any comments about any of the other reviews?
14:48:11 <rosmaita> ok, let's end the meeting early and go do some reviews!
14:48:16 <rosmaita> #endmeeting