| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-07-22 | |||
| 19:02:16 | 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:04:06 | dansmith | unless we put that in image.cache, if that's what you mean? | |
| 19:04:12 | dansmith | same difference though I think | |
| 19:05:01 | 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:10 | 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:26 | dansmith | right, but ^ | |
| 19:05:40 | dansmith | which is doable, it's just pretty stupid.. | |
| 19:06:32 | melwitt | I guess I'm not understanding how that would be necessary, like forget the format and all that | |
| 19:06:51 | dansmith | we only have image_id here right? | |
| 19:07:21 | melwitt | if the fetch func returns the format I mean | |
| 19:07:34 | melwitt | *if you made fetch return the format | |
| 19:07:49 | dansmith | ...which will be done by re-fetching the image info yeah? :) | |
| 19:07:57 | melwitt | no, the first fetch | |
| 19:08:08 | dansmith | wut | |
| 19:09:51 | 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:11:08 | 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:51 | 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:12:48 | melwitt | that is true, all of the fetch funcs would need to be modified to return format | |
| 19:13:33 | dansmith | also after this, | |
| 19:13:55 | dansmith | wait | |
| 19:16:39 | dansmith | I'm just trying to figure out if we need the filename anywhere else after we've made that call | |
| 19:17:05 | dansmith | seems like we imply it below that but maybe we never use it | |
| 19:17:36 | 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:18:56 | 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:19:44 | 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:20:37 | dansmith | we can't though, | |
| 19:20:41 | 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:55 | dansmith | because we need to know the image's disk_format, unless you want a THIRD ping to glance :) | |
| 19:21:19 | dansmith | I think all images would be ideal, but I think the base images are the important case here | |
| 19:21:24 | melwitt | oh, right. hm | |
| 19:22:30 | 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:23:05 | melwitt | as the format. without querying glance for it | |
| 19:23:49 | 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:24:23 | melwitt | no, the detection ran the first time the base image was written. thats' when you added the extension | |
| 19:24:33 | melwitt | but from then on, you don't need to look it up again | |
| 19:24:33 | 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:49 | melwitt | ok | |
| 19:25:04 | dansmith | I understand what you're saying, I'd just rather it be better than that | |
| 19:25:13 | melwitt | ack | |
| 19:26:05 | 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:18 | dansmith | I dunno, I'll have to think about it | |
| 19:27:10 | 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:37 | 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:50 | dansmith | that's just a UX thing and not critical of course, but...it'd be nicer | |
| 19:28:25 | 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:33:45 | melwitt | yeah I agree .info files would be json. you could even have a nested list for all the files in one .info! | |
| #openstack-nova - 2024-07-23 | |||
| 07:29:40 | opendevreview | Alexander Hild proposed openstack/nova master: feat: Include "vm uuid" in baseBoard asset tag in libvirt domain xml https://review.opendev.org/c/openstack/nova/+/924697 | |
| 07:31:56 | opendevreview | Alexander Hild proposed openstack/nova master: feat: Include "vm uuid" in baseBoard asset tag in libvirt domain xml https://review.opendev.org/c/openstack/nova/+/924697 | |
| 08:06:18 | mikal | sean-k-mooney: are you around? I think https://review.opendev.org/c/openstack/nova/+/922544 is ready for review but I have questions about if there needs to be a tempest test for it. | |
| 08:39:36 | sean-k-mooney | mikal: im not sure how you would tempet test that spice is secure. we recently tired to do that for vnc and vcrypt and we could not come up with a reasonable way ot do that just with a tcp connection becuase vnc uses tls to encypt the vnc packate payload not the entire tcp packet payload | |
| 08:40:53 | sean-k-mooney | so you can just connect without implementing the nvc protocal at least enought to negoicate the vencrypt session | |
| 08:41:43 | sean-k-mooney | unless there is a simple way to asssert that spice is using a secure connection without implemeting a portion of the spice protocoal i think unit and perhaps functional tests are enough | |
| 08:43:14 | sean-k-mooney | mikal: it might be worth considerign extending the libvirt funcitonal tests to be able to test some of the spice direct support but im not sure where in the series it makes sense to do that | |
| 09:20:30 | mikal | sean-k-mooney: so, it depends on if tempest can carry additional software. Kerbside does have a simple client which can parse enough of the protocol to know if its been redirected to a secure connection or not. | |
| 09:21:48 | mikal | sean-k-mooney: but then we'd have to carry extra code in tempest for that. https://github.com/shakenfist/kerbside/blob/develop/kerbside/spiceprotocol/__init__.py#L102 is approximate the right code. | |
| 09:29:42 | mikal | sean-k-mooney: also, should I move this spec from the "to be determined" bit of the dalmation etherpad to the "needs review" bit, or is that someone else's job? | |
| 09:30:47 | sean-k-mooney | mikal: tempest is generally not allowed to have depencies on external tools unless you are writing your own plugin | |
| 09:31:19 | sean-k-mooney | there are some things like ssh ectra but for the most part we try to keep core tempest as depency free as is reasonable | |
| 09:31:25 | mikal | sean-k-mooney: yeah, that's going to make any meaningful testing pretty hard to do. | |
| 09:31:53 | sean-k-mooney | mikal: again it would be totally fine to depend on kerbside in a kerbside tempest plugin | |
| 09:32:37 | mikal | sean-k-mooney: I'm happy enough to take a swing at writing such a plugin, but I'd like to see some more traction on the patch series and implement more of the changes requested (extra specs, new API flow) before pivoting to that. | |
| 09:33:02 | sean-k-mooney | and that can be in the kerbside repo or in a seperate one. if we want to do real end ot end testing i would suggest creating both a devstack adn tempest plugin which we can enable in a upstream job in the future | |
| 09:33:40 | sean-k-mooney | ya i personally woudl love to see end ot end testing but im ok with it happenign after the feature is completed | |
| 09:33:45 | mikal | I'd need someone to explain more to me what a tempest plugin in a separate repo gains as compared to just doing end to end CI with github actions in the kerbside project. I've never done much with tempest. | |
| 09:33:53 | sean-k-mooney | i think unit and functional tests woudl be enouch for now | |
| 09:34:07 | mikal | Well, I'm a bit worried about only having like three or four weeks to get all this landed at the moment. | |
| 09:34:22 | sean-k-mooney | yep understandable | |
| 09:34:30 | mikal | The patches have unit tests already (except for the new bits). | |
| 09:35:06 | mikal | I'm not particularly asking for special treatment, but there is only so much time before the deadline and I don't see a lot of value in writing lots of tempest stuff before the actual code is complete. | |
| 09:45:24 | mikal | sean-k-mooney: so should I move the heading in the etherpad? | |
| 10:00:04 | sean-k-mooney | sorry which etherpad? | |
| 10:00:31 | sean-k-mooney | mikal: was distracted downstream | |
| 10:31:14 | mikal | sean-k-mooney: no worries. The dalmatian etherpad (https://etherpad.opendev.org/p/nova-dalmatian-status) lists the SPICE stuff under "to be determined" not "needs code review". Should I just change that, or is it done by a designated person? | |
| 10:40:18 | sean-k-mooney | mikal: oh ya you can move it to needs core review since its approved and you have code not in WIP state | |
| 10:52:45 | mikal | sean-k-mooney: thanks done. I'm hesitant to un-WIP the next few patches because I'll have to redo CI on them, but I guess I'll do that too. | |
| 10:54:20 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add config option to require secure SPICE. https://review.opendev.org/c/openstack/nova/+/922544 | |
| 10:54:20 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow concurrent access to SPICE consoles. https://review.opendev.org/c/openstack/nova/+/922546 | |
| 10:54:21 | opendevreview | Michael Still proposed openstack/nova master: WIP: libvirt: Add guest devices to support SPICE USB. https://review.opendev.org/c/openstack/nova/+/922547 | |
| 10:54:21 | opendevreview | Michael Still proposed openstack/nova master: WIP: libvirt: Optionally enable SPICE debug logging. https://review.opendev.org/c/openstack/nova/+/922548 | |
| 10:54:22 | opendevreview | Michael Still proposed openstack/nova master: WIP: libvirt: Optionally support sound when using SPICE. https://review.opendev.org/c/openstack/nova/+/922549 | |
| 10:58:51 | opendevreview | Alexander Hild proposed openstack/nova master: feat: Include "vm uuid" in baseBoard asset tag in libvirt domain xml https://review.opendev.org/c/openstack/nova/+/924717 | |
| 11:02:21 | 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 | |
| 11:05:21 | opendevreview | Alexander Hild proposed openstack/nova master: feat: Include "vm uuid" in baseBoard asset tag in libvirt xml https://review.opendev.org/c/openstack/nova/+/924720 | |
| 11:06:07 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Fix typo https://review.opendev.org/c/openstack/nova/+/924722 | |
| 11:08:32 | opendevreview | Alexander Hild proposed openstack/nova master: feat: "vm uuid" in baseBoard asset tag https://review.opendev.org/c/openstack/nova/+/924723 | |
| 11:10:42 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for port interface APIs https://review.opendev.org/c/openstack/nova/+/924589 | |
| 11:11:14 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for availability zone APIs https://review.opendev.org/c/openstack/nova/+/924590 | |
| 11:12:01 | 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 | |
| 11:12:09 | 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 | |
| 11:12:15 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for flavor access API https://review.opendev.org/c/openstack/nova/+/924593 | |
| 11:12:20 | 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 | |
| 11:12:24 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for flavors APIs https://review.opendev.org/c/openstack/nova/+/924595 | |
| 11:12:30 | 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 | |
| 11:12:36 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Add contributor docs for response body validation https://review.opendev.org/c/openstack/nova/+/924597 | |
| 13:03:06 | elodilles_ooo | bauzas_: fyi, i'm off this week, so i won't participate on today's meeting | |
| 13:04:23 | bauzas_ | elodilles_ooo: ack thanks | |
| 13:04:35 | bauzas_ | have a good rest | |
| 13:13:14 | sean-k-mooney | elodilles_ooo: in that case please ignore irc and email until your pto is over :) you deserve a break | |
| 13:14:36 | opendevreview | Julien Le Jeune proposed openstack/nova master: Fix test_vmdk_bad_descriptor_mem_limit and test_vmdk_bad_descriptor_mem_limit_stream_optimized https://review.opendev.org/c/openstack/nova/+/924148 | |
| 14:01:07 | opendevreview | sean mooney proposed openstack/nova master: Change force_format strategy to catch mismatches https://review.opendev.org/c/openstack/nova/+/924731 | |