Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-05-06
12:24:38 sean-k-mooney as in the have 46 hosts and booted about 520 instace at this point and they have 2 host with 237 and 247 instances
12:24:38 sean-k-mooney as in the have 46 hosts and booted about 520 instace at this point and they have 2 host with 237 and 247 instances
12:25:57 sean-k-mooney so having a pretty dumb weither that jsut spread or packed by instances would help them. im goign to get them to set host_subset_size=46 so its just a random choice for now
12:25:57 sean-k-mooney so having a pretty dumb weither that jsut spread or packed by instances would help them. im goign to get them to set host_subset_size=46 so its just a random choice for now
12:26:34 sean-k-mooney that will get the the even distibution they want but i think it coudl be useful
12:26:34 sean-k-mooney that will get the the even distibution they want but i think it coudl be useful
12:27:04 sean-k-mooney the current host weigher would be so that people that want resize to same host to not change host could expess that preference if they really wanted too by truning on that weither
12:27:04 sean-k-mooney the current host weigher would be so that people that want resize to same host to not change host could expess that preference if they really wanted too by truning on that weither
12:27:51 sean-k-mooney gibi: im going to proably right a mini spec for moveing some of the fitlers to placmenet native approch so i could also add this there too
12:27:51 sean-k-mooney gibi: im going to proably right a mini spec for moveing some of the fitlers to placmenet native approch so i could also add this there too
12:28:14 gibi hm, I think if allow_resize_to_same_host=False then we add the scheduler will ignore the current host
12:28:14 gibi hm, I think if allow_resize_to_same_host=False then we add the scheduler will ignore the current host
12:28:22 sean-k-mooney just make it a generic schduling enhancements spec.
12:28:22 sean-k-mooney just make it a generic schduling enhancements spec.
12:28:32 sean-k-mooney gibi: it will the host manager will remove it
12:28:32 gibi sean-k-mooney: that also works for me
12:28:32 sean-k-mooney gibi: it will the host manager will remove it
12:28:32 gibi sean-k-mooney: that also works for me
12:28:56 sean-k-mooney but if you set it to ture there is no prefernce for stayingon the same host or not staying on the same host
12:28:56 sean-k-mooney but if you set it to ture there is no prefernce for stayingon the same host or not staying on the same host
12:29:20 gibi ohh, I did not know that, then I see why you need the weigher
12:29:20 gibi ohh, I did not know that, then I see why you need the weigher
12:29:37 sean-k-mooney well need is a stong word but it might be nice ot have
12:29:37 sean-k-mooney well need is a stong word but it might be nice ot have
12:30:15 gibi yeah, I agree
12:30:15 gibi yeah, I agree
12:30:31 sean-k-mooney we ocationally get customer confused by that, its not that common but it happens
12:30:31 sean-k-mooney we ocationally get customer confused by that, its not that common but it happens
12:42:56 rmart04 Hello, having some IRC issues, hopefully this works!
12:42:56 rmart04 Hello, having some IRC issues, hopefully this works!
12:43:54 rmart04 I've noticed that in VM's on Stein / host-passthrough cpu mode and dedicated core pinning policy, that the L2 and L3 cache values for the CPU do not match the physical CPU. Is this expected? Any way to configure?
12:43:54 rmart04 I've noticed that in VM's on Stein / host-passthrough cpu mode and dedicated core pinning policy, that the L2 and L3 cache values for the CPU do not match the physical CPU. Is this expected? Any way to configure?
12:47:13 gibi belmoreira: thanks for the report https://bugs.launchpad.net/nova/+bug/1924123 it is an interesting finding. Unfortunately it is not easy to fix.
12:47:15 openstack Launchpad bug 1924123 in OpenStack Compute (nova) "If source compute node is overcommitted instances can't be migrated" [Medium,Triaged]
12:47:15 openstack Launchpad bug 1924123 in OpenStack Compute (nova) "If source compute node is overcommitted instances can't be migrated" [Medium,Triaged]
12:47:15 gibi belmoreira: thanks for the report https://bugs.launchpad.net/nova/+bug/1924123 it is an interesting finding. Unfortunately it is not easy to fix.
12:50:00 sean-k-mooney rmart04: yes
12:50:00 sean-k-mooney rmart04: yes
12:50:19 sean-k-mooney you can also configure passthough of the host cache info but we dont do that in nova today
12:50:19 sean-k-mooney you can also configure passthough of the host cache info but we dont do that in nova today
12:53:07 rmart04 Ah, ok so possible in Libvirt/KVM but not exposed to nova?
12:53:07 rmart04 Ah, ok so possible in Libvirt/KVM but not exposed to nova?
12:53:37 sean-k-mooney correct
12:53:37 sean-k-mooney correct
12:54:06 sean-k-mooney https://libvirt.org/formatdomain.html#cpu-model-and-topology
12:54:06 sean-k-mooney https://libvirt.org/formatdomain.html#cpu-model-and-topology
12:54:16 sean-k-mooney you can add <cache mode='passthrough'/>
12:54:16 sean-k-mooney you can add <cache mode='passthrough'/>
12:54:20 sean-k-mooney to the cpu element
12:54:20 sean-k-mooney to the cpu element
12:55:19 rmart04 Interesting, is there anyway to add config like this that will persist? Or is it a case of modifying the XML and rebooting the VM in nova and when its trashed, start again?
12:55:19 rmart04 Interesting, is there anyway to add config like this that will persist? Or is it a case of modifying the XML and rebooting the VM in nova and when its trashed, start again?
12:55:39 sean-k-mooney not without modifying the nova code to add it no
12:55:39 sean-k-mooney not without modifying the nova code to add it no
12:55:49 rmart04 OK
12:55:49 rmart04 OK
12:55:53 rmart04 thanks for the information!!
12:55:53 rmart04 thanks for the information!!
12:55:54 sean-k-mooney we regenerate teh xml every time we move the vm or reboot it
12:55:54 sean-k-mooney we regenerate teh xml every time we move the vm or reboot it
12:55:58 rmart04 spot on as always
12:55:58 rmart04 spot on as always
12:56:30 sean-k-mooney this is proably something we could add as a feature but its never really come up
12:56:30 sean-k-mooney this is proably something we could add as a feature but its never really come up
14:19:29 openstackgerrit Tobias Urdin proposed openstack/nova master: When Nova-Api runs behind the load balancer or Reverse proxy, Loadbalancer IP is getting logged in nova_api.log instead of end user source ip by RequestLog https://review.opendev.org/c/openstack/nova/+/786766
15:46:38 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: QoS minimum guaranteed packet rate https://review.opendev.org/c/openstack/nova-specs/+/785014
15:56:34 gibi nova meeting starts in 4 minutes in #openstack-meeting-3
15:56:34 gibi nova meeting starts in 4 minutes in #openstack-meeting-3
16:51:35 sean-k-mooney dansmith: artom how we are fixing this for them is having them change all the config value to lowercase to match what neturon is expecting. and then doing a db update of all the things
16:51:35 sean-k-mooney dansmith: artom how we are fixing this for them is having them change all the config value to lowercase to match what neturon is expecting. and then doing a db update of all the things
16:52:28 dansmith yeah, I like the hardening of course, but in the interim we have to provide them a way to migrate and fix, since we don't control rabbit
16:52:28 dansmith yeah, I like the hardening of course, but in the interim we have to provide them a way to migrate and fix, since we don't control rabbit
16:53:00 dansmith so either we say "don't change it once you've set it" (which seems reasonable to me) or we say we're going to change everybody, so get your homework done (also reasonable)
16:53:00 dansmith so either we say "don't change it once you've set it" (which seems reasonable to me) or we say we're going to change everybody, so get your homework done (also reasonable)
16:53:20 dansmith if neutron is making some change that is going to require consistency then presumably the latter is the only option
16:53:20 dansmith if neutron is making some change that is going to require consistency then presumably the latter is the only option
16:59:48 bauzas I don't have a particular opinion on how we should fix those RPC issues, but I'm frightened by us trying to change the queue names
16:59:48 bauzas I don't have a particular opinion on how we should fix those RPC issues, but I'm frightened by us trying to change the queue names
17:00:04 bauzas as it's a impactful and visible change
17:00:04 bauzas as it's a impactful and visible change
17:01:06 bauzas anyhow, time to stop
17:01:06 bauzas anyhow, time to stop
17:01:26 artom My brain has mostly checked out at this point (I know, it's only 13:00 here), and I need to run errands anyways
17:01:26 artom My brain has mostly checked out at this point (I know, it's only 13:00 here), and I need to run errands anyways
17:01:34 artom I'll post a spec... I want to say next week?
17:01:34 artom I'll post a spec... I want to say next week?
17:03:04 sean-k-mooney well we can have this just be a workaround config option and never enable it by default
17:03:04 sean-k-mooney well we can have this just be a workaround config option and never enable it by default
17:12:08 openstackgerrit Elod Illes proposed openstack/placement master: Add periodic-stable-jobs template https://review.opendev.org/c/openstack/placement/+/775384
17:12:08 openstackgerrit Elod Illes proposed openstack/placement master: Add periodic-stable-jobs template https://review.opendev.org/c/openstack/placement/+/775384
17:15:25 dansmith sean-k-mooney: artom: We could probably lower() the hostname on service.create() and not service.update() in the short term
17:15:25 dansmith sean-k-mooney: artom: We could probably lower() the hostname on service.create() and not service.update() in the short term
17:15:43 dansmith that won't fix the cell mapping issue, but sounds like that's not the primary concern (or the biggest impact)
17:15:43 dansmith that won't fix the cell mapping issue, but sounds like that's not the primary concern (or the biggest impact)
17:18:41 artom So what's the call mapping issue again?
17:18:41 artom So what's the call mapping issue again?
17:21:15 sean-k-mooney dansmith: am maybe. that word normalise any new service yes
17:21:15 sean-k-mooney dansmith: am maybe. that word normalise any new service yes
17:21:39 dansmith sean-k-mooney: we could do the same for cell mappings actually
17:21:39 dansmith sean-k-mooney: we could do the same for cell mappings actually

Earlier   Later