| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-15 | |||
| 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 :) | |
| 12:51:19 | bauzas | ralonsoh: ack | |
| 12:51:32 | zigo | Python is a mess, not packaging ! :) | |
| 12:52:08 | bauzas | zigo: sure, having 3 different official ways to package + a lot of third-party ones is certainly not a mess | |
| 12:52:31 | zigo | Well, everyone's wrong, I'm the only one doing things right ... :P | |
| 12:54:17 | bauzas | #xkcd927, I agree | |
| 12:56:18 | zigo | Oh, I was wrong, pymemcache isn't using PBR, but standard setuptools with complex PBR like setup.cfg... | |
| 12:56:31 | zigo | So that's indeed a very good case for #xkcd927 ... | |
| 12:57:24 | zigo | But the issue really is Python packaging, and not Deb packaging. | |
| 12:57:31 | zigo | (not jocking, this time...) | |
| 13:02:07 | zigo | So, setup.cfg's way is (3rd way that I know now...): | |
| 13:02:08 | zigo | packages = foo | |
| 13:02:08 | zigo | [options] | |
| 13:12:02 | opendevreview | Merged 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 | |
| 13:17:26 | elodilles | zigo: somewhat similar case was this: https://review.opendev.org/q/topic:setuptools-issue-3197 | |
| 13:17:32 | elodilles | i think... | |
| 13:37:12 | zigo | - pyproject.toml | |
| 13:37:12 | zigo | - setup.cfg by PBR | |
| 13:37:12 | zigo | - setup.cfg by setup tools | |
| 13:37:12 | zigo | - setup.py (the lebacy way) | |
| 13:37:12 | zigo | Thinking about it: it's not even 3 standards that we have, but 4: | |
| 13:37:14 | zigo | Fun ... :P | |
| 13:42:18 | bauzas | elodilles: want me to rebase the placement RC1 patch with the new SHA1 ? | |
| 14:02:46 | elodilles | bauzas: if you could do that that would be awesome o:) | |
| 14:18:43 | bauzas | elodilles: shall work https://review.opendev.org/c/openstack/releases/+/894698 | |
| 14:19:33 | bauzas | (I needed to checkout HEAD^ for the bobcat file before using new-release tool) | |
| 15:02:05 | Uggla | bauzas, I think, I have spotted the difference and the "issue" with service token + sdk usage. | |
| 15:40:16 | bauzas | Uggla: happy to hear | |
| 15:41:05 | Uggla | I'm currently writing a wrapup of my findings, I will share it Monday. | |
| 15:41:28 | Uggla | coz I need to go to a school meeting... | |
| 15:42:15 | bauzas | Uggla: haha, me too on both Monday (for Charline) and Tuesday (Clémence) :) | |
| 15:42:15 | bauzas | Uggla: haha, me too on both Monday (for Charline) and Tuesday (Clémence) :) | |
| 15:59:35 | elodilles | bauzas: thanks, placement rc1 patch is on the gate! | |
| 15:59:53 | elodilles | now we need only the nova rc1 :] | |
| 16:13:54 | dansmith | we still need to land the revert series | |
| 16:13:58 | dansmith | I just rechecked the top one | |
| 16:14:19 | dansmith | and looks like the bottom one just hit a gate reset :/ | |
| 16:15:23 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/placement/+/895491 | |
| 16:15:25 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2023.2: Update TOX_CONSTRAINTS_FILE for stable/2023.2 https://review.opendev.org/c/openstack/placement/+/895492 | |
| 16:15:26 | opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/placement/+/895493 | |
| #openstack-nova - 2023-09-16 | |||
| 21:27:15 | opendevreview | Merged openstack/nova master: Make our nova-ovs-hybrid-plug job omit cinder https://review.opendev.org/c/openstack/nova/+/893540 | |
| #openstack-nova - 2023-09-18 | |||
| 07:22:18 | bauzas | good morning Nova | |
| 10:59:15 | opendevreview | Konrad Gube proposed openstack/nova-specs master: Re-propose using extend volume completion action for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/895648 | |
| 11:36:35 | sean-k-mooney | fyi https://github.com/mtreinish/stestr/issues/350 is going to make the gate explode | |
| 12:02:34 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Do not store InstanceInvalidState as instance_fault https://review.opendev.org/c/openstack/nova/+/860702 | |
| 12:09:09 | bauzas | sean-k-mooney: at least if the gate was actually working... | |
| 12:10:10 | sean-k-mooney | im pushing a uc fix for this now | |
| 12:15:21 | bauzas | sean-k-mooney: you know that we fail hard on https://launchpad.net/bugs/1940425 right? | |
| 12:16:13 | sean-k-mooney | ish | |
| 12:16:26 | sean-k-mooney | they reverted a particl fix on the neutron side for ovn | |
| 12:16:31 | sean-k-mooney | and have another fix | |
| 12:16:38 | sean-k-mooney | btu i dont think that is merged | |
| 12:16:42 | sean-k-mooney | it passes with ml2/ovs | |
| 12:16:46 | sean-k-mooney | so this is not a nova issue | |
| 12:17:03 | sean-k-mooney | its a neutorn one its also not an os-vif issues as far as i am aware | |
| 12:17:11 | sean-k-mooney | i have not looked that this in a while however | |
| 12:17:52 | sean-k-mooney | so i still stand by the invaldifor nova and incomplte/invalid for os-vif tatus | |
| 12:18:09 | sean-k-mooney | this is a neutron bug only when using ml2/ovn | |
| 12:18:50 | sean-k-mooney | we can skip that test if we want by default and leave it on in the hybrid plug job which uses ml2/ovs | |
| 12:19:02 | sean-k-mooney | until they fix it | |
| 12:20:55 | sean-k-mooney | bauzas: fyi i explained why this is a neutron bug in https://bugs.launchpad.net/neutron/+bug/1940425/comments/23 | |
| 12:21:29 | bauzas | yup, we know this is a neutron test and ralonsoh works on it AFAIK | |
| 12:21:55 | bauzas | context : https://review.opendev.org/c/openstack/nova/+/894945 is getting trampled a lot due to this | |
| 12:22:42 | sean-k-mooney | ya so in https://review.opendev.org/c/openstack/nova/+/893540 | |