Open Stack

>
> Denis, I actually don't think that Swift needs to use oslo.messaging at
> all. The middleware loads the rabbit configuration for the Notifier class
> from the CONF object here:
>
> https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L112
> and that conf object should use the config file sections that
> oslo_messaging relies on, right? So, this should really just require a
> change to the swift-proxy conf files to add the [oslo_messaging] sections,
> I think?


Well, yes, it make sense. Current scheme supports only one RabbitMQ node
with url parameter. If there exists possibility use some kind of
oslo_messaging/rabbit_hosts - i'm ok with such approach.

2015-12-01 19:30 GMT+03:00 Jay Pipes <jaypipes at gmail.com>:

> On 12/01/2015 08:17 AM, Richard Hawkins wrote:
>
>> ​Is it possible to write the functionality you desire in your
>> own middleware for Swift that lives outside of the Swift code?  I would
>> favor that approach for the following reasons:
>>
>> * You would have more control over code/changes so your middleware could
>> stabilize and mature faster (don't have to wait for reviews from
>> community for minor tweaks).
>>
>> * Since you are writing it, you get exactly what you want.
>>
>> * Swift would not gain more dependancies that would have to be installed.
>>
>> There have been a few projects in the past that have been successful
>> middleware without being included (swauth, swift3, swift-informant).
>>
>> And in the end, if your middleware becomes wildly successful and
>> everybody uses it, there would be no reason it could not be merged into
>> the Swift code at a later time.​
>>
>
> It's not Denis' middleware. It's the Ceilometer community's middleware for
> Swift to emit notification payloads that Ceilometer understands:
>
> https://github.com/openstack/ceilometermiddleware
>
> Denis, I actually don't think that Swift needs to use oslo.messaging at
> all. The middleware loads the rabbit configuration for the Notifier class
> from the CONF object here:
>
>
> https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L112
>
> and that conf object should use the config file sections that
> oslo_messaging relies on, right? So, this should really just require a
> change to the swift-proxy conf files to add the [oslo_messaging] sections,
> I think?
>
> Best,
> -jay
>
> Thanks,
>> Richard Hawkins
>> Software Developer - Cloud Files (OpenStack Swift)
>> Rackspace
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Denis Egorenko <degorenko at mirantis.com>
>> *Sent:* Tuesday, December 1, 2015 3:47 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift
>>
>> going to support oslo.messaging?
>> Hello folks,
>>
>> The issue I want to raise is related to Swift and Oslo.messaging.
>> Currently Swift doesn't support oslo.messaging middleware. There is no
>> possible to setup RabbitMQ HA setup in swift configuration, so we faced
>> the problem [1] in Fuel. If we want to use Ceilometer notifications for
>> Swift, we should use ceilometermiddleware. It provides possibility
>> configure properly transport settings for notifications [2]. The main
>> problem that Fuel uses HA RabbitMQ setup (mirrored queues) with direct
>> connection from clients. The client uses oslo.messaging to establish the
>> connection with one of rabbitmq servers. oslo.messaging uses heartbeats
>> to switch to another RabbitMQ server if/when there are any network
>> issues. However, Swift doesn't use oslo.messaging at all. It's possible
>> to specify only one RabbitMQ server in swift configuration hence there
>> can be problems if specified server is down or has network flapping
>> issues. Alternative solution is to use VIP for RabbitMQ [3]. This setup
>> is not perfect also as timeout and connection restore time is much worse.
>>
>> So, the question is:
>> Is Swift going to support oslo.messaging and particularly rabbit_hosts?
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1510064
>> [2] https://review.openstack.org/#/c/152273
>> [3] https://review.openstack.org/#/c/248147
>>
>> --
>> Best Regards,
>> Egorenko Denis,
>> Deployment Engineer
>> Mirantis
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Egorenko Denis,
Deployment Engineer
Mirantis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/426d6c7f/attachment.html>