Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-09-14
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: Logs cinderclient requests when debugging https://review.opendev.org/c/openstack/nova/+/895191
15:39:12 opendevreview Gorka Eguileor proposed openstack/nova master: Fix debug options https://review.opendev.org/c/openstack/nova/+/895190
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 packagename = "packagedir"
12:42:35 zigo [tool.setuptools.package-dir]
12:42:35 zigo Is there a PBR equivalent to pyproject.toml's :
12:43:37 jras_ Hi, we're trying to migrate from nova/libvirt network QoS to Neutron managed QoS. Is there any way to do this without requiring VM downtime? It seems changes made to domain config using virsh domiftune are undone after live migrations. It seems the alternative is to resize to a flavor without these quotas. Is that correct?
12:43:38 zigo right?
12:43:38 zigo nova
12:43:38 zigo packages =
12:43:38 zigo [files]
12:43:38 zigo It should be:
12:45:20 bauzas zigo: https://docs.openstack.org/pbr/latest/user/using.html#files
12:45:33 ralonsoh bauzas, I pushed a patch for this yesterday
12:45:38 ralonsoh I think is merged
12:45:40 bauzas ack gtk
12:45:48 bauzas ralonsoh: yeah the one you said
12:45:53 bauzas but that's still failing
12:46:02 bauzas fresh fish from today's shelf
12:46:43 ralonsoh bauzas, https://review.opendev.org/c/openstack/tempest/+/895167/1/tempest/api/compute/admin/test_live_migration.py isn't that enough?
12:46:51 jras_ I forgot to mention that the original flavor has had the quotas removed, before using domiftune to edit the domain config, they still seem to be set after live migration.
12:48:30 bauzas ralonsoh: unstable seems just be there for marking the test, but it still runs
12:48:32 bauzas https://opendev.org/openstack/tempest/commit/21f53012f76d11e3df327adcf87e67edf9045d09
12:49:09 ralonsoh bauzas, but the job should not fail if the test fails
12:49:26 bauzas agreed, I'm now puzzled
12:49:32 zigo (ie: the Debian folder is annoying setuptools 66.1.1, though it seems 66.1.2 is kind of fixed...)
12:49:32 zigo setuptools.errors.PackageDiscoveryError: Multiple top-level packages discovered in a flat-layout: ['debian', 'pymemcache'].
12:49:32 zigo bauzas: Thanks, but I think what I wrote isn't enough. What's happening to me, is:
12:49:45 ralonsoh bauzas, if in this new recheck it fails again, I'll send a patch to skip it
12:50:28 bauzas zigo: there are good reasons why I never did put my toe into the packaging mess, and that one you mention looks another good one to me :)

Earlier   Later