| opendevreview | Keerthivasan S proposed openstack/cinder master: [Pure Storage] Unit tests and fixed variable name for Replication-Enabled Consistency Groups https://review.opendev.org/c/openstack/cinder/+/897382 | 11:12 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/cinder master: Fix python shebang https://review.opendev.org/c/openstack/cinder/+/898600 | 15:47 |
| opendevreview | Takashi Kajinami proposed openstack/cinder master: Fix python shebang https://review.opendev.org/c/openstack/cinder/+/898600 | 16:03 |
| sean-k-mooney | eharney: can you remove the +w on https://review.opendev.org/c/openstack/cinder/+/868485 | 16:38 |
| sean-k-mooney | the limit on the leght of image metadta vlaues comes form nova's db not glances | 16:39 |
| sean-k-mooney | so it not safe to lift the lmit in cinder | 16:39 |
| eharney | sean-k-mooney: done, sounds worth digging into... why is it not safe? | 16:48 |
| eharney | i believe you can create glance images with those longer fields now | 16:48 |
| sean-k-mooney | im diging into the details of the patch | 16:48 |
| sean-k-mooney | so image metaedata keys are not free from and defiend by nova | 16:49 |
| sean-k-mooney | values are also checked by nova | 16:49 |
| sean-k-mooney | so glance would accpet it | 16:49 |
| sean-k-mooney | but you coudl not boot a vm with it | 16:49 |
| sean-k-mooney | boot form volume might work but i woudl expect it to fial | 16:50 |
| sean-k-mooney | attaching a volume with longer keys should work | 16:50 |
| sean-k-mooney | we only embed the image properies for the root disk | 16:50 |
| sean-k-mooney | so a volume created form an image with longer vlaues that is attached as a data voume would likely not break anything | 16:51 |
| sean-k-mooney | eharney: i commented on the bug looking at it more closely nova is ignroign any image porperies it does not recognise | 17:30 |
| sean-k-mooney | we have been assuimg that custom image proeprties have not been supproted in general since mitaka more or less | 17:31 |
| sean-k-mooney | but we do create soem for snapshots on the glace cide | 17:31 |
| sean-k-mooney | so the cahnge may or may not be ok | 17:31 |
| sean-k-mooney | looking at the code provided one of the filed that is over 255 is not one know about by nova it proably woudl work | 17:32 |
| sean-k-mooney | but im expecing a db error for the others or an object error if the image property is an enuma or other restricted data type | 17:33 |
| sean-k-mooney | so maybe its ok form a cidner perspective but i would expect this to be an api microversion bump at a minium | 17:33 |
| eharney | sean-k-mooney: what would behavior change would change when requesting a newer microversion? | 17:45 |
| sean-k-mooney | allow metadta values larger then 255 | 17:46 |
| sean-k-mooney | the db might already allow that but this is still a schma change | 17:46 |
| eharney | not sure what that means... we can't set the db schema limit based on the microversion | 17:46 |
| sean-k-mooney | exisitg clinet shoudl expect an error if the metadta vlaues are > 255 | 17:46 |
| sean-k-mooney | that not a db schema limit | 17:47 |
| sean-k-mooney | its an api schema limit | 17:47 |
| sean-k-mooney | i.e. what used to validate the json boday | 17:47 |
| eharney | on what operation? | 17:48 |
| sean-k-mooney | on put/post when updating the image metadta | 17:48 |
| sean-k-mooney | althoguh the tricker question is what to do on get if you have data that exceed 255 | 17:48 |
| eharney | but then someone could still update it to the larger size and then another call to consume that volume may not be able to handle that size | 17:49 |
| sean-k-mooney | so im really wondering how nova is going to know that it might need to raise new errors when we read the larger proerties | 17:50 |
| sean-k-mooney | we dont currently validate the lengths of several filed because we were expecting the 255 limit to be enfoced in galnce and cinder | 17:51 |
| sean-k-mooney | so that a problem in nova in either case | 17:51 |
| eharney | is glance doing that currently? | 17:52 |
| sean-k-mooney | i guess i can check there api ref | 17:52 |
| sean-k-mooney | https://docs.openstack.org/api-ref/image/v2/?expanded=import-an-image-detail#request | 17:54 |
| sean-k-mooney | Additionally, you may include additional properties specified as key:value pairs, where the value must be a string data type. Keys are limited to 255 chars in length. Available key names may be limited by the cloud???s property protection configuration and reserved namespaces like os_glance. | 17:54 |
| sean-k-mooney | they dont actully specify the lenght of the value jsut the key in the api ref... | 17:55 |
| sean-k-mooney | glance seams to not be partically self consitnet | 18:03 |
| sean-k-mooney | the metadef api can only descirb properies whose toal name is 160 (80 for namespace and 80 for name) | 18:04 |
| sean-k-mooney | where as the iamge tabel alows property names of 255 | 18:04 |
| sean-k-mooney | so there api for descirbing the validation of image properies is more restirctive then the api for seting/storing image properties | 18:05 |
| sean-k-mooney | the schma for validating an image https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L1696 | 18:08 |
| sean-k-mooney | does not seam to have any validation for metadata/properties | 18:09 |
| sean-k-mooney | so what i think im learning is nova shoudl not trust glance to have done any validation of the image properites becasue ti does none... | 18:12 |
| opendevreview | Ashley Rodriguez proposed openstack/devstack-plugin-ceph stable/2023.1: Remote Ceph with cephadm https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/897972 | 18:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!