Hi Zhou, The requirements for the request_refresh API call came from a customer. It wasn't intended as a replacement for the functionality we'd get by integrating with oslo.messaging. But it was a simple feature to add, with nice properties from Congress's perspective, driven by a real use case. It'd be great to support a more standard kind of streaming as well, such as with oslo.messaging.
Tim On Thu, Jun 18, 2015 at 11:10 PM Zhou, Zhenzan <zhenzan.z...@intel.com> wrote: > Hi, Tim > > > > I have looked at the request_fresh_action. One big question is that it > requires external services to queue up changes and then call this Congress > API at some point. I’m not sure they would buy in this design as many > projects have notification mechanism ready now and Ceilometer heavily > depends on these notifications. So basically I prefer to use > oslo.messaging. But this API is still useful for other external services > that don’t use oslo.messaging notification to publish changes and are > willing to integrate with Congress this way. > > Anyway, I can upload my draft bp for review at first. > > Thanks. > > > > BR > > Zhou Zhenzan > > > > *From:* Tim Hinrichs [mailto:t...@styra.com] > *Sent:* Wednesday, June 17, 2015 21:57 > > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [Congress] Mid-cycle sprint > > > > Hi Zhenzan, > > Yes the oslo.messaging integration task is relevant--oslo.messaging is one > way of achieving cross-process, cross-host messaging. So I'll count you as > interested for the mid-cycle sprint. > > > > Have you looked at the API call that forces a datasource driver to pull > immediately? See > congress/api/datasource_model.py:DatasourceModel.request_refresh_action. We > had envisioned using that to implement a kind of notification from external > services as follows. The external service queues up a list of changes and > when the queue is long enough runs the API call to force the datasource > driver hooked up to that service to pull those changes and then publish > them on the bus. So it's not exactly streaming updates from the external > service (which is good so that Congress can easily rate-limit updates), but > it has almost the same effect. > > > > Tim > > > > On Tue, Jun 16, 2015 at 6:02 PM Zhou, Zhenzan <zhenzan.z...@intel.com> > wrote: > > Hi, Tim > > > > Is this the oslo.messaging integration task? I’m interested in > participating. Actually I am working on a bp to receive notifications from > external services in datasource driver at first. I’m ok to change if the > direction is to integrate oslo.messaging thoroughly (even replacing DSE). > > Thanks. > > > > BR > > Zhou Zhenzan > > > > *From:* Tim Hinrichs [mailto:t...@styra.com] > *Sent:* Wednesday, June 17, 2015 05:14 > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [Congress] Mid-cycle sprint > > > > Hi all, > > > > In the last couple of IRCs we've been talking about running a mid-cycle > sprint focused on enabling our message bus to span multiple processes and > multiple hosts. The message bus is what allows the Congress policy engine > to communicate with the Congress wrappers around external services like > Nova, Neutron. This cross-process, cross-host message bus is the platform > we'll use to build version 2.0 of our distributed architecture. > > > > If you're interested in participating, drop me a note. Once we know who's > interested we'll work out date/time/location details. > > > > Thanks! > > Tim > > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
