| *** bauzas_ is now known as bauzas | 03:47 | |
| *** ministry is now known as __ministry | 04:35 | |
| frickler | stephenfin: how much of https://review.opendev.org/q/topic:%22remove-wsgi_scripts%22 do you think can we get still done this cycle? I have little hope for cinder, but placement could be fine if someone reviews https://review.opendev.org/c/openstack/placement/+/919569 | 05:25 |
|---|---|---|
| *** bauzas_ is now known as bauzas | 05:33 | |
| opendevreview | Rajat Dhasmana proposed openstack/nova master: Correct info about volume-backed server rebuild https://review.opendev.org/c/openstack/nova/+/924574 | 07:16 |
| opendevreview | Sylvain Bauza proposed openstack/nova stable/2024.1: cpu: Only check governor type on online cores https://review.opendev.org/c/openstack/nova/+/924514 | 09:40 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for host aggregate actions API https://review.opendev.org/c/openstack/nova/+/924584 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for host aggregate APIs https://review.opendev.org/c/openstack/nova/+/924585 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for extensions API https://review.opendev.org/c/openstack/nova/+/924586 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for versions APIs https://review.opendev.org/c/openstack/nova/+/924587 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for assisted volume snapshots APIs https://review.opendev.org/c/openstack/nova/+/924588 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for port interface APIs https://review.opendev.org/c/openstack/nova/+/924589 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for availability zone APIs https://review.opendev.org/c/openstack/nova/+/924590 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for bare metal node APIs https://review.opendev.org/c/openstack/nova/+/924591 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for console auth token APIs https://review.opendev.org/c/openstack/nova/+/924592 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for flavor access API https://review.opendev.org/c/openstack/nova/+/924593 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for flavor extra specs APIs https://review.opendev.org/c/openstack/nova/+/924594 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for flavors APIs https://review.opendev.org/c/openstack/nova/+/924595 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for floating IP pool APIs https://review.opendev.org/c/openstack/nova/+/924596 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: docs: Add contributor docs for response body validation https://review.opendev.org/c/openstack/nova/+/924597 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: WIP: tests: Ensure all APIs have a response body schema https://review.opendev.org/c/openstack/nova/+/924598 | 10:53 |
| opendevreview | Stephen Finucane proposed openstack/nova master: WIP: tests: Temporarily ignore missing schemas for removed APIs https://review.opendev.org/c/openstack/nova/+/924599 | 10:54 |
| stephenfin | frickler: There's nothing technically challenging about any of them: it's simply a case of getting them reviewed and merged | 10:54 |
| stephenfin | gibi: You could try calling 'connect_as' on the connection object? That doesn't accept a context object (yet) so you'll need to set the various fields manually but | 10:57 |
| stephenfin | ...that shouldn't be too difficult to do | 10:58 |
| stephenfin | gtema might have a better idea on #openstack-sdks | 10:58 |
| sean-k-mooney | frickler: stephenfin i reviewd the placement patch only the first of the two is requried and can merge this cycle | 11:04 |
| *** iurygregory__ is now known as iurygregory | 11:18 | |
| gibi | stephenfin: thanks I will try and jump over to the sdk channel if needed. | 11:33 |
| *** bauzas_ is now known as bauzas | 12:41 | |
| *** iurygregory__ is now known as iurygregory | 13:01 | |
| *** bauzas_ is now known as bauzas | 13:23 | |
| *** bauzas_ is now known as bauzas | 14:32 | |
| *** bauzas_ is now known as bauzas | 15:00 | |
| *** bauzas_ is now known as bauzas | 15:12 | |
| *** bauzas_ is now known as bauzas | 15:37 | |
| dansmith | melwitt: have you given any thought to how we might record/enforce the disk_format for the things in our _base directory? | 18:41 |
| dansmith | with the oslo stuff simmering I'm trying to figure out what the simplest path to do that is | 18:41 |
| dansmith | and I'm pretty mired down in all the crazy indirection | 18:41 |
| dansmith | at this point I'm kinda thinking that making imagecache.get_cache_fname() ping glance for every call to get disk_format will be the easiest, but that's sort of insane | 18:42 |
| dansmith | I was thinking doing it in fetch(_to_raw)() would be doable, but the depth from which we pass the destination fname is pretty deep | 18:42 |
| dansmith | (or sean-k-mooney ^) | 18:42 |
| melwitt | dansmith: did you change your mind about the "add a file extension to the name" idea or find some issue about it? | 18:43 |
| dansmith | melwitt: no, that's what I'm trying to implement, but it's not as easy as I was hoping | 18:44 |
| dansmith | I guess maybe doing the "database on disk | 18:45 |
| dansmith | might help with the overhead of pinging glance, | 18:45 |
| sean-k-mooney | so for exitng images in the cache that are used for backign files we cant rename them as it would break runing domian | 18:45 |
| dansmith | but we need to make sure we clean that up, and consult it for existing/copied images, etc | 18:45 |
| dansmith | sean-k-mooney: right I know | 18:45 |
| melwitt | dansmith: oh, I see. you could ping for disk_format the first time and then cache it maybe? | 18:45 |
| sean-k-mooney | i was thinkign we would need to check all of the in use images in init host | 18:45 |
| sean-k-mooney | and create a hard/soft link with the extention | 18:45 |
| dansmith | melwitt: sure, but that makes it (much) heavier | 18:45 |
| dansmith | sean-k-mooney: yeah that's how we could handle the existing ones, | 18:46 |
| dansmith | I'm just looking at how to make the first-run case even work | 18:46 |
| dansmith | because we sort of pass the target fname from deep inside libvirt driver, | 18:46 |
| sean-k-mooney | the problem with that is i think the file name is a md5 of the uuid + the caasity | 18:46 |
| sean-k-mooney | althoguh i coudl be wrong | 18:46 |
| dansmith | and when we do, we have recorded only the image id and not the type, etc | 18:46 |
| sean-k-mooney | so im not really sure how to look up the glance iamge | 18:47 |
| dansmith | sean-k-mooney: right, that's a problem for the day-2 case, but I haven't even gotten there... the day zero case is hard enough | 18:47 |
| dansmith | like "assume a blank compute node, how do we *start* recording and enforcing formats" | 18:47 |
| dansmith | figure out the migration of existing stuff later | 18:47 |
| melwitt | sean-k-mooney: yeah it's a fingerprint not the image id (name in the cache) | 18:48 |
| dansmith | right | 18:48 |
| sean-k-mooney | ack i honestly have not looked at this closely enough to say of the top of my head. i was hoping we woudl have some of the image metadata stored like the format in the instastance_system_metadata or somethign like that | 18:48 |
| melwitt | oh yeah, we do have all the image properties stored in instance sysmeta | 18:49 |
| sean-k-mooney | that or the bdms. ill need to load contex tbefore ill be of any help | 18:49 |
| melwitt | not sure if disk_format is always part of that | 18:49 |
| dansmith | I think that's too weak, because we won't have that for things like a rescue image | 18:49 |
| melwitt | yeah, true won't have for rescue | 18:49 |
| dansmith | like, if we're going to make this holistic, it has to be more than just the root disk of an instance during boot | 18:49 |
| dansmith | it would be bad if you could pollute the image cache by doing a rescue to a bad image and then a subsequent normal boot, etc | 18:50 |
| sean-k-mooney | dansmith: well we will likely need to modify the image cache api to pass the format but im not really sure form where other then when we are downloadign the image | 18:50 |
| dansmith | and, we won't know which images in the cache were/are for rescue or anything.. I think we have to get to a point where it's something we can rely on, else we will always have the legacy path | 18:50 |
| dansmith | sean-k-mooney: right, that | 18:50 |
| dansmith | is my point though, | 18:50 |
| dansmith | we | 18:51 |
| dansmith | have already decided what the dest filename will be, before we even fetch it | 18:51 |
| dansmith | and changing that reaches *deep* backwards into the driver | 18:51 |
| dansmith | it's sort of ... insane | 18:51 |
| sean-k-mooney | ok then the alternitive is to write a new info file becied the orgianl with the format as the content | 18:51 |
| melwitt | yeah, it is very disjointed | 18:51 |
| sean-k-mooney | as ub _base/backing_file _base/backing_file.info | 18:52 |
| sean-k-mooney | *as in | 18:52 |
| sean-k-mooney | if we cant modify the filename but know what it is we can comptue the relitive name | 18:53 |
| dansmith | the problem is that if we do that, we need to start copying it during migration | 18:53 |
| sean-k-mooney | only if the image is deleted form glance | 18:54 |
| dansmith | I also was hoping to make it a lot more obvious when we missed one | 18:54 |
| sean-k-mooney | otherwise it would be download on the dest node instead of copying | 18:54 |
| sean-k-mooney | but yes | 18:54 |
| dansmith | right, you can see that hole right in front.. upload a bad image, boot, delete it, then migrate to exploit :) | 18:54 |
| sean-k-mooney | am im just finsihing for today but ill sleep on it and take a look at the code tomrrow and see if anythign jump out at me | 18:54 |
| dansmith | ack | 18:55 |
| melwitt | dansmith: the fetch and disk image creation happen in Image.cache() which is called here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L11500 could you maybe return the file format from the fetch func and then pass it into create_image to tack on the extension to the name before writing it? | 18:55 |
| dansmith | melwitt: I think that's only some of the time | 18:55 |
| sean-k-mooney | the only other optiopn that jumps otu at me at the moment is to use the a singel file for all the format info or a db like pythons dbm or sqlite modules | 18:56 |
| dansmith | for ami,ari,aki we fetch direct I think | 18:56 |
| sean-k-mooney | which i assume you dont wnat to do at least right now | 18:56 |
| dansmith | and I thought there were also some of those backend drivers that raise and cause us to take the fetch direct path again, like on boot from snapshot or unshelve or something? | 18:56 |
| sean-k-mooney | i.e. you want this to be local to the compute node and obvious form simple inspection fo the filesytem without special tools | 18:56 |
| dansmith | sean-k-mooney: multiple files that get deleted with their parent seems cleanest if we're going that route | 18:57 |
| sean-k-mooney | and it also needs to work when /var/lib/nova is on nfs | 18:57 |
| dansmith | there is also the concern... yeah NFS | 18:57 |
| dansmith | multiple files make locking less reliable | 18:57 |
| dansmith | melwitt: I was initially going to return format from fetch_as_raw (and add the lookup/return to fetch) yeah | 18:59 |
| dansmith | however we'd need another move there in try_fetch_image_cache() which feels wrong, | 18:59 |
| dansmith | and also, there are cases where we don't go through that like the ami triplets I think | 18:59 |
| dansmith | and of course that copy_from_host, which is going to be a problem either way | 19:00 |
| melwitt | dansmith: move? the base image isn't created until Image.create_image (which is called from Image.cache) | 19:01 |
| dansmith | yeah, if fetch writes it to where it was asked and returns the format, then _try_fetch_image_cache() would need to move it to $path.$format | 19:02 |
| dansmith | unless we put that in image.cache, if that's what you mean? | 19:04 |
| dansmith | same difference though I think | 19:04 |
| melwitt | dansmith: no.. I'm thinking of how fetch isn't called until in Image.create_image so I was thinking you could adjust the target name before writing the file | 19:05 |
| dansmith | either way we end up with a sequence of: 1. fetch image info, 2. forget the format and calculate the wrong filename, 3. fetch the image info again, 4. write to a different file | 19:05 |
| dansmith | right, but ^ | 19:05 |
| dansmith | which is doable, it's just pretty stupid.. | 19:05 |
| melwitt | I guess I'm not understanding how that would be necessary, like forget the format and all that | 19:06 |
| dansmith | we only have image_id here right? | 19:06 |
| melwitt | if the fetch func returns the format I mean | 19:07 |
| melwitt | *if you made fetch return the format | 19:07 |
| dansmith | ...which will be done by re-fetching the image info yeah? :) | 19:07 |
| melwitt | no, the first fetch | 19:07 |
| dansmith | wut | 19:08 |
| melwitt | like in Image.create_image, the prepare_template() function is the fetch function. I guess you would have to be able to adjust what's in the functools.partial though to do it, maybe that's something that is not possible? | 19:09 |
| dansmith | I'm a bit lost here, but while we were talking I see that the kernel and ramdisk go through raw.cache() as well which means the cache function itself might work for those too as you say | 19:11 |
| dansmith | but note that ephemeral and swap are created like that as well, so they'd all need to change so we get a stable format returned from their not-really-fetch-function-s | 19:11 |
| melwitt | that is true, all of the fetch funcs would need to be modified to return format | 19:12 |
| dansmith | also after this, | 19:13 |
| dansmith | wait | 19:13 |
| dansmith | I'm just trying to figure out if we need the filename anywhere else after we've made that call | 19:16 |
| dansmith | seems like we imply it below that but maybe we never use it | 19:17 |
| dansmith | just feels wrong to have one step change the filename we're going to use in the middle, because someone will come along and say "oh look I have filename here, I can do a thing" | 19:17 |
| dansmith | er, yeah, because _create_image() is called and then we go create the guest's xml which will assume the image(s) are named like instructed right? | 19:18 |
| melwitt | yeah.. error prone at best I guess. and maybe an actual problem when a request comes in for a cached image, I guess maybe you could still match it by fingerprint + glance reported disk_format and if found in cache, use what's in the cache | 19:19 |
| dansmith | we can't though, | 19:20 |
| melwitt | maybe.. have to think about it. you were only talking about adding extension to base images right? or are you meaning like all images | 19:20 |
| dansmith | because we need to know the image's disk_format, unless you want a THIRD ping to glance :) | 19:20 |
| dansmith | I think all images would be ideal, but I think the base images are the important case here | 19:21 |
| melwitt | oh, right. hm | 19:21 |
| melwitt | well, could you not assume the format of what you find in the cache? like you get a request, you calculate the fingerprint, look for the basename in the cache, if you find it you use the file with the extension on it | 19:22 |
| melwitt | as the format. without querying glance for it | 19:23 |
| dansmith | I mean, we can also just run our detection code on the images without the format every time.. the point is to try to harden this, not just layer on the guesses :D | 19:23 |
| melwitt | no, the detection ran the first time the base image was written. thats' when you added the extension | 19:24 |
| melwitt | but from then on, you don't need to look it up again | 19:24 |
| dansmith | and part of the strategy here, I think, is to make sure we don't lose track of what we've validated and so yeah, doing /images/$image.*[0] is better than we have, it still seems like a hack | 19:24 |
| melwitt | ok | 19:24 |
| dansmith | I understand what you're saying, I'd just rather it be better than that | 19:25 |
| melwitt | ack | 19:25 |
| dansmith | I really was hoping to avoid just cluttering the _base dir with .info files, but perhaps that's just going to be easier because of how obsessed we are with filenames throughout the layers | 19:26 |
| dansmith | I dunno, I'll have to think about it | 19:26 |
| dansmith | also makes an admin's job harder if the next time we have a thing, they have to go read all the info files looking for which one(s) are qcows, then using that list to do some remediation action | 19:27 |
| dansmith | like currently, we were unable to check and purge bad images from the cache if they're present and the operators need to do that | 19:27 |
| dansmith | that's just a UX thing and not critical of course, but...it'd be nicer | 19:27 |
| dansmith | I assume if we use .info files, we should dump json in there because as soon as we add this we'll need to store something else (honestly we should probably store image_id at least as well)( | 19:28 |
| melwitt | yeah I agree .info files would be json. you could even have a nested list for all the files in one .info! | 19:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!