[openstack-dev] [all] how to send messages (and events) to our users
flavio at redhat.com
Wed Apr 8 13:29:00 UTC 2015
On 07/04/15 12:55 +1000, Angus Salkeld wrote:
>For quite some time we (Heat team) have wanted to be able to send messages to
>users (by user I do not mean the Operator, but the User that is interacting
>with the client).
>What do I mean by "user messages", and how do they differ from our current log
>- Our current logs are for the operator and have information that the user
>should not have
> (ip addresses, hostnames, configuration options, other tenant info etc..)
>- Our notifications (that Ceilometer uses) *could* be used, but I am not sure
>if it quite fits.
> (they seem a bit heavy weight for a log message and aimed at higher level
>These messages could be (based on Heat's use case):
>- Specific user oriented log messages (distinct from our normal operator logs)
>- Deprecation messages (if they are using old resource properties/template
>- Progress and resource state changes (an application doesn't want to poll an
>api for a state change)
>- Automated actions (autoscaling events, time based actions)
>- Potentially integrated server logs (from in guest agents)
>I wanted to raise this to "[all]" as it would be great to have a general
>all projects can make use of.
>What do we have now:
>- The user can not get any kind of log message from services. The closest thing
> ATM is the notifications in Ceilometer, but I have the feeling that these
>have a different aim.
>- nova console log
>- Heat has a DB "event" table for users (we have long wanted to get rid of
>What do other clouds provide:
>What are some options we could investigate:
>1. remote syslog
> The user provides a rsyslog server IP/port and we send their messages to
> [pros] simple, and the user could also send their server's log messages to
> rsyslog - great visibility into what is going on.
> There are great tools like loggly/logstash/papertrailapp that
>source logs from remote syslog
> It leaves the user in control of what tools they get to use.
> [cons] Would we become a spam agent (just sending traffic to an IP/Port) -
>I guess that's how remote syslog
> works. I am not sure if this is an issue or not?
> This might be a lesser solution for the use case of "an
>application doesn't want to poll an api for a state change"
> I am not sure how we would integrate this with horizon.
> We send the messages to a queue in Zaqar.
> [pros] multi tenant OpenStack project for messaging!
> [cons] I don't think Zaqar is installed in most installations (tho' please
>correct me here if this
> is wrong). I know Mirantis does not currently support Zaqar, so
>that would be a problem for me.
This is, unfortunately, true. However, adoption needs to start
somewhere and I believe this would be a good thing to use Zaqar for.
Kilo was a heads-down cycle for the Zaqar team but I believe we could
help out with making this happen in heat during Liberty.
At the Kilo summit, we discussed what was needed for Heat to consume
Zaqar and we've completed some of those features. I'm saying this to
highlight that Zaqar is now closer to Heat's needs.
> There is not the level of external tooling like in option "1"
>(logstash and friends)
True again :(
There's an almost-complete puppet manifest but other than that, tools
are yet to be built.
With my Zaqar hat on, I hope we can make this happen and any help on
tools/adoption is more than appreciated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev