Alternative implementation for Service Flavor when hosting policy is LOCAL

[fracappa]

Hi everyone.

I want to highlight that the current implementation has some drawbacks that are worth them to stress.

In the Service Flavor implementation, the Consumer can choose whether running the provided Service locally or remotely through the field hostingPolicy.

When the Consumer chooses to run it locally (hostingPolicy=local), in the current implementation we have the following scenario:

Basically, the provider intrinsically setup a Liqo peering within the Reservation phase so it can offload its application.

However, this situation can lead to the following issues:

• The Consumer could not have enough resources to host the offloaded applications
• The security infrastructure that should be upon the whole FLUIDOS Node architecture is not used (Verifiable Credentials, etc.) as the peering is set automatically
• The REAR protocol is broken as we're introducing new interactions within the standard workflow

As such, what I suggest to do it is to have a behavior like the following:

Here, the Consumer can basically ask a Service with hostingPolicy=true only if it already offers a Peering to the Provider at issue.

In my opinion, this would be a cleaner as well as a safer approach to implement this use case.

Eager to receive any feedback.

Regards,
Francesco

[LorenzoMoro]

Ok, so if I got it right, you're suggesting to subordinate a Service Flavor consumption to another Flavor (which kind?) consumption already solved and with a peering established, do you?

I agree with the cleaner and safer approach, but I can hardly map it into a use case workflow:

• the consumer needs to host a service offered by the provider;
• it somehow offers the provider a flavor mapping its resources it will have to reserve for the service runtime;
• it somehow solicitates the provider to consume this flavor, creating a solver and going through the whole regular REAR workflow, eventually establishing the peering;
• it consumes the service flavor offered by the provider and the the workflow continues as already described.

Seems to me a little cumbersome.

[fracappa]

Hi @LorenzoMoro .

Yes, the workflow that you have is overall aligned with what I'm proposing but there is a detail to take into account.

The Service Flavor consumption on the consumer cluster is only possible if the provider already had a peering, but this is something done in a previous and separated negotiation.; it's not something triggered when requiring a Service flavor is asked from the consumer.

However. this could potentially be a discussion to be put off once we have Liqo 1.0.0 integrated as it could solve lots of issues we're having with the current version, which also affects this specific use case.

Anyways, I believe it's useful if we start brainstorming about it.