Re: [openstack-dev] [oslo] Oslo PTG Summary

[Ken Giusti]

Hi Doug,

Andy updated the etherpad [0] with a new link [1].
Holler if it's still broken...


[0] https://etherpad.openstack.org/p/oslo-ptg-rocky
[1] 
https://docs.google.com/presentation/d/1PWJAGQohAvlwod4gMTp6u1jtZT1cuaE-whRmnV8uiMM/edit?usp=sharing

On Mon, Mar 12, 2018 at 11:54 AM, Doug Hellmann  wrote:
> I can’t see
>
> https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false&loop=false&delayms=3000&slide=id.p
>
>
>
> On Mar 12, 2018, at 11:39 AM, Ken Giusti  wrote:
>
> Hi Josh - I'm able to view all of them, but I probably have special
> google powers ;)
>
> Which links are broken for you?
>
> thanks,
>
> On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow  wrote:
>
>
> Can we get some of those doc links opened.
>
> 'You need permission to access this published document.' I am getting for a
> few of them :(
>
>
> Ben Nemec wrote:
>
>
> Hi,
>
> Here's my summary of the discussions we had in the Oslo room at the PTG.
> Please feel free to reply with any additions if I missed something or
> correct anything I've misrepresented.
>
> oslo.config drivers for secret management
> -
>
> The oslo.config implementation is in progress, while the Castellan
> driver still needs to be written. We want to land this early in Rocky as
> it is a significant change in architecture for oslo.config and we want
> it to be well-exercised before release.
>
> There are discussions with the TripleO team around adding support for
> this feature to its deployment tooling and there will be a functional
> test job for the Castellan driver with Custodia.
>
> There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
> UTC for discussion of this feature.
>
> oslo.config driver implementation: https://review.openstack.org/#/c/513844
> spec:
>
> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
>
> Custodia key management support for Castellan:
> https://review.openstack.org/#/c/515190/
>
> "stable" libraries
> --
>
> Some of the Oslo libraries are in a mature state where there are very
> few, if any, meaningful changes to them. With the removal of the
> requirements sync process in Rocky, we may need to change the release
> process for these libraries. My understanding was that there were no
> immediate action items for this, but it was something we need to be
> aware of.
>
> dropping support for mox3
> -
>
> There was some concern that no one from the Oslo team is actually in a
> position to support mox3 if something were to break (such as happened in
> some libraries with Python 3.6). Since there is a community goal to
> remove mox from all OpenStack projects in Rocky this will hopefully not
> be a long-term problem, but there was some discussion that if projects
> needed to keep mox for some reason that they would be asked to provide a
> maintainer for mox3. This topic is kind of on hold pending the outcome
> of the community goal this cycle.
>
> automatic configuration migration on upgrade
> 
>
> There is a desire for oslo.config to provide a mechanism to
> automatically migrate deprecated options to their new location on
> version upgrades. This is a fairly complex topic that I can't cover
> adequately in a summary email, but there is a spec proposed at
> https://review.openstack.org/#/c/520043/ and POC changes at
> https://review.openstack.org/#/c/526314/ and
> https://review.openstack.org/#/c/526261/
>
> One outcome of the discussion was that in the initial version we would
> not try to handle complex migrations, such as the one that happened when
> we combined all of the separate rabbit connection opts into a single
> connection string. To start with we will just raise a warning to the
> user that they need to handle those manually, but a templated or
> hook-based method of automating those migrations could be added as a
> follow-up if there is sufficient demand.
>
> oslo.messaging plans
> 
>
> There was quite a bit discussed under this topic. I'm going to break it
> down into sub-topics for clarity.
>
> oslo.messaging heartbeats
> =
>
> Everyone seemed to be in favor of this feature, so we anticipate
> development moving forward in Rocky. There is an initial patch proposed
> at https://review.openstack.org/546763
>
> We felt that it should be possible to opt in and out of the feature, and
> that the configuration should be done at the application level. This
> should _not_ be an operator decision as they do not have the knowledge
> to make it sanely.
>
> There was also a desire to have a TTL for messages.
>
> bug cleanup
> ===
>
> There are quite a few launchpad bugs open against oslo.messaging that
> were reported against old, now unsupported versions. Since we have the
> launchpad bug expirer enabled in Oslo the action item

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Doug Hellmann]

I can’t see 

https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false&loop=false&delayms=3000&slide=id.p
 




> On Mar 12, 2018, at 11:39 AM, Ken Giusti  wrote:
> 
> Hi Josh - I'm able to view all of them, but I probably have special
> google powers ;)
> 
> Which links are broken for you?
> 
> thanks,
> 
> On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow  wrote:
>> 
>> Can we get some of those doc links opened.
>> 
>> 'You need permission to access this published document.' I am getting for a
>> few of them :(
>> 
>> 
>> Ben Nemec wrote:
>>> 
>>> Hi,
>>> 
>>> Here's my summary of the discussions we had in the Oslo room at the PTG.
>>> Please feel free to reply with any additions if I missed something or
>>> correct anything I've misrepresented.
>>> 
>>> oslo.config drivers for secret management
>>> -
>>> 
>>> The oslo.config implementation is in progress, while the Castellan
>>> driver still needs to be written. We want to land this early in Rocky as
>>> it is a significant change in architecture for oslo.config and we want
>>> it to be well-exercised before release.
>>> 
>>> There are discussions with the TripleO team around adding support for
>>> this feature to its deployment tooling and there will be a functional
>>> test job for the Castellan driver with Custodia.
>>> 
>>> There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
>>> UTC for discussion of this feature.
>>> 
>>> oslo.config driver implementation: https://review.openstack.org/#/c/513844
>>> spec:
>>> 
>>> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
>>> 
>>> Custodia key management support for Castellan:
>>> https://review.openstack.org/#/c/515190/
>>> 
>>> "stable" libraries
>>> --
>>> 
>>> Some of the Oslo libraries are in a mature state where there are very
>>> few, if any, meaningful changes to them. With the removal of the
>>> requirements sync process in Rocky, we may need to change the release
>>> process for these libraries. My understanding was that there were no
>>> immediate action items for this, but it was something we need to be
>>> aware of.
>>> 
>>> dropping support for mox3
>>> -
>>> 
>>> There was some concern that no one from the Oslo team is actually in a
>>> position to support mox3 if something were to break (such as happened in
>>> some libraries with Python 3.6). Since there is a community goal to
>>> remove mox from all OpenStack projects in Rocky this will hopefully not
>>> be a long-term problem, but there was some discussion that if projects
>>> needed to keep mox for some reason that they would be asked to provide a
>>> maintainer for mox3. This topic is kind of on hold pending the outcome
>>> of the community goal this cycle.
>>> 
>>> automatic configuration migration on upgrade
>>> 
>>> 
>>> There is a desire for oslo.config to provide a mechanism to
>>> automatically migrate deprecated options to their new location on
>>> version upgrades. This is a fairly complex topic that I can't cover
>>> adequately in a summary email, but there is a spec proposed at
>>> https://review.openstack.org/#/c/520043/ and POC changes at
>>> https://review.openstack.org/#/c/526314/ and
>>> https://review.openstack.org/#/c/526261/
>>> 
>>> One outcome of the discussion was that in the initial version we would
>>> not try to handle complex migrations, such as the one that happened when
>>> we combined all of the separate rabbit connection opts into a single
>>> connection string. To start with we will just raise a warning to the
>>> user that they need to handle those manually, but a templated or
>>> hook-based method of automating those migrations could be added as a
>>> follow-up if there is sufficient demand.
>>> 
>>> oslo.messaging plans
>>> 
>>> 
>>> There was quite a bit discussed under this topic. I'm going to break it
>>> down into sub-topics for clarity.
>>> 
>>> oslo.messaging heartbeats
>>> =
>>> 
>>> Everyone seemed to be in favor of this feature, so we anticipate
>>> development moving forward in Rocky. There is an initial patch proposed
>>> at https://review.openstack.org/546763
>>> 
>>> We felt that it should be possible to opt in and out of the feature, and
>>> that the configuration should be done at the application level. This
>>> should _not_ be an operator decision as they do not have the knowledge
>>> to make it sanely.
>>> 
>>> There was also a desire to have a TTL for messages.
>>> 
>>> bug cleanup
>>> ===
>>> 
>>> There are quite a few launchpad bugs open against oslo.messaging that
>>> were reported against old, now 

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Ken Giusti]

Hi Josh - I'm able to view all of them, but I probably have special
google powers ;)

Which links are broken for you?

thanks,

On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow  wrote:
>
> Can we get some of those doc links opened.
>
> 'You need permission to access this published document.' I am getting for a
> few of them :(
>
>
> Ben Nemec wrote:
>>
>> Hi,
>>
>> Here's my summary of the discussions we had in the Oslo room at the PTG.
>> Please feel free to reply with any additions if I missed something or
>> correct anything I've misrepresented.
>>
>> oslo.config drivers for secret management
>> -
>>
>> The oslo.config implementation is in progress, while the Castellan
>> driver still needs to be written. We want to land this early in Rocky as
>> it is a significant change in architecture for oslo.config and we want
>> it to be well-exercised before release.
>>
>> There are discussions with the TripleO team around adding support for
>> this feature to its deployment tooling and there will be a functional
>> test job for the Castellan driver with Custodia.
>>
>> There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
>> UTC for discussion of this feature.
>>
>> oslo.config driver implementation: https://review.openstack.org/#/c/513844
>> spec:
>>
>> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
>>
>> Custodia key management support for Castellan:
>> https://review.openstack.org/#/c/515190/
>>
>> "stable" libraries
>> --
>>
>> Some of the Oslo libraries are in a mature state where there are very
>> few, if any, meaningful changes to them. With the removal of the
>> requirements sync process in Rocky, we may need to change the release
>> process for these libraries. My understanding was that there were no
>> immediate action items for this, but it was something we need to be
>> aware of.
>>
>> dropping support for mox3
>> -
>>
>> There was some concern that no one from the Oslo team is actually in a
>> position to support mox3 if something were to break (such as happened in
>> some libraries with Python 3.6). Since there is a community goal to
>> remove mox from all OpenStack projects in Rocky this will hopefully not
>> be a long-term problem, but there was some discussion that if projects
>> needed to keep mox for some reason that they would be asked to provide a
>> maintainer for mox3. This topic is kind of on hold pending the outcome
>> of the community goal this cycle.
>>
>> automatic configuration migration on upgrade
>> 
>>
>> There is a desire for oslo.config to provide a mechanism to
>> automatically migrate deprecated options to their new location on
>> version upgrades. This is a fairly complex topic that I can't cover
>> adequately in a summary email, but there is a spec proposed at
>> https://review.openstack.org/#/c/520043/ and POC changes at
>> https://review.openstack.org/#/c/526314/ and
>> https://review.openstack.org/#/c/526261/
>>
>> One outcome of the discussion was that in the initial version we would
>> not try to handle complex migrations, such as the one that happened when
>> we combined all of the separate rabbit connection opts into a single
>> connection string. To start with we will just raise a warning to the
>> user that they need to handle those manually, but a templated or
>> hook-based method of automating those migrations could be added as a
>> follow-up if there is sufficient demand.
>>
>> oslo.messaging plans
>> 
>>
>> There was quite a bit discussed under this topic. I'm going to break it
>> down into sub-topics for clarity.
>>
>> oslo.messaging heartbeats
>> =
>>
>> Everyone seemed to be in favor of this feature, so we anticipate
>> development moving forward in Rocky. There is an initial patch proposed
>> at https://review.openstack.org/546763
>>
>> We felt that it should be possible to opt in and out of the feature, and
>> that the configuration should be done at the application level. This
>> should _not_ be an operator decision as they do not have the knowledge
>> to make it sanely.
>>
>> There was also a desire to have a TTL for messages.
>>
>> bug cleanup
>> ===
>>
>> There are quite a few launchpad bugs open against oslo.messaging that
>> were reported against old, now unsupported versions. Since we have the
>> launchpad bug expirer enabled in Oslo the action item proposed for such
>> bugs was to mark them incomplete and ask the reporter to confirm that
>> they still occur against a supported version. This way bugs that don't
>> reproduce or where the reporter has lost interest will eventually be
>> closed automatically, but bugs that do still exist can be updated with
>> more current information.
>>
>> deprecations
>> 
>>
>> The Pika driver will be deprecated in Rocky. To our knowledge, no one
>> has ever used it and there are

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Ben Nemec]

On 03/08/2018 02:53 PM, Joshua Harlow wrote:


Can we get some of those doc links opened.

'You need permission to access this published document.' I am getting 
for a few of them :(


Shoot, I thought we fixed that but I guess we just projected them in the 
room from a laptop that had access.  I've copied the owners of the 
documents to see if they can open up the permissions.




Ben Nemec wrote:

Hi,

Here's my summary of the discussions we had in the Oslo room at the PTG.
Please feel free to reply with any additions if I missed something or
correct anything I've misrepresented.

oslo.config drivers for secret management
-

The oslo.config implementation is in progress, while the Castellan
driver still needs to be written. We want to land this early in Rocky as
it is a significant change in architecture for oslo.config and we want
it to be well-exercised before release.

There are discussions with the TripleO team around adding support for
this feature to its deployment tooling and there will be a functional
test job for the Castellan driver with Custodia.

There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
UTC for discussion of this feature.

oslo.config driver implementation: 
https://review.openstack.org/#/c/513844

spec:
https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html 



Custodia key management support for Castellan:
https://review.openstack.org/#/c/515190/

"stable" libraries
--

Some of the Oslo libraries are in a mature state where there are very
few, if any, meaningful changes to them. With the removal of the
requirements sync process in Rocky, we may need to change the release
process for these libraries. My understanding was that there were no
immediate action items for this, but it was something we need to be
aware of.

dropping support for mox3
-

There was some concern that no one from the Oslo team is actually in a
position to support mox3 if something were to break (such as happened in
some libraries with Python 3.6). Since there is a community goal to
remove mox from all OpenStack projects in Rocky this will hopefully not
be a long-term problem, but there was some discussion that if projects
needed to keep mox for some reason that they would be asked to provide a
maintainer for mox3. This topic is kind of on hold pending the outcome
of the community goal this cycle.

automatic configuration migration on upgrade


There is a desire for oslo.config to provide a mechanism to
automatically migrate deprecated options to their new location on
version upgrades. This is a fairly complex topic that I can't cover
adequately in a summary email, but there is a spec proposed at
https://review.openstack.org/#/c/520043/ and POC changes at
https://review.openstack.org/#/c/526314/ and
https://review.openstack.org/#/c/526261/

One outcome of the discussion was that in the initial version we would
not try to handle complex migrations, such as the one that happened when
we combined all of the separate rabbit connection opts into a single
connection string. To start with we will just raise a warning to the
user that they need to handle those manually, but a templated or
hook-based method of automating those migrations could be added as a
follow-up if there is sufficient demand.

oslo.messaging plans


There was quite a bit discussed under this topic. I'm going to break it
down into sub-topics for clarity.

oslo.messaging heartbeats
=

Everyone seemed to be in favor of this feature, so we anticipate
development moving forward in Rocky. There is an initial patch proposed
at https://review.openstack.org/546763

We felt that it should be possible to opt in and out of the feature, and
that the configuration should be done at the application level. This
should _not_ be an operator decision as they do not have the knowledge
to make it sanely.

There was also a desire to have a TTL for messages.

bug cleanup
===

There are quite a few launchpad bugs open against oslo.messaging that
were reported against old, now unsupported versions. Since we have the
launchpad bug expirer enabled in Oslo the action item proposed for such
bugs was to mark them incomplete and ask the reporter to confirm that
they still occur against a supported version. This way bugs that don't
reproduce or where the reporter has lost interest will eventually be
closed automatically, but bugs that do still exist can be updated with
more current information.

deprecations


The Pika driver will be deprecated in Rocky. To our knowledge, no one
has ever used it and there are no known benefits over the existing
Rabbit driver.

Once again, the ZeroMQ driver was proposed for deprecation as well. The
CI jobs for ZMQ have been broken for a while, and there doesn't seem to
be much interest in maintaining them. Fur

Re: [openstack-dev] [oslo] Oslo PTG Summary

[Joshua Harlow]

Can we get some of those doc links opened.

'You need permission to access this published document.' I am getting 
for a few of them :(


Ben Nemec wrote:

Hi,

Here's my summary of the discussions we had in the Oslo room at the PTG.
Please feel free to reply with any additions if I missed something or
correct anything I've misrepresented.

oslo.config drivers for secret management
-

The oslo.config implementation is in progress, while the Castellan
driver still needs to be written. We want to land this early in Rocky as
it is a significant change in architecture for oslo.config and we want
it to be well-exercised before release.

There are discussions with the TripleO team around adding support for
this feature to its deployment tooling and there will be a functional
test job for the Castellan driver with Custodia.

There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600
UTC for discussion of this feature.

oslo.config driver implementation: https://review.openstack.org/#/c/513844
spec:
https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html

Custodia key management support for Castellan:
https://review.openstack.org/#/c/515190/

"stable" libraries
--

Some of the Oslo libraries are in a mature state where there are very
few, if any, meaningful changes to them. With the removal of the
requirements sync process in Rocky, we may need to change the release
process for these libraries. My understanding was that there were no
immediate action items for this, but it was something we need to be
aware of.

dropping support for mox3
-

There was some concern that no one from the Oslo team is actually in a
position to support mox3 if something were to break (such as happened in
some libraries with Python 3.6). Since there is a community goal to
remove mox from all OpenStack projects in Rocky this will hopefully not
be a long-term problem, but there was some discussion that if projects
needed to keep mox for some reason that they would be asked to provide a
maintainer for mox3. This topic is kind of on hold pending the outcome
of the community goal this cycle.

automatic configuration migration on upgrade


There is a desire for oslo.config to provide a mechanism to
automatically migrate deprecated options to their new location on
version upgrades. This is a fairly complex topic that I can't cover
adequately in a summary email, but there is a spec proposed at
https://review.openstack.org/#/c/520043/ and POC changes at
https://review.openstack.org/#/c/526314/ and
https://review.openstack.org/#/c/526261/

One outcome of the discussion was that in the initial version we would
not try to handle complex migrations, such as the one that happened when
we combined all of the separate rabbit connection opts into a single
connection string. To start with we will just raise a warning to the
user that they need to handle those manually, but a templated or
hook-based method of automating those migrations could be added as a
follow-up if there is sufficient demand.

oslo.messaging plans


There was quite a bit discussed under this topic. I'm going to break it
down into sub-topics for clarity.

oslo.messaging heartbeats
=

Everyone seemed to be in favor of this feature, so we anticipate
development moving forward in Rocky. There is an initial patch proposed
at https://review.openstack.org/546763

We felt that it should be possible to opt in and out of the feature, and
that the configuration should be done at the application level. This
should _not_ be an operator decision as they do not have the knowledge
to make it sanely.

There was also a desire to have a TTL for messages.

bug cleanup
===

There are quite a few launchpad bugs open against oslo.messaging that
were reported against old, now unsupported versions. Since we have the
launchpad bug expirer enabled in Oslo the action item proposed for such
bugs was to mark them incomplete and ask the reporter to confirm that
they still occur against a supported version. This way bugs that don't
reproduce or where the reporter has lost interest will eventually be
closed automatically, but bugs that do still exist can be updated with
more current information.

deprecations


The Pika driver will be deprecated in Rocky. To our knowledge, no one
has ever used it and there are no known benefits over the existing
Rabbit driver.

Once again, the ZeroMQ driver was proposed for deprecation as well. The
CI jobs for ZMQ have been broken for a while, and there doesn't seem to
be much interest in maintaining them. Furthermore, the breakage seems to
be a fundamental problem with the driver that would require non-trivial
work to fix.

Given that ZMQ has been a consistent pain point in oslo.messaging over
the past few years, it was proposed that if someone does step fo

[openstack-dev] [oslo] Oslo PTG Summary

[Ben Nemec]

Hi,

Here's my summary of the discussions we had in the Oslo room at the PTG. 
 Please feel free to reply with any additions if I missed something or 
correct anything I've misrepresented.


oslo.config drivers for secret management
-

The oslo.config implementation is in progress, while the Castellan 
driver still needs to be written.  We want to land this early in Rocky 
as it is a significant change in architecture for oslo.config and we 
want it to be well-exercised before release.


There are discussions with the TripleO team around adding support for 
this feature to its deployment tooling and there will be a functional 
test job for the Castellan driver with Custodia.


There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600 
UTC for discussion of this feature.


oslo.config driver implementation: https://review.openstack.org/#/c/513844
spec: 
https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
Custodia key management support for Castellan: 
https://review.openstack.org/#/c/515190/


"stable" libraries
--

Some of the Oslo libraries are in a mature state where there are very 
few, if any, meaningful changes to them.  With the removal of the 
requirements sync process in Rocky, we may need to change the release 
process for these libraries.  My understanding was that there were no 
immediate action items for this, but it was something we need to be 
aware of.


dropping support for mox3
-

There was some concern that no one from the Oslo team is actually in a 
position to support mox3 if something were to break (such as happened in 
some libraries with Python 3.6).  Since there is a community goal to 
remove mox from all OpenStack projects in Rocky this will hopefully not 
be a long-term problem, but there was some discussion that if projects 
needed to keep mox for some reason that they would be asked to provide a 
maintainer for mox3.  This topic is kind of on hold pending the outcome 
of the community goal this cycle.


automatic configuration migration on upgrade


There is a desire for oslo.config to provide a mechanism to 
automatically migrate deprecated options to their new location on 
version upgrades.  This is a fairly complex topic that I can't cover 
adequately in a summary email, but there is a spec proposed at 
https://review.openstack.org/#/c/520043/ and POC changes at 
https://review.openstack.org/#/c/526314/ and 
https://review.openstack.org/#/c/526261/


One outcome of the discussion was that in the initial version we would 
not try to handle complex migrations, such as the one that happened when 
we combined all of the separate rabbit connection opts into a single 
connection string.  To start with we will just raise a warning to the 
user that they need to handle those manually, but a templated or 
hook-based method of automating those migrations could be added as a 
follow-up if there is sufficient demand.


oslo.messaging plans


There was quite a bit discussed under this topic.  I'm going to break it 
down into sub-topics for clarity.


oslo.messaging heartbeats
=

Everyone seemed to be in favor of this feature, so we anticipate 
development moving forward in Rocky.  There is an initial patch proposed 
at https://review.openstack.org/546763


We felt that it should be possible to opt in and out of the feature, and 
that the configuration should be done at the application level.  This 
should _not_ be an operator decision as they do not have the knowledge 
to make it sanely.


There was also a desire to have a TTL for messages.

bug cleanup
===

There are quite a few launchpad bugs open against oslo.messaging that 
were reported against old, now unsupported versions.  Since we have the 
launchpad bug expirer enabled in Oslo the action item proposed for such 
bugs was to mark them incomplete and ask the reporter to confirm that 
they still occur against a supported version.  This way bugs that don't 
reproduce or where the reporter has lost interest will eventually be 
closed automatically, but bugs that do still exist can be updated with 
more current information.


deprecations


The Pika driver will be deprecated in Rocky.  To our knowledge, no one 
has ever used it and there are no known benefits over the existing 
Rabbit driver.


Once again, the ZeroMQ driver was proposed for deprecation as well.  The 
CI jobs for ZMQ have been broken for a while, and there doesn't seem to 
be much interest in maintaining them.  Furthermore, the breakage seems 
to be a fundamental problem with the driver that would require 
non-trivial work to fix.


Given that ZMQ has been a consistent pain point in oslo.messaging over 
the past few years, it was proposed that if someone does step forward 
and want to maintain it going forward then we should split the dri