| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-14 | |||
| 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 | |
| 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 | [options] | |
| 13:02:08 | zigo | packages = foo | |
| 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 | Thinking about it: it's not even 3 standards that we have, but 4: | |
| 13:37:12 | zigo | - setup.py (the lebacy way) | |
| 13:37:12 | zigo | - setup.cfg by setup tools | |
| 13:37:12 | zigo | - setup.cfg by PBR | |
| 13:37:12 | zigo | - pyproject.toml | |
| 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. | |