<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 9, 2015 at 2:15 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Angus Salkeld's message of 2015-04-06 19:55:37 -0700:<br>
<span class="">> Hi all<br>
><br>
> For quite some time we (Heat team) have wanted to be able to send messages<br>
> to our<br>
> users (by user I do not mean the Operator, but the User that is interacting<br>
> with the client).<br>
><br>
> What do I mean by "user messages", and how do they differ from our current<br>
> log messages<br>
> and notifications?<br>
> - Our current logs are for the operator and have information that the user<br>
> should not have<br>
>   (ip addresses, hostnames, configuration options, other tenant info etc..)<br>
> - Our notifications (that Ceilometer uses) *could* be used, but I am not<br>
> sure if it quite fits.<br>
>   (they seem a bit heavy weight for a log message and aimed at higher level<br>
> events)<br>
><br>
> These messages could be (based on Heat's use case):<br>
><br>
> - Specific user oriented log messages (distinct from our normal operator<br>
> logs)<br>
<br>
</span>These currently go in the Heat events API, yes?<br></blockquote><div><br></div><div>Well I wanted a replacement for our events table that could also take smaller messages<br></div><div>and fulfil some other use cases (be a stream, that the user doesn't have to poll).</div><div><br></div><div>We are sending RPC notifications at the moment: </div><div>stack.<action>.begin/end/error</div><div>autoscaling.begin/end/error</div><div><br></div><div>We need to add:</div><div>per resource notifications (to replace the event table)</div><div><br></div><div>Add some useful log-like messages:</div><div>"x property is deprecated, please update your template to use Y"</div><div><br></div><div>There are also a bunch of other log messages that should really be going to the user, but</div><div>just end up in the Operator's log file.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> - Deprecation messages (if they are using old resource properties/template<br>
> features)<br>
<br>
</span>I think this could fit with the bits above.<br>
<span class=""><br>
> - Progress and resource state changes (an application doesn't want to poll<br>
> an api for a state change)<br>
<br>
</span>These also go in the current Heat events.<br>
<span class=""><br>
> - Automated actions (autoscaling events, time based actions)<br>
<br>
</span>As do these?<br>
<span class=""><br>
> - Potentially integrated server logs (from in guest agents)<br>
><br>
> I wanted to raise this to "[all]" as it would be great to have a general<br>
> solution that<br>
> all projects can make use of.<br>
><br>
> What do we have now:<br>
> - The user can not get any kind of log message from services. The closest<br>
> thing<br>
>   ATM is the notifications in Ceilometer, but I have the feeling that these<br>
> have a different aim.<br>
> - nova console log<br>
> - Heat has a DB "event" table for users (we have long wanted to get rid of<br>
> this)<br>
<br>
</span>So if we forget the DB part of it, the API is also lacking things like<br>
pagination and search that one would want in an event/logging API.<br></blockquote><div><br></div><div>I'd almost rather spend the time getting an OpenStack wide solution then switch</div><div>our client (and API) to use that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> What do other clouds provide:<br>
> - <a href="https://devcenter.heroku.com/articles/logging" target="_blank">https://devcenter.heroku.com/articles/logging</a><br>
> - <a href="https://cloud.google.com/logging/docs/" target="_blank">https://cloud.google.com/logging/docs/</a><br>
> - <a href="https://aws.amazon.com/blogs/aws/cloudwatch-log-service/" target="_blank">https://aws.amazon.com/blogs/aws/cloudwatch-log-service/</a><br>
> - <a href="http://aws.amazon.com/cloudtrail/" target="_blank">http://aws.amazon.com/cloudtrail/</a><br>
> (other examples...)<br>
><br>
> What are some options we could investigate:<br>
> 1. remote syslog<br>
>     The user provides a rsyslog server IP/port and we send their messages<br>
> to that.<br>
>     [pros] simple, and the user could also send their server's log messages<br>
> to the same<br>
>               rsyslog - great visibility into what is going on.<br>
><br>
>               There are great tools like loggly/logstash/papertrailapp that<br>
> source logs from remote syslog<br>
>               It leaves the user in control of what tools they get to use.<br>
><br>
>     [cons] Would we become a spam agent (just sending traffic to an<br>
> IP/Port) - I guess that's how remote syslog<br>
>                works. I am not sure if this is an issue or not?<br>
><br>
>               This might be a lesser solution for the use case of "an<br>
> application doesn't want to poll an api for a state change"<br>
><br>
>               I am not sure how we would integrate this with horizon.<br>
><br>
<br>
</span>I think this one puts too much burden on the user to setup a good<br>
receiver.<br>
<span class=""><br>
> 2. Zaqar<br>
>     We send the messages to a queue in Zaqar.<br>
>     [pros] multi tenant OpenStack project for messaging!<br>
><br>
>     [cons] I don't think Zaqar is installed in most installations (tho'<br>
> please correct me here if this<br>
>                is wrong). I know Mirantis does not currently support Zaqar,<br>
> so that would be a problem for me.<br>
><br>
>               There is not the level of external tooling like in option "1"<br>
> (logstash and friends)<br>
><br>
<br>
</span>I agree with your con, and would also add that after the long<br>
discussions we had in the past we had some concerns about scaling.<br>
<span class=""><br>
> 3. Other options:<br>
>    Please chip in with suggestions/links!<br>
><br>
<br>
</span>There's this:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Cue" target="_blank">https://wiki.openstack.org/wiki/Cue</a><br>
<br>
I think that could be a bit like 1, but provide the user with an easy<br>
target for the messages.<br>
<br>
I also want to point out that what I'd actually rather see is that all<br>
of the services provide functionality like this. Users would be served<br>
by having an event stream from Nova telling them when their instances<br>
are active, deleted, stopped, started, error, etc.<br>
<br>
Also, I really liked Sandy's suggestion to use the notifications on the<br>
backend, and then funnel them into something that the user can consume.<br>
The project they have, yagi, for putting them into atom feeds is pretty<br>
interesting. If we could give people a simple API that says "subscribe<br>
to Nova/Cinder/Heat/etc. notifications for instance X, and put them<br>
in an atom feed", that seems like something that would make sense as<br>
an under-the-cloud service that would be relatively low cost and would<br>
ultimately reduce load on API servers.<br></blockquote><div><br></div><div>"an under-the-clould service" ? - That is not what I am after here. </div><div><br></div><div><br></div><div>What I am really after is a general OpenStack solution for how end users can</div><div>consume service notifications (and replace "heat event-list").</div><div><br></div><div><br></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><br></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>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>Maybe this needs to be a part of Cue?</div><div><br></div><div>-Angus</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>