| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-05 | |||
| 00:28:54 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: libvirt: start tracking NUMACell.socket for hosts https://review.opendev.org/c/openstack/nova/+/766816 | |
| 00:28:55 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Add `socket` PCI NUMA affinity policy request prefilter https://review.opendev.org/c/openstack/nova/+/772749 | |
| 00:28:55 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: extra specs/image pros: add `socket` PCI NUMA affinity https://review.opendev.org/c/openstack/nova/+/772748 | |
| 00:28:56 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: pci: implement the `socket` NUMA affinity policy https://review.opendev.org/c/openstack/nova/+/772779 | |
| 00:28:56 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Track host NUMA topology in PCI manager https://review.opendev.org/c/openstack/nova/+/774149 | |
| 01:38:05 | openstackgerrit | Merged openstack/nova master: hyperv: Configures chassis asset tags for VMs. https://review.opendev.org/c/openstack/nova/+/752723 | |
| 01:59:04 | openstack | bug 1907522 in OpenStack Compute (nova) ussuri "test_*_with_qos_min_bw_allocation fails in the nova-multi-cell job with: nova.exception.MigrationPreCheckError: Migration pre-check error: Failed to create port bindings for host |
|
| 01:59:04 | openstackgerrit | Merged openstack/nova stable/ussuri: Reproduce bug 1907522 in functional test https://review.opendev.org/c/openstack/nova/+/773930 | |
| 04:13:07 | openstackgerrit | Merged openstack/nova master: Fix ForbiddenWithAccelerators to HTTPForbidden for shelve API https://review.opendev.org/c/openstack/nova/+/770007 | |
| 04:14:15 | openstackgerrit | Merged openstack/nova master: pci: Improve testing of 'nova.pci.request' module https://review.opendev.org/c/openstack/nova/+/764446 | |
| 05:42:19 | openstackgerrit | Merged openstack/nova stable/ussuri: Set instance host and drop migration under lock https://review.opendev.org/c/openstack/nova/+/770769 | |
| 06:01:07 | openstackgerrit | Khomesh Thakre proposed openstack/nova master: api: Reject requests to reset the state of SHELVE_OFFLOADED servers https://review.opendev.org/c/openstack/nova/+/773238 | |
| 06:40:08 | openstackgerrit | Wenping Song proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 06:40:09 | openstackgerrit | Wenping Song proposed openstack/nova master: Replace tenants* with projects* of policies https://review.opendev.org/c/openstack/nova/+/765315 | |
| 06:40:10 | openstackgerrit | Wenping Song proposed openstack/nova master: Replace os-simple-tenant-usage with os-simple-project-usage https://review.opendev.org/c/openstack/nova/+/768852 | |
| 08:18:07 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |
| 08:23:32 | alexe9191 | Good day everyone, is there an issue anyone aware of in OpenStack rocky in the scheduler? it seems to think that some of my hosts belong to the nova AZ, while nova-api is reporting that they are in a different zone. | |
| 08:49:42 | alexe9191 | somehow removing one host of the aggregate and re-adding it fixed the problem for the whole aggregate. I think there is some kind of a update all mechanism when adding/removing hosts to aggregates. | |
| 08:54:25 | bauzas | alexe9191: have you named an aggregate with a 'nova' name for its AZ ? | |
| 08:55:15 | alexe9191 | no | |
| 08:55:20 | alexe9191 | that's the default one | |
| 08:55:25 | bauzas | I mean, is there an aggregate having a metadata value for AZ being "nova" ? | |
| 08:55:29 | bauzas | k | |
| 08:55:32 | alexe9191 | nop | |
| 08:55:36 | bauzas | https://docs.openstack.org/nova/stein/user/aggregates.html#availability-zones-azs | |
| 08:55:56 | alexe9191 | could be that at some certain point someone did something and just renamed it later without updating the aggregates..,, | |
| 08:56:17 | bauzas | hmmm | |
| 08:56:31 | bauzas | not sure, since the API verifies whether there are instances | |
| 08:56:47 | alexe9191 | the api was reporting that the host is in the correct az | |
| 08:56:54 | alexe9191 | nova service-list | grep host | |
| 08:56:58 | alexe9191 | showed the correct values | |
| 08:56:59 | bauzas | are you sure the API is correct ? | |
| 08:57:03 | bauzas | ack ok | |
| 08:57:05 | alexe9191 | the scheduler was not though... | |
| 08:57:16 | alexe9191 | also in the DB the mapping between the host and it's aggregate was also correct | |
| 08:57:27 | bauzas | alexe9191: how do you know the scheduler was wrong, then ? | |
| 08:57:42 | alexe9191 | the scheduler was saying that host X is in AZ: nova | |
| 08:57:46 | alexe9191 | which is wrong | |
| 08:57:49 | alexe9191 | cause it's not | |
| 08:57:51 | bauzas | when ? | |
| 08:58:06 | bauzas | the AZFilter, you mean ? | |
| 08:58:09 | alexe9191 | when trying to build a machine, the AZfilter | |
| 08:58:10 | alexe9191 | yes | |
| 08:58:47 | alexe9191 | metadata = utils.aggregate_metadata_get_by_host( | |
| 08:58:48 | alexe9191 | if 'availability_zone' in metadata: | |
| 08:58:48 | alexe9191 | host_state, key='availability_zone') | |
| 08:58:49 | alexe9191 | host_az = metadata['availability_zone'] | |
| 08:58:49 | alexe9191 | hosts_passes = availability_zone in metadata['availability_zone'] | |
| 08:58:50 | alexe9191 | hosts_passes = availability_zone == CONF.default_availability_zone | |
| 08:58:50 | alexe9191 | else: | |
| 08:58:51 | alexe9191 | if not hosts_passes: | |
| 08:58:51 | alexe9191 | host_az = CONF.default_availability_zone | |
| 08:58:52 | alexe9191 | "%(host_state)s has AZs: %(host_az)s", | |
| 08:58:52 | alexe9191 | LOG.debug("Availability Zone '%(az)s' requested. " | |
| 08:58:53 | alexe9191 | 'az': availability_zone, | |
| 08:58:53 | alexe9191 | {'host_state': host_state, | |
| 08:58:54 | alexe9191 | 'host_az': host_az}) | |
| 08:58:59 | alexe9191 | ow sorry, I should've used spwan my apologies | |
| 08:59:19 | bauzas | by Rocky, we now have a placement prefilter for AZs | |
| 08:59:31 | alexe9191 | Indeed:) We are gonna switch to that | |
| 08:59:32 | bauzas | you could use it | |
| 08:59:41 | bauzas | and verify whether it works | |
| 08:59:59 | alexe9191 | well not it does, i removed ONE host from the aggregate and re-added it | |
| 09:00:02 | bauzas | that being said, I don't know why the filter wouldn't work | |
| 09:00:17 | alexe9191 | and that solved the problem for all the hosts being wrongly reported in nova AZ | |
| 09:07:59 | openstackgerrit | Wenping Song proposed openstack/nova master: Replace tenants* with projects* of policies https://review.opendev.org/c/openstack/nova/+/765315 | |
| 09:07:59 | openstackgerrit | Wenping Song proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 09:13:14 | brinzhang_ | gmann: I am updating the os-simple-project-usage patch https://review.opendev.org/c/openstack/nova/+/768852, could you please help to review why the test cannot request the 2.90 version after I register the router with a new class? | |
| 09:15:12 | brinzhang_ | gmann: the test case in https://review.opendev.org/c/openstack/nova/+/768852/9/nova/tests/unit/api/openstack/compute/test_simple_project_usage.py#681 | |
| 10:38:04 | openstackgerrit | Elod Illes proposed openstack/nova master: WIP: Tool to list launchpad bug status https://review.opendev.org/c/openstack/nova/+/774223 | |
| 10:42:09 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a routed networks scheduler pre-filter https://review.opendev.org/c/openstack/nova/+/749068 | |
| 10:42:44 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a routed networks scheduler pre-filter https://review.opendev.org/c/openstack/nova/+/749068 | |
| 10:42:47 | bauzas | gibi: sean-k-mooney: finally done ^ | |
| 11:10:51 | gibi | bauzas: ack, added to my queue | |
| 12:15:14 | sean-k-mooney | bauzas: nice ill review it today | |
| 13:41:35 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow disabling CPU flags via `cpu_model_extra_flags` https://review.opendev.org/c/openstack/nova/+/774240 | |
| 13:46:56 | kashyap | gibi (or anyone): --^ When you can, can you have a quick look of the above? I'm not sure if I quite got the parsing right there | |
| 14:15:35 | sean-k-mooney | kashyap: that is not something we can really do at this point in the cycle | |
| 14:15:56 | sean-k-mooney | kashyap: it requires a spec and we are well passed that point | |
| 14:17:20 | sean-k-mooney | kashyap: there was an outstandign debate around support +/- syntax partly due to parsing issues with hypenated flags that may exists | |
| 14:17:40 | sean-k-mooney | but there was also concern about haveing to config options | |
| 14:19:02 | sean-k-mooney | its a somewhat small feature which if gibi and other were open to allowing as a specless blueprint we could psersue but we need to resolve the config opention issue first | |
| 14:20:04 | sean-k-mooney | the parsing is relitivly simple to fix since we also have it comma sperated so we just need to d a starts with check | |
| 14:20:51 | sean-k-mooney | so we can go with the +/- sysntax if we want too but just wanted to raise that old issue and the procedual point that technicaly we should not be adding feature now | |
| 14:40:35 | kashyap | sean-k-mooney: Spec? WTF? | |
| 14:40:42 | kashyap | sean-k-mooney: Spec is *really* overkill | |
| 14:40:51 | kashyap | sean-k-mooney: I have an old blueprint; that more than suffices | |
| 14:40:59 | kashyap | https://blueprints.launchpad.net/nova/+spec/allow-disabling-cpu-flags | |
| 14:41:46 | kashyap | sean-k-mooney: Okay ... I was AFK, only now fully catching up. You do say "specless blueprint" | |
| 14:41:49 | kashyap | That's good | |
| 14:41:53 | kashyap | sean-k-mooney: The BP exists for more than a year | |
| 14:42:44 | kashyap | sean-k-mooney: The startswith check is also there, of course. Not sure if you've read the change | |
| 14:43:19 | kashyap | sean-k-mooney: I can argue in good faith that this is also a bug-fix. As it absolutely helps during upgrades for operators. | |
| 14:44:09 | kashyap | sean-k-mooney: And what hyphenated flags are you talking about? Example, please. There are no hyphenated CPU flags | |
| 14:44:20 | kashyap | sean-k-mooney: The +/- syntax is the simplest way to go. | |
| 14:44:53 | sean-k-mooney | kashyap:correct right now but this was discussed at the ptg many moons ago now and there was some disagrepmetn on that syntax | |
| 14:45:20 | sean-k-mooney | im not against it but we shoudl not assuem the kernel will not add hypenated cpu flags | |
| 14:45:26 | sean-k-mooney | its simple to supprot | |
| 14:45:37 | kashyap | What's the disagreement? I don't recall. Please, let's keep things concrete | |
| 14:45:48 | kashyap | sean-k-mooney: Indeed, it is simple. I hope we don't get bogged down in the weeds | |