| *** mhen_ is now known as mhen | 02:58 | |
| opendevreview | Hervé Beraud proposed openstack/tooz master: deprecate the eventlet handler from the zookeeper driver https://review.opendev.org/c/openstack/tooz/+/940374 | 09:16 |
|---|---|---|
| cardoe | fungi: is this the right place for pbr questions? | 18:35 |
| fungi | cardoe: sure! | 18:36 |
| fungi | we just released 6.1.1 today, if that's part of your question | 18:37 |
| cardoe | Well the release notes aren't updating. That was my first comment. | 18:38 |
| fungi | looking... | 18:38 |
| cardoe | https://docs.openstack.org/pbr/latest/user/releasenotes.html | 18:38 |
| fungi | cardoe: there have been no new release notes since https://review.opendev.org/c/openstack/pbr/+/885064 (build_sphinx removal) in 6.0.0 | 18:40 |
| fungi | so it looks up to date to me | 18:40 |
| cardoe | My real question is that it seems like "packages" under "[files]" in setup.cfg doesn't seem to be respected or ironic has something wrong cause of this failure... https://zuul.opendev.org/t/openstack/build/0214cda124e2411197563253af056b86 | 18:41 |
| cardoe | ah I would have thought there would have been a releasenote for some of the suggested changes okay nvm on htat. | 18:41 |
| cardoe | setuptools.errors.PackageDiscoveryError: Multiple top-level packages discovered in a flat-layout: ['etc', 'ironic', 'devstack', 'playbooks', 'releasenotes']. | 18:42 |
| fungi | we thought the changes were transparent/backward-compatible. this is the list of commits: https://paste.opendev.org/show/b6yEK4LGuBn1eXzdKtJH/ | 18:42 |
| JayF | As I said in #openstack-ironic; does PBR even support operation without a setup.py? | 18:42 |
| cardoe | It should. | 18:42 |
| JayF | Lots of things should; not all things are | 18:43 |
| cardoe | That's why it's wanting itself as the build system in pyproject.toml | 18:43 |
| fungi | it does not. did setup.py get removed? | 18:43 |
| cardoe | Yes. That's what my patch is removing. | 18:43 |
| fungi | setup.py is (has always been) required, because it's the only way to add the pbr entrypoint to setuptools plugins | 18:44 |
| cardoe | You're own commit contradicts that. | 18:44 |
| cardoe | https://opendev.org/openstack/pbr/commit/917a0196c4e9ed8f96fb5f911334e9fa47616411 | 18:44 |
| fungi | where? it says "minimal setup.py" | 18:45 |
| cardoe | PEP517 compliance means no setup.py required because the build system is defined in pyproject.toml | 18:45 |
| fungi | not even remotely. did you read pep517? | 18:45 |
| fungi | anyway, the minimum possible setup.py when pbr is used with a pyproject.toml build-system.requires is documented here: https://docs.openstack.org/pbr/latest/user/using.html#pyproject-toml | 18:46 |
| cardoe | I have but if it's required then that's fine. I can close out that patch. | 18:47 |
| cardoe | The only other question I've got is when do we need to remove wsgi_scripts. I know the changes said "soon it won't work". | 18:48 |
| fungi | that's something i haven't tested yet. note that pep-517 build-system.requires support isn't new, it's been in pbr for a couple of years, but in 6.1.1 we added an explicit setuptools dependency in pbr itself to accommodate environments where setuptools is not preinstalled (the pyproject-build tool's isolated builds, python >=3.12, et cetera) | 18:50 |
| cardoe | I'll admit I didn't read your change to see that setup.py is still required by pbr. I was going on the PEP517 only. | 18:51 |
| cardoe | So I apologize for being that person. | 18:51 |
| fungi | no worries. for now, to notify setuptools that it needs to use pbr as a plugin, the only way we're aware of is to signal that through setuptools.setup() in a setup.py file | 18:52 |
| fungi | keep in mind that use of setup.py files is not deprecated by setuptools | 18:52 |
| fungi | execution of setup.py as a script is deprecated | 18:53 |
| cardoe | I was just aiming to break easy_install for ironic by removing it. | 18:54 |
| cardoe | Cause I found someone doing that. | 18:55 |
| clarkb | setuptools is a pep517 and 660 compliant packaging tool. PBR continues to rely on that support to support both peps with PBR | 18:55 |
| clarkb | pep517 doesn't mean no more setuptools. It means here's a new interface that packaging tools use to support stuff. In this case setuptools | 18:55 |
| *** iurygregory_ is now known as iurygregory | 18:55 | |
| clarkb | re wsgi scripts I think using pyproject.toml and pep517 building may break them so when you switch you need to stop? | 18:56 |
| clarkb | using the old methods it should still be supported | 18:56 |
| fungi | cardoe: we have a series of example changes for bindep where we're demonstrating different aspects of modernized python packaging, in order to decide what aspects we'd want to standardize on recommending. the start of the series is at https://review.opendev.org/c/opendev/bindep/+/816741 | 18:58 |
| fungi | cardoe: you'll see in that change that you probably want to switch to options.py_modules instead of files.packages, btw | 18:59 |
| dcapone2004 | I seem to have a missing queue in an openstack deployment and am hoping for some guidance if and how to safely add the queue back in | 22:36 |
| JayF | Queues are, as needed, created by services. There isn't generally a case where you should be creating them manually. | 22:37 |
| dcapone2004 | yeah that is my problem :-) | 22:37 |
| JayF | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/MT5ITEVQY5NBLXQXSFM5QW3XCZA3DLMZ/ | 22:38 |
| JayF | it sounds suspiciously similar to this recent post | 22:38 |
| JayF | perhaps it'll be helpful | 22:38 |
| dcapone2004 | https://paste.openstack.org/show/bms5EkJTo4tkHe9Ls8HS/ | 22:38 |
| JayF | If I saw that; I'd likely restart that service and/or the one it's communicating with | 22:39 |
| JayF | but I don't have any specific advice beyond that. Others may have a better idea; but I'd suggest posing this question in the channel for 1) the service itself which is breaking here and/or 2) the install automation you're using (e.g. kolla-ansible) | 22:39 |
| dcapone2004 | I have attempted to restart the nova and rabbitmq containers, but I may give that a try again later tonight | 22:40 |
| JayF | specifically the openstack services in question; not the rabbit | 22:40 |
| dcapone2004 | appreciate the guidance and reference, as the issue did pop up after a KA upgrade | 22:40 |
| JayF | and nova is a lot more than one service, so remember that | 22:40 |
| JayF | e.g. nova-api vs nova-conductor vs nova-scheduler vs nova-compute | 22:40 |
| dcapone2004 | yeah I restarted all 5 | 22:40 |
| JayF | ack | 22:41 |
| dcapone2004 | on all cluster nodes, but I will definitely give it another try later this evening | 22:41 |
| JayF | if you're using k-a, asking them might be a good choice too | 22:41 |
| JayF | as in that thread; some ansible command fixed things for that user :D | 22:42 |
| dcapone2004 | should all containers be STOPPED on ALL nodes before restarting, or can they be done 1 node at a time, wondering if this is why the queue(s) are not recreating | 22:42 |
| dcapone2004 | or is that a question for the KA group... | 22:42 |
| JayF | you'll absolutely get better success in that channel I suspect; this channel is usually more for development | 22:44 |
| dcapone2004 | ok, thanks | 22:44 |
| JayF | not to mention I might be the only person awake paying attention here given the TZ of most of the oslo team :) | 22:44 |
| dcapone2004 | yeah luckyily it isn't urgent as it is a dev cluster :-) | 22:44 |
| dcapone2004 | JayF: If you are still around, let me ask you this as it is more specific to RabbitMQ and messaging | 23:12 |
| dcapone2004 | I have dug a little deeper and it seems that the queue is missing from only 1 node in the cluster....Can I attempt to restart RabbitMQ on this node only? If I do that, does other services need to be restarted as well, or will it potentially self heal from the other 2 active nodes in the cluster running RabbitMQ? | 23:13 |
| JayF | I am not enough of a rabbit expert to answer that well, sorry | 23:14 |
| dcapone2004 | neither am I :-) | 23:14 |
| dcapone2004 | well after checking rabbitmq docs, verifying that BOTH other RabbitMQ servers in the cluster BOTH had exactly the same queues, I took the chance and restarted rabbitmq on the 3rd node in the cluster and everything self healed.... updating in case anyone else comes across this in the logs | 23:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!