[occi-wg] Events ?
Gary Mazz
garymazzaferro at gmail.com
Tue May 19 06:16:56 CDT 2009
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.
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
>
More information about the occi-wg
mailing list