Open Stack

Basically I love the blueprints thrust.

I'd love to see a real spec for how to construct a proper openstack logging
event, and how to place those events into the message queue for
consumption.  Something that's more engineering spec then proverb.

That being said, a couple of things I'd like to see that I didn't see in
there just yet.  ( mind you i may have missed it, i am human after all )

1.  Standardized Metadata

Being able to parse a log for content with a known metadata structure would
be very helpful for folks planning on consuming logs in adaptive
orchestration scenarios.

2.  Message Service Etiquette

I think the 'logged events need to make sense' starts to get into the idea
of a common logging etiquette.  But there's the logical aspect beyond the
aesthetic.  I assume we'll probably want to force rate limiting of logging
should something start getting noisy.  I feel like that's something that
should be done before hitting the message bus and creating noise there.
Specifically I am thinking of the repetition of messages being condensed on
the app side before being pushed to the bus.

This of course calls into question should this ettiquette be different for
a WARN versus an ERROR?

3.  Audit Log Handling

This is probably outside scope.  Feel free to declare it so.  But once we
start talking audit logs we need to discuss what can and cannot be done to
an event before it gets signed ( yeah that would need to be discussed too )
and handed off to the audit log pipeline ( that doesn't exist yet ).

-Matt


On Wed, Apr 30, 2014 at 4:39 PM, Sean Dague <sean at dague.net> wrote:

> I'm trying to work up some drafts of logging guidelines that we can get
> agreement on and hopefully get all openstack projects to implement over
> time. In advance of the Juno summit I'd like to get feedback on drafts
> via the nova-specs process.
>
> The draft review is here - https://review.openstack.org/#/c/91446/
>
> Anyone is welcome to log into gerrit and provide feedback on what's
> there, including general comments on areas we should address which
> aren't there. I'll try to blend the feedback I get this week for at
> least one, if not 2 follow up drafts prior to summit.
>
> There is not a specific summit session for this, however if we've got a
> good working doc before the summit I was hoping we could bang out any
> sticky parts ad-hoc while there.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140430/0c6691ff/attachment.html>