This event has ended. Create your own event → Check it out
This event has ended. Create your own
View analytic
Tuesday, May 19 • 11:15am - 11:55am
Cross Project workshops: Asynchronous status updates to users

Sign up or log in to save this to your schedule and see who's attending!

For quite some time the Heat team has wanted to be able to send messages to our 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 messages and notifications?

- 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 events)

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 features)
- 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)

What do we have now:
- The user can not get any kind of log message or notification from services.
- nova console log
- Heat has a DB ""event"" table for users (we have long wanted to get rid of this)

What do other clouds provide:
- https://devcenter.heroku.com/articles/logging
- https://cloud.google.com/logging/docs/
- https://aws.amazon.com/blogs/aws/cloudwatch-log-service/
- http://aws.amazon.com/cloudtrail/
(other examples...)

This session doesn't just apply to Heat. There are many asyncronous operations an API user can perform that may fail without the user being able to understand why without calling support or having access to logs. Very few resources among all the OpenStack projects handle reporting errors to end users for asynchronous operations (Cinder volume creation, Glance Image snapshots, etc) and those that do are inconsistent with each other. This session would discuss a standard way for APIs to handle this as there are a lot of options to choose from and many APIs that do not tackle the problem at all.

Moderators: asalkeld, ameade

Tuesday May 19, 2015 11:15am - 11:55am
Room 213-214
  • format json

Attendees (94)