| *** abhishekk is now known as akekane|home | 04:54 | |
| *** akekane|home is now known as abhishekk | 04:54 | |
| opendevreview | Mridula Joshi proposed openstack/glance-specs master: Expanding stores-detail for other stores https://review.opendev.org/c/openstack/glance-specs/+/835606 | 10:06 |
|---|---|---|
| tobias-urdin | jokke_: maybe kind of a long-shot, but we are manually patching our deployments to do something similar to https://review.opendev.org/c/openstack/glance/+/835462 | 10:10 |
| tobias-urdin | what do you think about that? or is there another way (currently) to do it? | 10:10 |
| abhishekk | tobias-urdin, may be this will help you | 10:17 |
| abhishekk | https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#the-image-property-injection-plugin | 10:17 |
| tobias-urdin | hm, problem is that only applies to image import, while users and third-party integrations (horizon etc) would still try to use the file endpoint? | 10:22 |
| abhishekk | yep, it only applies to import | 10:28 |
| tobias-urdin | that is one problem, we don't use image import so I don't know if the patch I linked would even solve that usage as well, but yeah... i'm not sure what to do, our currently solution is very bad in that we have cronjobs and whatnot to solve this | 10:58 |
| abhishekk | I am afraid that this will be considered for upstream glance (but yeah, there is no other way to do it) | 11:01 |
| tobias-urdin | I assume you meant to say "not considered" above? If so, do you have any other suggestions except for the obvious that we'll need to carry that patch ourselves? | 11:10 |
| dansmith | tobias-urdin: it seems reasonable to me to implement things like this for both upload and import | 13:54 |
| dansmith | tobias-urdin: curious to hear why you don't use import (there are lots of reasons, but I'd like to know yours) | 13:55 |
| dansmith | presumably property injection isn't very helpful if it only works for one of the two ways to create an image, so even if you did use import, if upload is available and doesn't inject, that's a problem | 13:55 |
| dansmith | which is why I think it'd be better to do it for both | 13:55 |
| tobias-urdin | yeah, i think we have task very far back in the backlog about checking image import, but never got there | 13:56 |
| tobias-urdin | ideally we would support both until one of them is removed, but we never investigated impact on end-users, third-party integrations or web portals | 13:57 |
| tobias-urdin | for image import that is | 13:57 |
| dansmith | ack, well, import requires substantial disk space on the api workers in order to work, and is technically more steps to upload | 13:58 |
| tobias-urdin | (that is, if we were to disable upload with policy for example, we tend to wanna keep full API compatibility) | 13:58 |
| dansmith | but it used to require *shared* storage amongst all the api workers, which it doesn't anymore | 13:58 |
| dansmith | tobias-urdin: right, so I think having to disable upload to get consistent property injection is kinda dumb, hence my support for making it work in both | 13:59 |
| tobias-urdin | i agree | 13:59 |
| dansmith | image format conversion isn't as easy, so I get why that wouldn't be available in import, but property injection should not be hard :) | 13:59 |
| dansmith | sorry s/import/upload/ :) | 14:00 |
| dansmith | tobias-urdin: if you want to add to to the ptg schedule for glance we could discuss it there | 14:01 |
| tobias-urdin | seems like a good topic to discuss to have a coherent implementation on both sides, i guess since the import part also supports that with the property injection, if upload is suppose to then provide the same experience | 14:04 |
| dansmith | sure, could have that larger discussion with property injection as the example case | 14:05 |
| dansmith | https://etherpad.opendev.org/p/zed-ptg-glance-planning | 14:05 |
| tobias-urdin | i confused myself a little bit when thinking about all the property protection stuff when doing my mentioned proposed change, but hopefully the glance team can clear up any issues with the implementation :) | 14:05 |
| dansmith | add it to the bottom here ^ | 14:05 |
| dansmith | I think the important part is to make the upload implementation pull properties from the same place as import, of course | 14:06 |
| dansmith | unfortunately that's in the image_import config right now, but that doesn't mean we can't read it of course | 14:07 |
| tobias-urdin | added to the bottom, perhaps somebody bites - I will see if I can attend PTG timeslots, unfortunately I haven't checked yet | 14:09 |
| dansmith | tobias-urdin: we should get abhi to schedule that when it works for both of us | 14:09 |
| tobias-urdin | yes :) | 14:11 |
| jokke_ | tobias-urdin: dansmith: The taskflow plugins are import only as we wanted to make sure the client is not held hostage on the request while anything lengthy gets processed. The Interoperable Image Import was designed as the one user facing image creation method while the upload was not deprecated for removal due to the other service (Nova, Cinder, etc.) dependencies | 14:25 |
| jokke_ | It's all documented in the mail long spec for Interoperable Image Import | 14:25 |
| jokke_ | :s/mail/mile/g | 14:25 |
| dansmith | jokke_: yeah I'm well aware that's the intent, but it's not the reality | 14:25 |
| dansmith | I believe abhi was going to put a question about if/why import isn't used into the operator survey, but I don't know if that ever happened | 14:27 |
| dansmith | to gauge how widely it's actually used | 14:27 |
| *** EugenMayer4 is now known as EugenMayer | 16:05 | |
| *** sfinucan is now known as stephenfin | 16:31 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!