SSM: Start implementation for first year PoC

[tsoenen]

@mpeuster @mehraghdam @smendel @stevenvanrossem @wtaverni @adrian-rosello @shuaibsiddiqui @DarioValocchi @pkarkazis : Hi all!

Since performing scaling / using SSMs is part of our year1 goal, I tried to make a simplified MSC/workflow that could lead to a first simple implementation: http://wiki.sonata-nfv.eu/index.php/MSC_Kernel_US_Service_Scaling_Simple_First_Iteration#Explanation

Could you go through it and highlight missing links? Especially for the monitoring (the SP side) and the infrastructure adapter, are these suggestions doable, or am I assuming functionality that is not there yet?

To speed up the process on this, we could hold a call somewhere in the next couple of days.

[smendel]

+1 for a call to further discuss the MSC and implementation.

[DarioValocchi]

:+1: I will answer the doodle! :smiley:

[jbonnet]

@tsoenen Is really scaling part of our Y1 goal? :-(

[wtaverni]

It is in the storyboard, and I believe it is a good idea to at least discuss possibilities? I believe a very simple scenario/showcase would be very nice to kickstart work in y2

[tsoenen]

@jbonnet : According to this storyboard (http://wiki.sonata-nfv.eu/index.php/StoryboardYear1), it is:p

Let's see what is possible.

[jbonnet]

@tsoenen I see it there, but those are very high level wishes, I don't think it's feasible to implement, at least for the general case and on the SP side.

[tsoenen]

@jbonnet : I think we can demonstrate the power of SSMs with minimal effort, building on what we have. The MSC in http://wiki.sonata-nfv.eu/index.php/MSC_Kernel_US_Service_Scaling_Simple_First_Iteration describes my view on this. The two blocking points would be whether we are able to monitor a certain metric, and whether the IA can handle a change in service graph. Everything else can be hidden inside the SSM, which for now could just be another plugin.

[mpeuster]

@tsoenen Faking a SSM by just let it be another plugin is a great and simple idea as long as we don't have the "real" SSM interface + boarding mechanics in place.

I support this idea.

[tsoenen]

@mpeuster : I think we could do the boarding mechanism the same way we are currently deploying the SLM in the unittests. We add the SSM code (even multiple SSMs can be added this way) to the SLM dockerfile, which enables us to deploy/destruct each SSM from within the SLM easily. An extra 'SSM' key to the NSD dictionary can be the trigger to deploy or not.

[mpeuster]

@tsoenen Yes, for a temporary solution this should work. Later, a SSM should be a Dockercontainer itself that is started by the executive plugin (e.g. the SLM or placement plugin).

Maybe we can even already do this? I think we can access the Docker API from within the e.g. SLM container and run a SSM as a second container besides the SLM. (Of curse, this does not clearly separate the environments in which platform containers and SSM containers are executed but its ok for a prototype).

[smendel]

The issue is outdated and does not reflect the current plan for the first year demo.