FlowObjectiveEvent vs blocking manager requests

[Jordi Ortiz]

Hi all,

To the best of my knowledge there is no FlowObjectiveEvent to know wether a FlowObjective has been installed or not, so no app can listen as it can do with e.g, FlowRuleEvent, LinkEvent, ...

To me it makes sense from the point of view of coordination of the different abstractions. Let me put an example:
I create a FlowObjective that uses a Meter and outputs to a Group to multiple ports. That means that the flow objective can not be created until the meter and the group is in place, or the device will complain. But let's look at the other way around, for removing that Meter/Group I have to first remove the FlowObjective and I'll never know when that is done.

This problem is generated because of the Services mechanism writing to Stores which is non-blocking for apps. The Manager/Service writes into a Store and afterwards the system takes care of converting the stored request into openflow messages but the app continues with its work assuming that the request was granted (which might be not)

May be I'm doing things complicated but to me right now it is not clear how to synchronise the different Abstractions from an App.

One way is to have also an store in the app and make it react based on events, but for that I will need the FlowObjectiveEvent.

Does all of this make sense to you?

Regards
Jordi

[Jonathan Hart]

Hi Jordi,

There is a way you can get some feedback on the success or failure of a FlowObjective even in the current system. FlowObjectives have add(ObjectiveContext) and remove(ObjectiveContext) methods. The ObjectiveContext you provide will be called when the flow objective either succeeds or fails.

Is that good enough for your use case?

Thanks,

Jono

--
You received this message because you are subscribed to the Google Groups "ONOS Deployments Brigade" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brigade-deploym...@onosproject.org.
To post to this group, send email to brigade-d...@onosproject.org.
Visit this group at https://groups.google.com/a/onosproject.org/group/brigade-deployments/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/brigade-deployments/20170714101639.1dce5d1f%40JORDI-LENOVO.
For more options, visit https://groups.google.com/a/onosproject.org/d/optout.

[Jordi Ortiz]

Hi,

On Fri, 14 Jul 2017 23:30:52 +0000
Jonathan Hart <jo...@onlab.us> wrote:

> Hi Jordi,
>
> There is a way you can get some feedback on the success or failure of a
> FlowObjective even in the current system. FlowObjectives have
> add(ObjectiveContext) and remove(ObjectiveContext) methods. The
> ObjectiveContext you provide will be called when the flow objective either
> succeeds or fails.
>
> Is that good enough for your use case?

Thanks, indeed it is.

I think that works for the removal, when the meter removal depends on having removed the related flows.

For the addition, i.e: when the flows depend on meter creation, I have used CompletableFuture. So the meter request is a CompletableFuture that on complete() launchs the FlowObjective creation. It "works" but not sure how to handle errors. Meaning that if a CompletableFuture fails not sure how to abort the whole service creation since other FlowObjectives of the service have been created while waiting for the meter.


Regards
Jordi

--
Jordi Ortiz
jordi.o...@gmail.com
(+34)868888532
http://webs.um.es/jordi.ortiz/
Dpto. Ingeniería de la Información y las Comunicaciones
Universidad de Murcia

[Jonathan Hart]

Hi Jordi,

Sorry, not sure of a nice way to handle that. You might just have to manually roll things back if you detect that one of the operations failed.

Thanks,

Jono

To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/brigade-deployments/20170717145629.4da9a29d%40JORDI-LENOVO.