Open Stack

That’s a good question. IMO, this is an important use case, and should be considered within scope of the project.

Rackspace uses a precursor to Marconi for its Cloud Backup product, and it has worked out well for showing semi-realtime updates, e.g., progress on an active backup jobs. We have a large number of backup agents posting events at any given time. The web-based control panel polls every few seconds for updates, but the message service was optimized for frequent, low-traffic requests like that, so it hasn’t been a real problem.

I’ve tried to promote a performance-oriented mindset from the beginning of the Marconi project, and I would like to give a shout-out to the team for the fine work they’ve done in this area to date; queues scale quite well, and benchmarks have shown promising throughput and latency numbers that will only improve as we continue to tune the existing code (and add transport and storage drivers designed for ultra-high-throughput use cases).

That being said, we definitely need to consider the load on the various OpenStack components, themselves, for generating events (i.e., pushing events to a queue). I would love to learn more about the requirements of individual project teams in this respect (those who are interested in surfacing events to end users).

From: Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>>
Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, December 4, 2013 at 8:30 AM
To: OpenStack Dev <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [ceilometer] [marconi] Notifications brainstorming session tomorrow @ 1500 UTC

How frequent do you imagine these notifications being?  There's a wide variation here between the 'blue moon' case where disk space is low and frequent notifications of things like OS performance, which you might want to display in Horizon or another monitoring tool on an every-few-seconds basis, or instance state change, which is usually driven by polling at present.

I'm not saying that we should necessarily design notifications for the latter cases, because it introduces potentially quite a lot of user-demanded load on the Openstack components, I'm just asking for a statement of intent.
--
Ian.


On 4 December 2013 16:09, Kurt Griffiths <kurt.griffiths at rackspace.com<mailto:kurt.griffiths at rackspace.com>> wrote:
Thanks! We touched on this briefly during the chat yesterday, and I will
make sure it gets further attention.

On 12/3/13, 3:54 AM, "Julien Danjou" <julien at danjou.info<mailto:julien at danjou.info>> wrote:

>On Mon, Dec 02 2013, Kurt Griffiths wrote:
>
>> Following up on some conversations we had at the summit, I¹d like to get
>> folks together on IRC tomorrow to crystalize the design for a
>>notifications
>> project under the Marconi program. The project¹s goal is to create a
>>service
>> for surfacing events to end users (where a user can be a cloud app
>> developer, or a customer using one of those apps). For example, a
>>developer
>> may want to be notified when one of their servers is low on disk space.
>> Alternatively, a user of MyHipsterApp may want to get a text when one of
>> their friends invites them to listen to That Band You¹ve Never Heard Of.
>>
>> Interested? Please join me and other members of the Marconi team
>>tomorrow,
>> Dec. 3rd, for a brainstorming session in #openstack-marconi at 1500
>>
>>UTC<http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&se
>>c=0>.
>> Your contributions are crucial to making this project awesome.
>>
>> I¹ve seeded an etherpad for the discussion:
>>
>> https://etherpad.openstack.org/p/marconi-notifications-brainstorm
>
>This might (partially) overlap with what Ceilometer is doing with its
>alarming feature, and one of the blueprint our roadmap for Icehouse:
>
>  https://blueprints.launchpad.net/ceilometer/+spec/alarm-on-notification
>
>While it doesn't solve the use case at the same level, the technical
>mechanism is likely to be similar.
>
>--
>Julien Danjou
># Free Software hacker # independent consultant
># http://julien.danjou.info


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/088094bf/attachment.html>