Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-04-15
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: Add conductor API for service support check https://review.opendev.org/c/openstack/nova/+/915912
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
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 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: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 gibi dansmith: thanks for the ping, otherwise I would have missed the patch
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 bauzas #startmeeting nova
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 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:53 opendevmeet The meeting name has been set to '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)
16:02:35 bauzas #info No Critical bug
16:02:39 bauzas #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 74 new untriaged bugs (+7 since the last meeting)
16:02:58 bauzas I definitely need to do what we agreed on the PTG :)
16:03:04 bauzas #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:06 bauzas so,
16:03:09 bauzas #info bug baton is ?
16:03:16 elodilles o/
16:03:18 bauzas anyone wanting to take the baton ?
16:03:22 elodilles i can volunteer
16:03:34 bauzas cool thanks
16:03:36 bauzas #undo
16:03:36 opendevmeet Removing item from minutes: #info bug baton is ?

Earlier   Later