Earlier  
Posted Nick Remark
#openstack-nova - 2023-09-14
13:14:15 mgariepy https://paste.openstack.org/show/bP2oY2IOe4lNvj6wGB8w/
13:14:51 mgariepy what is resolving the alias ? is it dont by the scheduler directly ?
13:15:27 sean-k-mooney that depends on the request
13:15:47 mgariepy my flavor has alias stuff in in.
13:15:49 sean-k-mooney but no i think its doen in the compute or the api
13:16:53 sean-k-mooney https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure-nova-api
13:17:07 sean-k-mooney so for ne vm request this is usd by the nova-api not the scheduler
13:17:30 sean-k-mooney and for rezize its used form teh compute
13:17:45 sean-k-mooney so if you are udataing this you need to restart the nova-api not the scheduler
13:18:26 sean-k-mooney the scheudle reciveds a fully popultated RequestSepc object which has the pci resuets embeeded in it
13:19:38 mgariepy but me resquest doesn't receive the device_type :/
13:23:12 sean-k-mooney did you restart the nova-api processes after updating hte alias
13:24:02 mgariepy i did restart the nova slice. let me try juste putting the same config accross all the cluster to see if it changes something.
13:32:19 mgariepy what driver shoud be loaded fo the pci dev ?
13:32:56 mgariepy pci-stub or vfio-pci ?
13:32:58 sean-k-mooney the driver should not matter to the schduler
13:33:13 sean-k-mooney that woudl only matter on the compute node but yes either of those shoudl work
13:33:18 mgariepy ok
13:33:36 sean-k-mooney the important part is that the framebuffer is not initallised by xorg/wayland as that woudl prevent the passthough
13:33:53 mgariepy ha ok.
13:34:13 sean-k-mooney vfio-pci is what kvm/qemu will use when its being passthough through
13:34:26 sean-k-mooney so prebinding to that is generally not a bad idea but often not required
13:34:46 mgariepy i did some stuff with passthrough with el-cheapo gamer gpus. but with older openstack release.
13:35:50 sean-k-mooney thre is nothing really that has changed that would impact this
13:36:06 sean-k-mooney the alias and whitelist/device list syntax is the same
13:36:22 sean-k-mooney and your reporting that its fialing in the pci filter os its not related to the placment part
13:36:31 sean-k-mooney since it passes that to get to the point where its failing
13:37:09 mgariepy yeah i'll retest in like 30 minutes.. meeting time ;)
15:04:23 mgariepy sean-k-mooney, it works now Thanks a log for your help.
15:04:47 mgariepy with the type-PF and all my server with the same config it's almost magical :D
15:21:51 sean-k-mooney awsome
15:21:52 opendevreview Sylvain Bauza proposed openstack/placement master: Update 2023.2 reqs to support os-traits 3.0.0 as min version https://review.opendev.org/c/openstack/placement/+/895186
15:22:21 sean-k-mooney the reqeust was proably being accpeted by a not restarted instace
15:22:29 mgariepy yeah
15:23:01 bauzas dansmith: sean-k-mooney: forgot to propose the requirements update for the new traits : https://review.opendev.org/c/openstack/placement/+/895186
15:23:05 mgariepy any tips on debugging that sort of stuff when multiple instance of every service are running ?
15:23:08 bauzas we need it before RC1
15:23:39 dansmith bauzas: aren't we past requirements freeze?
15:23:46 dansmith is that in u-c already?
15:24:41 bauzas dansmith: os-traits was delivered in March
15:24:46 bauzas and u-c already has it
15:24:52 dansmith okay
15:24:56 bauzas https://opendev.org/openstack/requirements/raw/branch/master/upper-constraints.txt
15:25:13 dansmith ack, cool
15:25:20 bauzas so we just need to say 'look, for Bobcat, we need to accept only 3.0 since we use a trait in it"
15:25:40 bauzas I haven't checked tho whether we really use this trait in Placement but I'm assuming it
15:26:11 dansmith bauzas: wait you're not sure if we need the new traits? :)
15:26:58 dansmith we just bumped for this a few weeks ago: https://review.opendev.org/c/openstack/nova/+/873221
15:38:38 opendevreview Gorka Eguileor proposed openstack/nova master: Fix load_validators https://review.opendev.org/c/openstack/nova/+/895189
15:39:12 opendevreview Gorka Eguileor proposed openstack/nova master: Fix debug options https://review.opendev.org/c/openstack/nova/+/895190
15:39:12 opendevreview Gorka Eguileor proposed openstack/nova master: Logs cinderclient requests when debugging https://review.opendev.org/c/openstack/nova/+/895191
15:39:40 opendevreview Gorka Eguileor proposed openstack/nova master: Fix guard for NVMeOF volumes https://review.opendev.org/c/openstack/nova/+/895192
15:53:20 bauzas dansmith: so, I made a few researches, my bad, just followed blindly a pattern from Antelope when I did https://review.opendev.org/c/openstack/placement/+/874080
15:54:09 bauzas so, https://review.opendev.org/c/openstack/nova/+/873221 is using traits-2.10 https://review.opendev.org/c/openstack/releases/+/873106 which is already supported as minimum
16:10:55 bauzas dansmith: so, I think I'll abandon https://review.opendev.org/c/openstack/placement/+/895186
16:11:08 dansmith bauzas: okay
16:12:28 bauzas I'm actually lost, we created 3.0 in order to no longer support py2.6 and py2.7
16:12:31 sean-k-mooney bauzas: so https://review.opendev.org/c/openstack/nova/+/831194/37/nova/share/manila.py#43 is returning the connection to via the sdk to talke to manilla
16:12:59 bauzas sean-k-mooney: sec, trying to see whether we need https://review.opendev.org/c/openstack/releases/+/894698
16:13:06 sean-k-mooney its fine
16:13:20 sean-k-mooney focus on that i was just wonderign where the error was
16:13:54 bauzas sorry I meant https://review.opendev.org/c/openstack/placement/+/895186
16:14:26 bauzas we'll add a new trait which isn't used yet by Nova
16:14:44 bauzas but we'll also make py3.6 and py3.7 unsupported
16:20:03 bauzas dansmith: sean-k-mooney: okay, I think I sorted it, we eventually need https://review.opendev.org/c/openstack/placement/+/895186 not because of the new trait, but because we want to unsupport 3.6 and 3.7
16:20:09 bauzas in Bobcat
16:20:14 dansmith okay
16:20:38 sean-k-mooney ok so i should +2w that then right
16:20:43 sean-k-mooney the min version bump to 3.0.0
16:24:35 bauzas sean-k-mooney: sorry, yeah
16:24:47 bauzas thanks
16:39:31 sean-k-mooney mgariepy: the only real tip is to use the request-id to corralate the requets across diffent services when looking at the logs
16:40:03 sean-k-mooney that and try and use automation like kolla-ansible to ensure you have the same config on all relevent nodes rather then doing manual changes
16:40:27 sean-k-mooney but no not really other then that
17:03:15 mgariepy sean-k-mooney, i'm using openstack-ansible
17:03:56 mgariepy when doing changes that i'm not quite sure i do it manually instead of doing it via osa.
#openstack-nova - 2023-09-15
07:44:11 sahid o/
07:44:43 sahid still with my fighting regarding aggregate and az. There is one thing I wanted to mention
07:45:52 sahid I have noticed the behavior betzeen placement aggregate multitenance isloation in placement and the filter aggregate multitenancy isolation of the sheduler
07:46:36 sahid the filter scheduler accepts host which does not belong to an aggregate with filter_tenant_id
07:50:08 sahid so tenant_id can be scheduled to hosts that do not belong to an aggregate with filter_tenant_id=tenant_id, where in placement tenant_id can *only* be scheduled to hosts that belong to aggregate with filter_tenant_id=tenant_id
07:50:19 sahid i'm not sure I'm clear :-)
08:44:13 bauzas sahid: you're perfectly clear :)
08:44:26 bauzas placement prefilter behaves different from the scheduler filter
08:55:01 sahid bauzas: thanks :-) the question that i have also is that, is there any plan to move all the filters in placement and so remove the scheduler? My point is that, the current AggregateMultitenancyIsolation is limited regarding the number of project_id we can set as part of filter_tenant_id (limited by the db field for value of an aggregate key I guess). Does that make sense to provide a patch to remove
08:55:07 sahid that limitation by adding a logic like we have in placement?
08:55:10 sahid or we just don't want to involve on scheduler fitler anymore?
08:55:37 bauzas sahid: we eventually came to the conclusion that this was impossible and unwantable to move all the filters into placement prefilters
08:56:11 bauzas but everytime we have resources in placement, we shall have prefilters yeah
08:57:10 bauzas back to your question, I'd say that there is no clear stance about the AggregateMultitenancyIsolation filter
08:57:16 bauzas it behaves a bit differently
08:57:26 bauzas so we could keep it and patch it if required
08:57:36 bauzas the limitation you mention is indeed a DB problem
08:58:18 bauzas but I assume placement would also have this limitation (at least it's limited by the length of the URL and the size of the response :) )
08:59:05 sahid thanks a lot for all those points
08:59:58 sahid for placement filter_tenant_id is a prefix for the key, it searches to match all keys in the aggregate that start with filter_tenant_id
09:00:17 sahid which well remove the limitation :-)
12:40:28 bauzas ralonsoh: looks like some neutron revert is also needed here : https://9646a7fb82b47fbe6288-a22e2178400a1d74c0dfc0d0570ba9cf.ssl.cf2.rackcdn.com/894945/1/check/nova-grenade-multinode/e307f26/testr_results.html
12:42:35 zigo Is there a PBR equivalent to pyproject.toml's :
12:42:35 zigo [tool.setuptools.package-dir]

Earlier   Later