| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-05 | |||
| 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 | host_state, key='availability_zone') | |
| 08:58:48 | alexe9191 | if 'availability_zone' in metadata: | |
| 08:58:49 | alexe9191 | hosts_passes = availability_zone in metadata['availability_zone'] | |
| 08:58:49 | alexe9191 | host_az = metadata['availability_zone'] | |
| 08:58:50 | alexe9191 | else: | |
| 08:58:50 | alexe9191 | hosts_passes = availability_zone == CONF.default_availability_zone | |
| 08:58:51 | alexe9191 | host_az = CONF.default_availability_zone | |
| 08:58:51 | alexe9191 | if not hosts_passes: | |
| 08:58:52 | alexe9191 | LOG.debug("Availability Zone '%(az)s' requested. " | |
| 08:58:52 | alexe9191 | "%(host_state)s has AZs: %(host_az)s", | |
| 08:58:53 | alexe9191 | {'host_state': host_state, | |
| 08:58:53 | alexe9191 | 'az': availability_zone, | |
| 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: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 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: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 | |
| 14:46:01 | sean-k-mooney | just change flag = flag.strip('-') to flag = flag[1:] | |
| 14:46:32 | sean-k-mooney | kashyap: the was a view expressed that deployment tools may prefer 2 config opitons instead of 1 | |
| 14:46:35 | kashyap | Looking at your comments ... | |
| 14:46:41 | kashyap | sean-k-mooney: Thanks for the quick review | |
| 14:48:15 | sean-k-mooney | if you do flag = flag[1:] it wont matter if the kernel adds hypeinated flags in the futrue. there are a number that have undercosres which is why im not sure they wont add ones with - https://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean | |
| 14:49:37 | sean-k-mooney | oh possible aes-ni | |
| 14:51:16 | sean-k-mooney | ah no that is shortened to just ase | |
| 14:51:21 | sean-k-mooney | *aes | |
| 14:52:30 | kashyap | sean-k-mooney: Yep; note: strip(+) will strip it from the beginning and end. *Not* from the middle | |
| 14:54:43 | sean-k-mooney | ah it does have that limitation | |
| 14:54:53 | sean-k-mooney | that is different then other languages | |
| 14:54:54 | kashyap | Anyway; can do the sliced index | |
| 14:57:01 | sean-k-mooney | https://docs.python.org/3/library/stdtypes.html#str.strip i was expectin git to work more like sub but i guess that makes sense i have used ti to strip leading and trailing whitespace before | |
| 14:57:14 | sean-k-mooney | and i knew it maintained that | |
| 14:57:46 | sean-k-mooney | by the way im not against implementing this i just want use to do the paperwork correctly | |
| 14:58:25 | sean-k-mooney | so basically add it to the adgendar for next weeks nova meeting and get the bp approved for wallby if the core team agrees | |
| 15:01:37 | gibi | kashyap, sean-k-mooney: yepp that bp needs an approval, but honestly it is pretty late in the cycle. we past M2 so if it is not super urgent to fix some bad situation somewhere then I don't think it fits in Wallaby. We have 18 approved bps and I think we will only have time to finish like maybe 2/3 of it | |
| 15:02:53 | kashyap | gibi: It does fix a major problem | |
| 15:03:01 | kashyap | gibi: I'll explain in a bit; running a meeting | |
| 15:03:01 | gibi | is it a bug? | |
| 15:03:05 | gibi | ack | |
| 15:06:23 | sean-k-mooney | gibi: a downtream one basically a kernel abi break | |
| 15:06:50 | sean-k-mooney | though it wont nessisarly fix it it just will help prevent new people form hitting it | |
| 15:06:55 | kashyap | sean-k-mooney: Not just downstream | |
| 15:06:58 | kashyap | Affects upstream too | |
| 15:07:36 | sean-k-mooney | to be clear this wont acutlly help improve upgrade without a vm reboot | |
| 15:07:56 | sean-k-mooney | anyway ya i should join that too | |
| 15:08:01 | sean-k-mooney | the call | |
| 15:09:20 | kashyap | sean-k-mooney: It won't; but let's not get bogged down into details, please :) | |