[occi-wg] Events ?

Gary Mazz garymazzaferro at gmail.com
Tue May 19 15:51:14 CDT 2009


Well since this is a interoperability interface, I'm assuming there will 
be gateways to other technologies like fabrics. Events, event delivery 
and event management are important  patterns and are supported by 
others. I don't believe we'll be able to get away without supporting 
them for very long. One of the big drawbacks to snmp and cimoms are the 
lack of event support and an infrastructure to support event message 
persistence.

I'm also not sure where we are drawing the line in terms of 
interoperability. There was a general consensus that occi should be 
focusing on integration points in the cloud, but I didn't see a clear 
definition of an integration point. (I was out of the loop for a while) 
In  the occi model the platform can be considered a container (loosely, 
a vm) with infrastructure resources provisioned. The container life 
cycle and resource provisioning are "management" integration points, 
although there are no verbs published yet. 

Will portions of occi interface be permitted to permeate the container 
boundary ?  It is still unclear the level of interaction, if any, 
between the occi and the container contents. Maybe I missed the definition.

-gary





Alexis Richardson wrote:
> Indeed and XMPP and HTTP should not be overlooked either.
>
>
> On Tue, May 19, 2009 at 7:49 PM, Sam Johnston <samj at samj.net> wrote:
>   
>> On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson
>> <alexis.richardson at gmail.com> wrote:
>>     
>>> Interesting point.
>>>
>>> Speaking as someone who is professionally involved in messaging and
>>> events my STRONG advice would be to completely leave them for now.
>>> Implementation of the planned draft will naturally bring up use cases
>>> suited to the various eventing technologies and protocols, none of
>>> which are fully baked by the way.  This will be good fodder for future
>>> work but currently is **** not in scope ****.
>>>       
>> Agreed, and I don't know AMQP well enough to say how it could fit here.
>>
>> The use case we need to take away from it is that OCCI messages aren't
>> necessarily going to be ephemeral - they may well be long lived, queued,
>> serialised, saved to file, etc.
>>
>> Sam
>>
>>
>>     
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>   




More information about the occi-wg mailing list