[occi-wg] OCCI-notifications

Mon Dec 22 17:29:59 EST 2014

In that case you create more notification links from the same source, and
distinct destinations. Their "meaning", i.e. the data transferred to a
specific destination, primarily depends from the destination. This is
opaque to the user, but the provider has all the info needed to setup the
communication.

Does this answer?

2014-12-22 22:04 GMT+01:00 Gary Mazz <garymazzaferro at gmail.com>:

>  Hi Augusto,
>
> In the current example, the events are directed to a single entity 3ook,
> supporting centralized reporting and control. In cases where decentralized
> management is required,  or multiple event endpoints are required, eg an
> independent auditor,  I don't see a clear path to multiple destinations.
> Am I missing something ?
>
> -gary
>
>
> On 12/22/2014 7:24 AM, Augusto Ciuffoletti wrote:
>
>  I've just pushed a revision of the doc trying to meet your comment:
> attached is the pdf. You find added content from line 112 to line 129, and
> in fig. 2.
>
>  How is it?
>
> 2014-12-20 22:17 GMT+01:00 Gary Mazz <garymazzaferro at gmail.com>:
>
>>  Hi Guys,
>>
>> Its been a while..
>>
>> The notification work  looks great !!
>>
>> Is there a capability to place notifications in a workflow/deployment
>> topology  ?
>>
>> cheers,
>> gary mazzaferro
>>
>>
>> On 9/16/2014 4:59 AM, Andy Edmonds wrote:
>>
>> Guys, here a summary of the KIS approaches as discussed at OGF42
>>
>>
>> https://docs.google.com/presentation/d/1x3_exe7RD6orOhwRajFNJwXxgV1zXHIZR0WU9NHw_pg/edit#slide=id.p
>>
>>  Andy
>>
>>  Andy Edmonds Æ
>> Senior Researcher, ICCLab
>> Institute of Information Technology
>> Zürich University of Applied Sciences
>> http://www.cloudcomp.ch, @dizz
>>
>> On 16 September 2014 12:17, Augusto Ciuffoletti <augusto at di.unipi.it>
>> wrote:
>>
>>>   I agree with you that notification should be considered as a model,
>>> as an extension that introduces new resources and links, just like IaaS
>>> Infrastructure. I guess that this gives us all the tools to produce an
>>> effective model, without the side effects of introducing new core concepts.
>>>
>>>  I do not agree about the limitations you address: this depends on how
>>> we model the relevant concepts. If we'd use mixins, you could associate
>>> them virtually to anything, but for the same reason they are weak in
>>> formulating recommendations. So it is really relevant to use the right tool
>>> for a given task.
>>>
>>>  I hope to be able to propose my idea about that by the beginning of the
>>> next week. Suggestions are always welcome.
>>>
>>>  Augusto
>>>
>>>  PS: thanks to all organizers and participants to the OGF sessions, for
>>> a very productive and exciting meeting. In these times it is hard to find
>>> one :-/
>>>
>>> 2014-09-16 10:10 GMT+02:00 Jean Parpaillon <jean.parpaillon at free.fr>:
>>>
>>>> Hi Augusto, all,
>>>> Thanks for all the interesting discussions in OGF, first.
>>>>
>>>> Regarding the notifications, we discussed 2 approaches:
>>>> - the first include the notion of notification into the meta-model, with
>>>> versions of it in each rendering/protocol
>>>> - the second one add categories for a notification system, hence a model
>>>>
>>>> IMO, the second approach, hence simpler, has the problem of being
>>>> limited to notifications on resources. I don't see how to plug
>>>> notifications on collections, links or user mixins, for instance.
>>>>
>>>> Have I missed somthing ?
>>>>
>>>> Another possible approach should be to consider notifications only at
>>>> the level of protocol, not touching meta-model.
>>>>
>>>> My opinion is we should first think about at which level we want to
>>>> introduce this notion of notifications.
>>>>
>>>> Regards,
>>>> Jean
>>>>
>>>>
>>>> Le jeudi 11 septembre 2014 à 10:05 +0100, Augusto Ciuffoletti a écrit :
>>>>  > Dear all,
>>>> >
>>>> >
>>>> > talking and listening to people here during OGF42, I perceived that
>>>> > there is a strong demand for a notification mechanism inside OCCI,
>>>> > that is able to carry an asynchronous notification about a relevant
>>>> > event. For instance, "this job is now running" from an hypothetical
>>>> > job resource, or "this VM is going to shut down in 5 seconds" from a
>>>> > Compute.
>>>> >
>>>> > This demand is in fact more compelling than that about monitoring, and
>>>> > may be in fact integrated in OCCI-monitoring at a later time. So I'll
>>>> > give precedence to OCCI-Notification.
>>>> >
>>>> >
>>>> > The specification is very simple: one single link ("Notification"),
>>>> > and two types of mixins, one for the triggering event, one for the
>>>> > triggered action.
>>>> >
>>>> >
>>>> > Any "thumb up" or input from you is relevant, and I will submit soon a
>>>> > proposal about that.
>>>> >
>>>> > --
>>>> > Augusto Ciuffoletti
>>>> > Dipartimento di Informatica
>>>> > Università di Pisa
>>>> > 56100 - Pisa (Italy)
>>>>  > _______________________________________________
>>>> > occi-wg mailing list
>>>> > occi-wg at ogf.org
>>>> > https://www.ogf.org/mailman/listinfo/occi-wg
>>>>
>>>> --
>>>> Jean Parpaillon
>>>> Open Source Consultant
>>>> Phone: +33 6 30 10 92 86 <%2B33%206%2030%2010%2092%2086>
>>>> im: jean.parpaillon at gmail.com
>>>> skype: jean.parpaillon
>>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en
>>>>
>>>>
>>>
>>>
>>> --
>>> Augusto Ciuffoletti
>>> Dipartimento di Informatica
>>> Università di Pisa
>>> 56100 - Pisa (Italy)
>>>
>>
>>
>>
>> _______________________________________________
>> occi-wg mailing listocci-wg at ogf.org
>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>
>
> --
> Augusto Ciuffoletti
> Dipartimento di Informatica
> Università di Pisa
> 56100 - Pisa (Italy)
>
>

-- 
Augusto Ciuffoletti
Dipartimento di Informatica
Università di Pisa
56100 - Pisa (Italy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20141222/887d1f98/attachment-0001.html>