| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-15 | |||
| 10:49:33 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for remaining server action APIs https://review.opendev.org/c/openstack/nova/+/915743 | |
| 10:49:35 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Migrate to JSON Schema Draft 2020-12 https://review.opendev.org/c/openstack/nova/+/915845 | |
| 10:49:35 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Ensure API schemas are valid https://review.opendev.org/c/openstack/nova/+/915844 | |
| 10:53:11 | sean-k-mooney | dougszu: you can back port that it looks apporprate | |
| 11:03:58 | dougszu | thanks sean-k-mooney | |
| 11:25:39 | opendevreview | sean mooney proposed openstack/nova master: fix sphinx-lint errors in docs and add ci https://review.opendev.org/c/openstack/nova/+/897089 | |
| 11:25:40 | opendevreview | sean mooney proposed openstack/nova master: ignore sphinx-lint series in git blame https://review.opendev.org/c/openstack/nova/+/897218 | |
| 12:25:51 | sean-k-mooney | melwitt: stephenfin can ye reappove the sphinx-lint seriese, stephen i adressed your nits in the latest verion too but let me know if i missed anything | |
| 12:38:23 | fwiesel | bauzas: I've started with an etherpad for a Blueprint for the lazy metadata loading (https://etherpad.opendev.org/p/nova-lazy-metadata-loading) Should put that url in the blueprint registration? Or does it come later? | |
| 13:23:14 | bauzas | fwiesel: the etherpad looks a good start for me, no worries | |
| 14:25:05 | stephenfin | sean-k-mooney: done | |
| 15:35:50 | sean-k-mooney | fwiesel: lazy generation of the metadata can be problemtic just an fyi | |
| 15:36:12 | sean-k-mooney | fwiesel: cloud init will only retry the first request to the metadata endpoint | |
| 15:36:46 | sean-k-mooney | once the first request is sucuscessful it never retries any other request assuming all metadta is aviaable | |
| 15:37:10 | sean-k-mooney | which is why we generate it all and cache it in memcache | |
| 15:38:14 | sean-k-mooney | so if we allow lazy loading we would have to enforce some kind of stict timing aroudn how long that can take or it will cause vms to fail to get ssh keys ectra | |
| 15:38:25 | sean-k-mooney | and require the end user to reboot them or recreate them | |
| 15:39:13 | sean-k-mooney | fwiesel: the othger thing to kep in mind is i belivew we use the network info cache i dont think we query neturon for any of the metadata | |
| 15:40:35 | sean-k-mooney | in general im not sure that lazy loading the metadata will actully be a good thing | |
| 15:42:38 | sean-k-mooney | i would also argure that polling the metadata api is not an intended usecase | |
| 15:42:59 | sean-k-mooney | what we could do is provide a way for the client to invladiate the cache | |
| 15:43:15 | sean-k-mooney | i.e. by issuring a Delete to the root for the metadata api | |
| 15:43:24 | sean-k-mooney | and then that way the could know tey are not out os sync | |
| 16:55:03 | opendevreview | Dan Smith proposed openstack/nova master: Add method to determine "ancient" service version https://review.opendev.org/c/openstack/nova/+/915911 | |
| 16:55:04 | opendevreview | Dan Smith proposed openstack/nova master: Make compute auto-disable if too old https://review.opendev.org/c/openstack/nova/+/915913 | |
| 16:55:04 | opendevreview | Dan Smith proposed openstack/nova master: Add conductor API for service support check https://review.opendev.org/c/openstack/nova/+/915912 | |
| 20:09:44 | opendevreview | Amit Uniyal proposed openstack/nova master: DNM: test evacuation https://review.opendev.org/c/openstack/nova/+/915923 | |
| #openstack-nova - 2024-04-16 | |||
| 05:49:08 | opendevreview | Amit Uniyal proposed openstack/nova master: DNM: test evacuation https://review.opendev.org/c/openstack/nova/+/915923 | |
| 09:23:28 | opendevreview | Kien Nguyen proposed openstack/python-novaclient master: support get and list server's metadata https://review.opendev.org/c/openstack/python-novaclient/+/915977 | |
| 11:27:30 | opendevreview | Amit Uniyal proposed openstack/nova master: DNM: test evacuation https://review.opendev.org/c/openstack/nova/+/915923 | |
| 11:33:09 | sean-k-mooney | auniyal: ^ fyi when you create DNM patches like that its better to disable the jobs that you dont need to save ci resouces | |
| 13:50:28 | dansmith | gibi: I cc'd you but just in case it's under a mountain of other notification emails, I'm looking for pre-approval on this method of determining the trailing threshold: https://review.opendev.org/c/openstack/nova/+/915911/1 | |
| 13:50:33 | dansmith | from our version support discussion | |
| 13:51:00 | dansmith | just the algorithm for picking the version, and then I'll flesh out everything else | |
| 14:01:57 | auniyal | sean-k-mooney ack, but I am not sure how to disable jobs, | |
| 14:02:05 | auniyal | by doing -1 to workflow ? | |
| 14:03:00 | auniyal | its a depends-on patch, so I do not really need to run any job in nova-ci for this | |
| 14:05:30 | dansmith | auniyal: by commenting out or removing jobs from the .zuul | |
| 14:06:03 | auniyal | dansmith, ack, thanks | |
| 14:06:49 | auniyal | yeah, I knew workflow is stop stop merging, but thought may it also work for jobs | |
| 14:06:57 | gibi | dansmith: thanks for the ping, otherwise I would have missed the patch | |
| 14:06:57 | samcat116 | reason. I've also seen the error on vm creation, but much less common. Not sure if there's anything I can do to debug further. | |
| 14:06:57 | samcat116 | Hi all, I seem to be hitting the following issue pretty consistently on a 2023.2 deployment: https://bugs.launchpad.net/nova/+bug/1931707. Specifically when trying to delete a large number of instances with many ports attached to each at once. For instance on the last run we had computes with over 100 vms on a given compute node with 10 ports on each vm. Out of our deletion of about 100 vms, over 150 went into error due to this | |
| 14:08:31 | dansmith | gibi: no problem and no big rush, just wanted to at least get some agreement while things are still fresh | |
| 14:09:27 | auniyal | dansmith, its okay to comment whole file right ? | |
| 14:14:39 | dansmith | auniyal: probably not, and obviously not if you want to run *any* tests | |
| 14:14:53 | dansmith | auniyal: sean-k-mooney was likely suggesting you comment out all but the tests you want to run on your WIP | |
| 14:20:02 | auniyal | ack | |
| 14:20:50 | sean-k-mooney | dansmith: auniyal yes | |
| 14:21:46 | erlon | sean-k-mooney: hey, can you give a look on the RBAC change (https://review.opendev.org/c/openstack/nova/+/811521) again when you have a chance? | |
| 14:23:19 | erlon | I was trying to add some core reviewers to the list as well, but I don't know how to find them anymore. It use to be in the project groups, core-reviewers, but now there's a lot of groups. | |
| 14:28:15 | sean-k-mooney | sure i see you created a blue print for it | |
| 14:28:28 | sean-k-mooney | so we still need to approve that in the nova team meeting | |
| 14:28:45 | sean-k-mooney | i dont really have any objection to enabing this as a specless blueprint | |
| 14:33:44 | erlon | The other thing I was wondering, is the likelihood of this being backported. The fact that it has a blueprint, make it sounds like there's a feature which this is not, but might raise some eyebrows | |
| 14:42:28 | erlon | The next meeting will be only next week right? Do I need to add the top in the agenda? Or there's already a slot for review requests | |
| 14:42:40 | erlon | sean-k-mooney: ^ | |
| 14:46:46 | dansmith | erlon: sounds like a feature to me, FWIW | |
| 14:50:18 | kashyap | gibi: When you get a min, can you look at this (needs to reload some context, though): https://review.opendev.org/c/openstack/nova/+/899185 | |
| 14:51:14 | sean-k-mooney | dansmith: erlon yes this is a feature and not something that is upstrema backporable | |
| 15:31:15 | gibi | kashyap: I remember we discussed doing that change in the past but I don't know where it is stopped, what is the next step there?j | |
| 15:41:36 | kashyap | gibi: The next step is discussed in the bug you filed: https://bugs.launchpad.net/nova/+bug/2039803 | |
| 15:41:59 | bauzas | reminder : nova meeting here in ~20 mins | |
| 15:42:11 | kashyap | gibi: Our aim is ge this fixed with as less churn as possible | |
| 15:49:44 | gibi | kashyap: OK your comment https://bugs.launchpad.net/nova/+bug/2039803/comments/2 make sense | |
| 15:50:56 | kashyap | s/ge/to get/ | |
| 15:51:20 | kashyap | gibi: Okay, please also give a quick look at the draft patch. Tomm; not tonight, it requires to load up on the context | |
| 15:52:01 | sean-k-mooney | so why is this listed as a bug | |
| 15:52:09 | sean-k-mooney | to me this is a feature | |
| 15:52:31 | sean-k-mooney | its technial debth | |
| 15:52:41 | sean-k-mooney | but i dotn thinkw e woudl backport this right | |
| 15:53:35 | sean-k-mooney | i mean we shoudl not eb breakign live migration by calling the worng api | |
| 15:54:04 | sean-k-mooney | but im nnot sure how i feel about changign all those libvirt api methods in somethign we would backport | |
| 15:54:16 | sean-k-mooney | i would epect the test fallout to be non trivial | |
| 15:54:41 | sean-k-mooney | although i guess we coudl see what it looks like and make the deicsion about if this could be backported later | |
| 15:55:46 | kashyap | Yeah, we don't want to update all those methods. If you see the WIP patch, it's targetted as a bug fix | |
| 15:56:05 | sean-k-mooney | i saw all the red ci jobs | |
| 15:56:09 | kashyap | That comment is just written to show what we've already considered and eliminated. | |
| 15:56:10 | sean-k-mooney | i briefly skimmed it | |
| 15:56:53 | sean-k-mooney | the ci jobs logs all rotated so this need a rebase at a minium | |
| 15:57:14 | kashyap | (Just on the bug comment: we shouldn't update all those methods. And not all those methods listed there make sense in this context.) | |
| 15:57:24 | kashyap | Yeah, needs a rebase for sure. | |
| 15:58:50 | kashyap | Thank you for looking (even if it's skimming) | |
| 15:59:32 | sean-k-mooney | the change is basically s/host_cpu = self._host.get_capabilities().host.cpu/host_cpu = self._host.get_domain_capabilities().host.cpu/ | |
| 16:00:19 | sean-k-mooney | the side effect being that domain caps the new api also has awareness of what the qemu instance on the host can emulate ectra | |
| 16:00:36 | sean-k-mooney | so we will be useing the capablity of the cpu that woudl be presented to the guest | |
| 16:00:41 | sean-k-mooney | rather the hte host caps | |
| 16:00:47 | bauzas | (meeting now)à | |
| 16:00:53 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:53 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:53 | opendevmeet | Meeting started Tue Apr 16 16:00:53 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:53 | bauzas | #startmeeting nova | |
| 16:01:00 | bauzas | howdy folks | |
| 16:01:03 | dansmith | o/ | |
| 16:01:06 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:01:13 | elodilles | o/ | |
| 16:01:21 | auniyal | o/ | |
| 16:01:49 | sean-k-mooney | o/ | |
| 16:02:22 | bauzas | let's try to have a short meeting, I could have someone going to my home around 4.30pm | |
| 16:02:32 | bauzas | #topic Bugs (stuck/critical) | |