| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-08 | |||
| 09:08:28 | mikal | bauzas: I'm not sure if this was clear or not, so just in case. While I appreciate a courtesy ping before you discuss spice-direct, I kind of also need it to be at the start of the day with warning the day before so I can rearrange my sleep schedule for the day. | |
| 09:08:45 | bauzas | mikal: sure, I'm currently working on a planning :) | |
| 09:08:53 | mikal | bauzas: yeah cool, no rush. | |
| 09:09:00 | bauzas | maybe Friday would work for you ? | |
| 09:09:30 | mikal | bauzas: I'd also really like to just focus on the "do we want this at all" bit first, instead of implementation specifics. We can rat hole on those later if we get past the "do we even want this" bit. | |
| 09:09:37 | mikal | bauzas: let me check ye olde calendar... | |
| 09:10:59 | mikal | bauzas: oh actually, Friday (EU time) works well for me because that's Friday night my time and I can just sleep in on Saturday. So yeah that sounds good to me. | |
| 09:12:19 | bauzas | mikal: ok, so I'll try to discuss your topic around 1300UTC | |
| 09:12:47 | mikal | bauzas: cool. Want me to put it on the topic list for that day in the etherpad? | |
| 09:13:17 | bauzas | mikal: I already did it :) | |
| 09:14:15 | mikal | bauzas: "(fwiesel): POST /servers/{server_id}/remote-consoles is "leaky"" sounds a bit overlappy with me too, isn't that also talking about console types which might want to return connection details other than a URL? Maybe that should be a Friday session too then? | |
| 09:14:58 | bauzas | mikal: ahah, good point, I could move it on Friday if fwiesel is okay | |
| 09:15:40 | bauzas | yeah, it looks okay for fwiesel, so I'll move it | |
| 09:15:52 | mikal | bauzas: is the "userdata" one this spec? https://review.opendev.org/c/openstack/nova-specs/+/863884 | |
| 09:16:17 | mikal | bauzas: because I have _opinions_ about that one. | |
| 09:16:52 | bauzas | yup | |
| 09:17:19 | mikal | bauzas: because "nova metadata optimization" is _not_ that spec as best as I can see. | |
| 09:18:30 | bauzas | mikal: we'll discuss this on Friday too | |
| 09:20:03 | bauzas | FWIW, I'll start to review the specs today | |
| 09:24:34 | mikal | bauzas: yeah cool, I did not intend to create pressure. | |
| 09:25:37 | mikal | I wonder if it still makes sense to provide ec2 style metadata at all? We don't have an ec2 API any more right? And its not like we're new and anyone is running a cloud-init which doesn't know about openstack any more... | |
| 09:29:22 | bauzas | mikal: no we removed the ec2 API indeed (like in 6 years ago IIRC) | |
| 09:30:11 | bauzas | yeah, checked, this was in mitaka | |
| 09:31:06 | bauzas | https://docs.openstack.org/releasenotes/nova/mitaka.html#release-notes-13-0-0-stable-mitaka-prelude | |
| 09:32:06 | bauzas | then the ec2 api was in https://opendev.org/openstack/ec2-api/ | |
| 09:32:34 | mikal | IIRC we spun it off into another project that then withered on the vine? | |
| 09:32:59 | mikal | I think the days of having to pretend to be ec2 to our users are well and truely over. | |
| 09:34:17 | bauzas | well, because most of folks already know about direct OpenStack APIs | |
| 09:34:55 | mikal | Yeah, and back in the day lots of tooling (cloud-init etc) didn't know about us, so we pretended to be ec2. Eucalyptus did the same. | |
| 09:35:44 | bauzas | mikal: we have a related topic https://etherpad.opendev.org/p/nova-dalmatian-ptg#L303 | |
| 09:36:47 | bauzas | our API documentations are fine, but some folks want to automatically get our documents by their own scripts | |
| 09:38:20 | mikal | Hmmm, do the current JSON schemas document all of the HTTP response codes which might be returned by an API call? | |
| 09:39:57 | mikal | https://openapi.shakenfist.com/#/instances/get_instances__instance_ref_ for example is some output from a Swagger / OpenAPI automation tool, and having the HTTP response codes there is quite important. I think OpenAPI is a good idea. For a lot of languages it means people can auto-generate their own API clients for example. | |
| 09:41:50 | bauzas | sorry I need to go off for an appointment | |
| 09:52:44 | mikal | No worries. | |
| 10:04:26 | frickler | fyi openapi is also a topic in the tc session on friday, IIUC mainly a discussion about gtema's codegenerator project | |
| 10:04:46 | frickler | see https://etherpad.opendev.org/p/apr2024-ptg-os-tc#L37 | |
| 10:05:12 | frickler | (note the scheduling might not be final yet) | |
| 10:38:33 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix case-sensitivity for metadata keys https://review.opendev.org/c/openstack/nova/+/873901 | |
| 11:57:13 | bauzas | wow, our PTG agenda is now pretty packed | |
| 11:57:20 | bauzas | I'll provide an email | |
| 13:01:55 | sean-k-mooney | mikal: o/ | |
| 13:03:39 | sean-k-mooney | mikal: its been a long time since i saw you around these parts how are you? | |
| 14:04:40 | bauzas | folks, the QA team will discuss about grenade skip-level jobs around 14300UTC (ie. in 30 mins by now) https://etherpad.opendev.org/p/apr2024-ptg-qa#L43 | |
| 14:04:49 | bauzas | you may be interested in joining it ^ | |
| 14:21:58 | opendevreview | ribaudr proposed openstack/nova master: Fix: migration configuration with cpu_shared_set (object part) https://review.opendev.org/c/openstack/nova/+/903706 | |
| 14:21:58 | opendevreview | ribaudr proposed openstack/nova master: Fix: migration configuration with cpu_shared_set (libvirt part) https://review.opendev.org/c/openstack/nova/+/915139 | |
| 14:21:59 | opendevreview | ribaudr proposed openstack/nova master: Test live migration between hosts with differnet cpu_shared_sets https://review.opendev.org/c/openstack/nova/+/913744 | |
| 14:38:33 | sean-k-mooney | bauzas: gibi can ye review this logging patch https://review.opendev.org/c/openstack/nova/+/898057 i want to merge that to help debugging some numa issues | |
| 14:54:44 | bauzas | sean-k-mooney: -1 for a missing test coverage | |
| 14:54:50 | bauzas | but I like your approach | |
| 14:55:26 | sean-k-mooney | ok ill figure out how tot test it | |
| 14:55:37 | sean-k-mooney | if your happy with the approch then that is easy to adresss | |
| 14:56:03 | bauzas | sean-k-mooney: oh, that's simple to test, sec | |
| 14:57:15 | bauzas | https://github.com/openstack/nova/blob/master/nova/tests/unit/objects/test_objects.py | |
| 14:57:47 | bauzas | here, you can add another fake object that would inherit from your JSONPrintableObjectMixin mixin | |
| 14:57:55 | sean-k-mooney | yep | |
| 14:58:00 | sean-k-mooney | sounds good | |
| 14:58:14 | bauzas | or just amend MyObj | |
| 14:58:31 | sean-k-mooney | ill proably inherit form it | |
| 14:58:31 | bauzas | and add the two test methods for checking the output | |
| 14:58:39 | sean-k-mooney | or duplicate it | |
| 14:58:42 | bauzas | in _BaseTest | |
| 14:58:45 | bauzas | as you want | |
| 14:58:50 | sean-k-mooney | but ill ready over it and see what is simplest | |
| 14:59:05 | bauzas | yup, I just wanted to make sure we double check that we get a dump | |
| 14:59:21 | sean-k-mooney | sure thats tottally valid to ask for. | |
| 14:59:43 | sean-k-mooney | i didnt add it becuase i tought it was trivial enough not to need ti but im tottaly fine with adding tests | |
| 14:59:48 | bauzas | I'm thinking about the RPC compatibility | |
| 14:59:58 | bauzas | I think it will work | |
| 15:00:22 | bauzas | the primitive won't have the mixin in it, so an old compute would just rehydrate the object without the mixin | |
| 15:01:08 | sean-k-mooney | rpc is fine | |
| 15:01:27 | sean-k-mooney | on unupgraded code we will just fall back to the default __str__ impl | |
| 15:01:44 | sean-k-mooney | we are not going to depend on this out side of logs | |
| 15:01:57 | sean-k-mooney | so old code will just log as it does now | |
| 15:02:17 | sean-k-mooney | new code will log the .obj_to_primitive() json dump | |
| 15:02:44 | dansmith | So fwiw, I'd rather us not always dump these as json | |
| 15:03:15 | sean-k-mooney | well i applied them to some of the objects where its needed but perhapse i could make it configuable based on the log level | |
| 15:03:21 | dansmith | it's much harder to read and it's not exactly the same format as we expect in python (null instead of None, no list/set distinction, etc) | |
| 15:03:22 | sean-k-mooney | i.e. only do that if debug | |
| 15:03:38 | dansmith | why not just dump the primitive in specific places if and when you want it? | |
| 15:03:47 | sean-k-mooney | i want it everywhere we log this | |
| 15:03:52 | dansmith | what's the extra thing you're getting out of this that we don't get with the inbuilt dump? | |
| 15:04:08 | sean-k-mooney | yes | |
| 15:04:20 | sean-k-mooney | we just get something<?> or stuff like that | |
| 15:04:29 | sean-k-mooney | for pci request and many of the numa related info | |
| 15:04:52 | dansmith | you get that when a field is unset I think is that what you mean? | |
| 15:06:27 | bauzas | I often used .dumps() for objects and ya got a question mark for unset fields IIRC | |
| 15:06:44 | bauzas | but we can test this quickly | |
| 15:06:45 | sean-k-mooney | it not jsut <?> | |
| 15:06:47 | dansmith | right, which you won't even see in the json dump I think | |
| 15:06:51 | sean-k-mooney | wwe also had requests=[InstancePCIRequest,InstancePCIRequest]) | |
| 15:07:06 | sean-k-mooney | so it does not recursivly print the nested objects | |
| 15:08:08 | dansmith | yeah, which it could do... | |
| 15:08:48 | sean-k-mooney | so i guess i wasnt expecting much push back as this to me is a significant readbility gain | |
| 15:09:17 | sean-k-mooney | we could adress it other wasy but this to mean was a clean an consitent way to make it more readable and support debuggin form logs | |
| 15:09:28 | sean-k-mooney | for the specific objects where the current logging is lacking | |
| 15:09:28 | dansmith | it's a significant readability regression to me :) | |
| 15:11:38 | sean-k-mooney | i guess you would prefer if i modified the list object ot print recurrsivly instead | |
| 15:11:43 | sean-k-mooney | keeping the same format | |