> > 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 <jaypi...@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 <degore...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best Regards, Egorenko Denis, Deployment Engineer Mirantis
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
