| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-08 | |||
| 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 | |
| 15:12:02 | sean-k-mooney | do you know if there is an atribute we would need to apply to do that | |
| 15:12:44 | dansmith | I mean, the reason it doesn't recurse now is just because the dump could end up being super massive and so the decision not to recurse was intentional | |
| 15:13:00 | dansmith | that was at a time where we had many fewer object types and less nesting I'm sure | |
| 15:13:10 | sean-k-mooney | but that often means i cant debug custoemr issues form the logs | |
| 15:13:11 | dansmith | but things like a list of instances would be a massive dump in the logs | |
| 15:13:25 | dansmith | sure, I know | |
| 15:13:33 | sean-k-mooney | i think we shoudl recuse for debug mode | |
| 15:13:40 | sean-k-mooney | but perhaps not for anythign else | |
| 15:13:42 | dansmith | I'm not saying don't make it recursive, I'm just saying it's pretty heavy | |
| 15:13:46 | sean-k-mooney | do you know if we have dont that before? | |
| 15:13:53 | dansmith | not that I know of | |
| 15:14:07 | sean-k-mooney | ok ill pause the patch there then and see if that is possibel | |
| 15:14:15 | sean-k-mooney | if thats an approch you and bauzas prefer | |
| 15:14:39 | sean-k-mooney | dansmith: for context i have othen patch in this dumping in the past | |
| 15:14:49 | bauzas | I'm just testing what we get | |