<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:10pt;color:#000000;background-color:#FFFFFF;font-family:'Courier New',monospace;">
<div>>From: Angus Salkeld <asalkeld@mirantis.com></div>
<div>>Sent: Wednesday, April 8, 2015 8:24 PM</div>
<div>>To: OpenStack Development Mailing List (not for usage questions)</div>
<div>>Subject: Re: [openstack-dev] [all] how to send messages (and events) to our users</div>
<div>> </div>
<div>></div>
<div>>I also want to point out that what I'd actually rather see is that all</div>
<div>>of the services provide functionality like this. Users would be served</div>
<div>>by having an event stream from Nova telling them when their instances</div>
<div>>are active, deleted, stopped, started, error, etc.</div>
<div>></div>
<div>>Also, I really liked Sandy's suggestion to use the notifications on the</div>
<div>>backend, and then funnel them into something that the user can consume.</div>
<div>>The project they have, yagi, for putting them into atom feeds is pretty</div>
<div>>interesting. If we could give people a simple API that says "subscribe</div>
<div>>to Nova/Cinder/Heat/etc. notifications for instance X, and put them</div>
<div>>in an atom feed", that seems like something that would make sense as</div>
<div>>an under-the-cloud service that would be relatively low cost and would</div>
<div>>ultimately reduce load on API servers.</div>
<div>></div>
<div>>"an under-the-clould service" ? - That is not what I am after here. </div>
<div>></div>
<div><br>
</div>
<div>Yeah, we're using this as an "under cloud" service. Our notifications are only</div>
<div>consumed internally, so it's not a multi-tenant/SaaS solution.</div>
<div><br>
</div>
<div>></div>
<div>>What I am really after is a general OpenStack solution for how end users can<br>
</div>
<div>>consume service notifications (and replace "heat event-list").</div>
<div>></div>
<div>></div>
<div>>Right now there is "ceilometer event-list", but as some Ceilometer devs have said,</div>
<div>>they don't want to store every notification that comes.</div>
<div>></div>
<div>>So is the yagi + atom hopper solution something we can point end-users to?</div>
<div>>Is it per-tenant etc...</div>
<div><br>
</div>
<div>However, there is a team within Rax working on this SaaS offering: </div>
<div>Peter Kazmir and Joe Savak. I'll let them respond with their lessons on </div>
<div>AtomHopper, etc. </div>
<div><br>
</div>
<div>>Sandy, do you have a write up somewhere on how to set this up so I can experiment a bit?</div>
<div><br>
</div>
<div>Yagi: <a href="https://github.com/rackerlabs/yagi">https://github.com/rackerlabs/yagi</a> <br>
</div>
<div>AtomHopper: <a href="http://atomhopper.org/">http://atomhopper.org/</a>  (java warning)</div>
<div><br>
</div>
<div>The StackTach.v3 sandbox is DevStack-for-Notifications. It simulates </div>
<div>notifications (no openstack deploy needed) and it has Yagi set up to</div>
<div>consume them. There's also Vagrant scripts to get you going. <br>
</div>
<div><br>
</div>
<div><a href="http://www.stacktach.com/install.html">http://www.stacktach.com/install.html</a><br>
</div>
<div><a href="https://github.com/stackforge/stacktach-sandbox">https://github.com/stackforge/stacktach-sandbox</a><br>
</div>
<div><br>
</div>
<div>and some, slightly older, screencasts on the Sandbox here:<br>
</div>
<div><a href="http://www.stacktach.com/screencasts.html">http://www.stacktach.com/screencasts.html</a>​ <br>
</div>
<div><br>
</div>
<div>We're in the #stacktach channel, by all means ping us if you run into problems.</div>
<div>Or if a Hangout works better for you, just scream :)</div>
<div><br>
</div>
<div><br>
<br>
</div>
<p><br>
</p>
</body>
</html>