| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-14 | |||
| 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] | |
| 12:42:35 | zigo | packagename = "packagedir" | |
| 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 | It should be: | |
| 12:43:38 | zigo | [files] | |
| 12:43:38 | zigo | packages = | |
| 12:43:38 | zigo | nova | |
| 12:43:38 | zigo | right? | |
| 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 | bauzas: Thanks, but I think what I wrote isn't enough. What's happening to me, is: | |
| 12:49:32 | zigo | setuptools.errors.PackageDiscoveryError: Multiple top-level packages discovered in a flat-layout: ['debian', 'pymemcache']. | |
| 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: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 :) | |
| 12:51:19 | bauzas | ralonsoh: ack | |