[oslo] python-consul2 is unmaintained
Hello, I recently noticed that python-consul2 library[1], which is used by the consul coordination driver in tooz, hasn't been updated for 3+ years. Looking at issues in the project, there is an indication that the library is not compatible with ACL API in consul >= 1.11[2]. There is another fork created[3] and this includes fixes to support new API endpoints. Although the driver in tooz does not directly use the feature, I think it's better to discuss our plan to mitigate risks caused by the unmaintained library. As far as I can think of, there are three options now 1. Deprecate consul driver and remove it 2. Keep using python-consul2 now. At least basic functionality is proven to work by our functional tests (Note that the tests do not cover all configuration patterns) 3. Replace python-consul2 by py-consul Before we start the overall discussions I'd like to ask a few questions to the wider audience, as our inputs. - Is anyone using the consul coordination driver now ? - Does anyone have experience with python-consul2 and/or py-consul ? Note that this discussion affects the http messaging driver[4] currently proposed, because it also requires client library to communicate with Consul. Actually I noticed the situation when I noticed that the requirement check job is failing because the library is not part of global requirements list... Thank you, Takashi Kajinami [1] https://github.com/poppyred/python-consul2 [2] https://github.com/poppyred/python-consul2/issues/42 [3] https://github.com/criteo-forks/py-consul [4] https://review.opendev.org/c/openstack/oslo.messaging/+/912499 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Could be worth to know if operators use consul and then, deprecate it if it is not the case. Replacing it would consume developers resources. If nobody uses it, let's remove it. It would reduce our technical debt. Migrate it only if people show interest in it. Le ven. 22 mars 2024 à 10:30, Takashi Kajinami <kajinamit@oss.nttdata.com> a écrit :
Hello,
I recently noticed that python-consul2 library[1], which is used by the consul coordination driver in tooz, hasn't been updated for 3+ years.
Looking at issues in the project, there is an indication that the library is not compatible with ACL API in consul >= 1.11[2]. There is another fork created[3] and this includes fixes to support new API endpoints.
Although the driver in tooz does not directly use the feature, I think it's better to discuss our plan to mitigate risks caused by the unmaintained library.
As far as I can think of, there are three options now
1. Deprecate consul driver and remove it
2. Keep using python-consul2 now. At least basic functionality is proven to work by our functional tests (Note that the tests do not cover all configuration patterns)
3. Replace python-consul2 by py-consul
Before we start the overall discussions I'd like to ask a few questions to the wider audience, as our inputs.
- Is anyone using the consul coordination driver now ?
- Does anyone have experience with python-consul2 and/or py-consul ?
Note that this discussion affects the http messaging driver[4] currently proposed, because it also requires client library to communicate with Consul. Actually I noticed the situation when I noticed that the requirement check job is failing because the library is not part of global requirements list...
Thank you, Takashi Kajinami
[1] https://github.com/poppyred/python-consul2 [2] https://github.com/poppyred/python-consul2/issues/42 [3] https://github.com/criteo-forks/py-consul [4] https://review.opendev.org/c/openstack/oslo.messaging/+/912499
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
I did some trial to replace python-consul2 by py-consul but it turned out that py-consul is based on the quite old code of python-consul and lacks some features added to python-consul2. (eg. Session.create does not support token) and we have to fill this gap for the migration. On 3/23/24 00:41, Herve Beraud wrote:
Could be worth to know if operators use consul and then, deprecate it if it is not the case.
Replacing it would consume developers resources. If nobody uses it, let's remove it. It would reduce our technical debt. Migrate it only if people show interest in it.
I agree with this approach regarding the tooz driver, since the team is now quite small and we have to focus on what is actually used to keep the overall work feasible for us. Though we still have to continue discussion about the library as part of the discussion for HTTP messaging driver.
Le ven. 22 mars 2024 à 10:30, Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> a écrit :
Hello,
I recently noticed that python-consul2 library[1], which is used by the consul coordination driver in tooz, hasn't been updated for 3+ years.
Looking at issues in the project, there is an indication that the library is not compatible with ACL API in consul >= 1.11[2]. There is another fork created[3] and this includes fixes to support new API endpoints.
Although the driver in tooz does not directly use the feature, I think it's better to discuss our plan to mitigate risks caused by the unmaintained library.
As far as I can think of, there are three options now
1. Deprecate consul driver and remove it
2. Keep using python-consul2 now. At least basic functionality is proven to work by our functional tests (Note that the tests do not cover all configuration patterns)
3. Replace python-consul2 by py-consul
Before we start the overall discussions I'd like to ask a few questions to the wider audience, as our inputs.
- Is anyone using the consul coordination driver now ?
- Does anyone have experience with python-consul2 and/or py-consul ?
Note that this discussion affects the http messaging driver[4] currently proposed, because it also requires client library to communicate with Consul. Actually I noticed the situation when I noticed that the requirement check job is failing because the library is not part of global requirements list...
Thank you, Takashi Kajinami
[1] https://github.com/poppyred/python-consul2 <https://github.com/poppyred/python-consul2> [2] https://github.com/poppyred/python-consul2/issues/42 <https://github.com/poppyred/python-consul2/issues/42> [3] https://github.com/criteo-forks/py-consul <https://github.com/criteo-forks/py-consul> [4] https://review.opendev.org/c/openstack/oslo.messaging/+/912499 <https://review.opendev.org/c/openstack/oslo.messaging/+/912499>
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit <https://github.com/kajinamit> launchpad: https://launchpad.net/~kajinamit <https://launchpad.net/~kajinamit>
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ <https://github.com/4383/>
participants (2)
-
Herve Beraud
-
Takashi Kajinami