On May 11, 2011, at 10:47 AM, Matt Dietz wrote:
Hey Seshu,
1) Yes, that will be contained within the publisher_id field of the message body
2) We should be able to get customer related data from the message where it
makes sense. It would be contained within the payload dictionary. Given that
On May 10, 2011, at 11:07 AM, Matt Dietz wrote:
Alright, I'll buy it. Simply adding a UUID would be trivial
Cool.
Regarding categories, I tend to agree with Jay on this. I think it would
be treacherous to try to account for any number of possibilities, and I
also think that we need to keep
@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] Notifications proposal
I think notifications need to be kept really simple. I put out a proposal a few
months ago at:
http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html
Let the subscribers do any heavy
@lists.launchpad.net
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] Notifications proposal
I came into the conversation late and it struck me this proposal was a bit
heavier than what I was proposing.
I agree with letting something outside of Nova do the heavy
Hi George,
Understood, but burrow can act as both. At the core, the difference
between SQS and SNS are notification workers and a lower default
message TTL. Matt mentioned that Nova will push to RabbitMQ or some
other MQ and workers pull from the queue to translate into PuSH, email,
sms, etc. If
For the record, I should also say I think RabbitMQ is awesome and
should be used for deployments where it makes sense. Keeping it
modular and also allowing burrow to be an option will make more sense
for some deployments.
-Eric
On Tue, May 10, 2011 at 07:52:55PM +, Matt Dietz wrote:
For the
Hey guys,
Monsyne Dragon and myself are proposing an implementation for notifications
going forward. Currently my branch exists under
https://code.launchpad.net/~cerberus/nova/nova_notifications. you'll see that's
it been proposed for merge, but we're currently refactoring it around changes
On May 9, 2011, at 5:20 PM, Matt Dietz wrote:
Message example:
{ 'publisher_id': 'compute.host1',
'timestamp': '2011-05-09 22:00:14.621831',
'priority': 'WARN',
'event_type': 'compute.create_instance',
'payload': {'instance_id': 12, ... }}
There was a lot of concern
On May 9, 2011, at 6:39 PM, Matt Dietz wrote:
Jorge,
Thanks for the feedback!
Regarding the message format, we actually don't need the unique id in the
generic event format because that's implementation specific. The external
publisher I've implemented actually does all of the
9 matches
Mail list logo
