[occi-wg] Events ?

[Alexis Richardson]

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 ****.

a


On Tue, May 19, 2009 at 5:53 PM, Roger Menday
<roger.menday at uk.fujitsu.com> wrote:
>
>
> On 19 May 2009, at 12:16, Gary Mazz wrote:
>
>>
>> You've got it...
>>
>> I do like the idea of long life messages and events. I think events
>> will
>> be important just from the perspective of well know programming
>> practices. I personally don't see unix signals going away for a long
>> while.
>>
>> Resources can change states for one reason or another. Networking and
>> storage (another network) are often victims of accidental switch
>> reconfigurations resulting in loss of connectivity to endpoints.
>>
>> Configuration changes to resources outside the scope of the "active
>> state" in the "life cycle model" may need to be logged or corrective
>> action may be engaged.
>>
>> Long life remote service dependencies are another area where events
>> may
>> be appropriate. Normally, I would suggest the applications handle
>> occurrences between parties, but with migration as a normal
>> circumstance, it may be out of control and scope of the parties.
>> Either
>> the infrastructure will handle a "pause for migration" event or the
>> container will tell the app which will tell the other party. Queuing
>> (a
>> bridge) may be a way to avoid the issue as long as the service
>> parameters are not violated. But it may be out of scope for
>> interoperability.
>>
>> Security or privilege revocation is another area. Hard execution
>> breaks
>> due to user or admin control is still another area.
>>
>> Polling may be inappropriate in many cases, driving up CPU loads and
>> network bandwidth consumption.
>>
>
> Going down the ATOM route, one does get a feed of events (cf. recent
> discussions related to holding the lifecycle of a resource as a
> collection of states in a feed). In addition, there are a number of
> approaches out there to alert interested parties to an updated feed,
> stopping relentless polling somewhat. I wonder if that is enough ?
>
> regards,
> Roger
>
>> I'll get them on the wiki in the later AM... I'm gmt -7
>>
>> -gary
>>
>> Sam Johnston wrote:
>>> On Mon, May 18, 2009 at 7:55 PM, Gary Mazz <garymazzaferro at gmail.com
>>> <mailto:garymazzaferro at gmail.com>> wrote:
>>>
>>>    Hi,
>>>
>>>     From the current discussions, there has been no mention of
>>>    events. Will
>>>    the occi support events ? What will the model look like ?
>>>
>>>
>>> This is something I had thought about a little but not considered a
>>> focus point for us. I did however consider the possibility of OCCI
>>> messages being long lived in that they can be queued and passed over
>>> transports like XMPP (this was one of a number of potential use cases
>>> for signatures).
>>>
>>> The interest in doing this would be, for example, a client that has
>>> rendered a number of resources and wants to know about state changes
>>> and the like. They would just need to subscribe to the resource and
>>> when the state changes they would be sent the updated entry.
>>> Similarly
>>> an management system could ask for regular updates of e.g.
>>> performance
>>> monitor counters.
>>>
>>> Does this sound adequate for your needs or do you have use case(s)
>>> that require more - and if so, why aren't they in the wiki ;)
>>>
>>> Sam
>>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> Roger Menday (PhD)
> <roger.menday at uk.fujitsu.com>
>
> Senior Researcher, Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
> Tel: +44 (0) 208 606 4534
>
>
> ______________________________________________________________________
>
>  Fujitsu Laboratories of Europe Limited
>  Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>  Registered No. 4153469
>
>  This e-mail and any attachments are for the sole use of addressee(s) and
>  may contain information which is privileged and confidential. Unauthorised
>  use or copying for disclosure is strictly prohibited. The fact that this
>  e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
>  not guarantee that it has not been intercepted or amended nor that it is
>  virus-free.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>