Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-05
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 :)
15:12:31 kashyap gibi: In short, that fix (which allows selectively disabling CPU flags) helps migrating instances from any Intel host that doesn't have "TSX" to a destination host that has "TSX"
15:20:39 gibi kashyap: lets bring it up next week on the nova meeting. I will review your patch now. If next week we see that it has a positive review and close to merge then I can accept to approve the bp late and at the same time merge the code and forget all about it
15:25:58 kashyap gibi: Thank you; sure.
15:31:19 openstackgerrit Stephen Finucane proposed openstack/nova master: policy: Copy rules before providing them to enforcer https://review.opendev.org/c/openstack/nova/+/774252
15:31:23 stephenfin gmann: ^
15:31:35 stephenfin Just to be safe
15:33:36 artom Wait, is making a field nullable in an object mean a version bump?
15:33:49 artom Wait, no, ignore me
15:51:15 sean-k-mooney gmann: is https://opendev.org/openstack/openstack-tempest-skiplist new?
15:51:41 sean-k-mooney i dont recall seeing this before i assuem we do not use it in nova?
15:52:48 sean-k-mooney ah this is a ooo thing
15:53:36 sean-k-mooney thats fine i was concerned that we would be skipping tests without knowing it just be cause ooo or another poejct hit an issue
15:54:04 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: libvirt: start tracking NUMACell.socket for hosts https://review.opendev.org/c/openstack/nova/+/766816
15:54:07 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
15:54:09 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: Add `socket` PCI NUMA affinity policy request prefilter https://review.opendev.org/c/openstack/nova/+/772749
15:54:12 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: Track host NUMA topology in PCI manager https://review.opendev.org/c/openstack/nova/+/774149
15:54:16 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: pci: implement the `socket` NUMA affinity policy https://review.opendev.org/c/openstack/nova/+/772779
16:32:40 stephenfin gmann: I removed that legacy PolicyFixture. 482 unit test failures. Haven't run functional tests yet. This is going to take some work :-)
16:48:27 kashyap gibi: Thanks for the quick review. Yes, let's talk on the Nova meeting week
17:57:05 mnaser anyone know off the top of their head if you can specify volume type when using bfv (so nova creating the volume?)
17:59:25 sean-k-mooney mnaser: via the block device mappings i think that came up at some point
17:59:40 mnaser sean-k-mooney: yeah, i'm looking at the code to see if that is currently possible
18:00:13 mnaser > If you want to create a volume to a specific storage backend, you need to use an image which has cinder_img_volume_type property. In this case, a new volume will be created as storage_backend1 volume type.
18:00:45 sean-k-mooney mnaser: we talked about it at the ptg but i cant recally if we said yes or not
18:01:05 sean-k-mooney i know we were relutant to support it as we did not want to keep proxing thigns to other services

Earlier   Later