Open Stack

On 9/3/2014 11:32 AM, Chris Dent wrote:
> On Wed, 3 Sep 2014, Sandy Walsh wrote:
>
>> We're chatting with IBM about CADF and getting down to specifics on
>> their applicability to notifications. Once I get StackTach.v3 into
>> production I'm keen to get started on revisiting the notification
>> format and olso.messaging support for notifications.
>>
>> Perhaps a hangout for those keenly interested in doing something about this?
> That seems like a good idea. I'd like to be a part of that.
> Unfortunately I won't be at summit but would like to contribute what
> I can before and after.
>
> I took some notes on this a few weeks ago and extracted what seemed
> to be the two main threads or ideas the were revealed by the
> conversation that happened in this thread:
>
>      * At the micro level have versioned schema for notifications such that
>        one end can declare "I am sending version X of notification
>        foo.bar.Y" and the other end can effectively deal.

Yes, that's table-stakes I think. Putting structure around the payload
section.

Beyond type and version we should be able to attach meta information
like public/private visibility and perhaps hints for external mapping
(this trait -> that trait in CADF, for example).

>      * At the macro level standardize a packaging or envelope of all
>        notifications so that they can be consumed by very similar code.
>        That is: constrain the notifications in some way so we can also
>        constrain the consumer code.
That's the intention of what we have now. The top level traits are
standard, the payload is open. We really only require: message_id,
timestamp and event_type. For auditing we need to cover Who, What, When,
Where, Why, OnWhat, OnWhere, FromWhere.

>      These ideas serve two different purposes: One is to ensure that
>      existing notification use cases are satisfied with robustness and
>      provide a contract between two endpoints. The other is to allow a
>      fecund notification environment that allows and enables many
>      participants.
Good goals. When Producer and Consumer know what to expect, things are
good ... "I know to find the Instance ID <here>". When the consumer
wants to deal with a notification as a generic object, things get tricky
("find the instance ID in the payload", "What is the image type?", "Is
this an error notification?")

Basically, how do we define the principle artifacts for each service and
grant the consumer easy/consistent access to them? (like the 7-W's above)

I'd really like to find a way to solve that problem.

> Is that a good summary? What did I leave out or get wrong?
>

Great start! Let's keep it simple and do-able.

We should also review the oslo.messaging notification api ... I've got
some concerns we've lost our way there.

-S