Infrabstract - MANO Framework APIs for initial implmentaion of year 1

[smendel]

In the simple service deployment flow the SLM will invoke the Infrabstract to translate the NSD to the relevant VIM deployment script , then deploy the service, and will expect a deployment final status response. This API needs to be defined, and its use should be implemented in the SLM. Derived from:

23

https://github.com/sonata-nfv/son-sp-infrabstract/issues/2 @smendel @shuaibsiddiqui @tsoenen @vidalenc @DarioValocchi

[tsoenen]

Hi all!

Since the Infra. Adapter will not be handling NSDs in the fully integrated version, I suggest we avoid making code for that now which we will not be using later. Therefore, I think the SLM should process the NSD/VNFDs and send the service graph with the VNF image urls to the Infra. Adapter.

Once placement is added to the Mano framework, by the point the request arrives at the Infra. Adapter, it is already decided which VNF should be deployed on which device and how exactly to connect them. In this simplified version, this is not the case. What component is going to decide where to place the VNFs in this simplified version?

[jbonnet]

@tsoenen If we use OpenStack and only one site (PoP), OpenStack can (as far as I know) decide the placement (i.e., just choose the physical machine). But this must be checked by WP6

[DarioValocchi]

@tsoenen moreover, I don't know to what extent a placement plugin that can be added to the SP will have a "per machine" view, being an adaptor in between which masquerade the specific VIM through wHich the machines are used. Actually there are tre level of abstraction: the Hypervisor, the VIM and the SP platform.

Anyway, the "skeleton" i'm preparing is API indipendend, more or less what manuel has done for the mano-plugins, but following arch discussed in the wiki. I'm working on "containarize" it, and than I will upload a first version on the repo. We can use it as a basis for defining the API and the endpoint.

[mpeuster]

@tsoenen @jbonnet I don't think that we want to deal with placement decisions inside a PoP. We only decide on which PoP we want to place with our SONATA system not on which host inside a PoP. This decision is left to the e.g. OpenStack instance running at each PoP (no infrastructure/cloud provider will let us decide where he should start our VMs inside his datacenter).

[DarioValocchi]

+1 @mpeuster, I think that the scope of placement should be in multi-PoP or multi-VIM(different Datacenter in the same PoP) deployment.

[smendel]

+1 for SLM deciding on which PoP.

@DarioValocchi - is the implementation based on this design - http://wiki.sonata-nfv.eu/index.php/Infrastructure_Adaptor_Design_Discussion ?

To my understanding in this github issue we want to define the API between the SLM and the IA, so the SLM will implement the correct API call, the implementation behind the IA is a less concern at this stage, and we need to address first the API aspects first - e.g. -

• will the IA register to the Message Broker as another Plugin (as suggested in the design linked above) ? and so the communication will be with Rabbit MQ messages format. or is it going to be a REST API ?
• what will be the content of the API call - how will the service/vnf be described / how will the requested PoP will be refered to etc

[tsoenen]

What are the pro/cons of the IA communicating with the MANO framework through a REST API?

So if I understand correctly, when we have a multi-PoP infrastructure, the placement SSM decides which VNF is mapped on which PoP. If two POPs are connected with eachother by multiple paths, the placement also decides which of these paths should be used (if both PoPs host a VNF, and these VNFs are connected). How to connect two VNFs that are mapped on the same PoP is a decision for the PoP owner.

In our simplified example, all VNFs are mapped on the same PoP. Therefore, no placement info on the connections of the service graph has to be added. In the SLM, we should just assign each VNF to the same PoP (hardcoded, since we perform no placement), before the service graph and the VNF image urls are send to the IA. I think by doing it this way, we stay closest to the actual way the MANO framework should be working, reducing the amount of extra code that might turn useless in a couple of weeks.

Any thoughts?

[shuaibsiddiqui]

Regarding placement decision within a PoP, a VNF may indicate requirement of an accelerator in its VNFD which can allow Placement Plugin to make a smart placement decision even within a PoP.

It is not for Y1 but I think we should consider this scenario. There is something similar along these lines in T-NOVA already (@jbonnet: Please, correct me if I am wrong).

[DarioValocchi]

@smendel @tsoenen as for the pro/cons on Msg/REST communication: Basing on the SP architecture I would follow the rabbitMq idea. I believe this brings an higher level of flexibility, exploiting the topics-communication to expose the IA interface toward all the interested modules of the SP. So my penny is on topic/queue based communication. This will also mean that a good thing is to register the IA to the plugin manager. This will ensure a standard level of manageability of the IA, implementing standard lifecycle and standard monitoring facilities, likewise any plugin. Anyway my first work on the code has been to abstract from the communication layer, so we can decide also to change in the future for a different MsgBus implementation, or even for a different model (a REST server) to receive and send messages.

[mpeuster]

+1 for the "IA is just another plugin" approach using RabbitMQ

Integrates much nicer into the rest of the architecture.

[tsoenen]

Hi @DarioValocchi , in what format do you expect to receive the deployment info from the SLM? Would to following yaml format work for you:

forwarding_graph:
        ...
vnf:
        - vnf_id:
          url:
        - vnf_id:
          url:
        ...

where the forwarding_graph is an exact copy from the one in https://github.com/sonata-nfv/son-schema/blob/master/package-descriptor/examples/sonata-demo.yml and the urls are links to the vnf images. vnf_id is needed to determine which image url maps to which vnf in the forwarding graph. (the forwarding graph also uses vnf_id to reference the vnfs)

[DarioValocchi]

Hi @tsoenen, we're discussing (probably today, possibly Thursday) the translation between the SD and the HEAT template which will happen in the IA (Here's a doodle for the call: http://doodle.com/poll/a5v4gavdkssh2bt4). With a more clear view on this process we can have a better idea on what the IA needs to receive from the platform. Anyway, in general terms, I think it is good to have a "lightweighted" passed to the IA, as you propose.

[adrian-rosello]

Hi!

From the IA response to the SLM, I was wondering which information it will it provide (and also the format). I guess it would contain information about the reserved resources and the connection points, right? Those are relevant data that would later be included in the NSR.

[jbonnet]

@adrian-rosello hi,

I see the response from the IA being 1 NSR (Network Service Record) and 1 VNFR (VNF Record) per each one of the VNFs that are part of the NS. At least for a start. Later, and since we want to 'abstract' de actual infrastructure we'll use, more info might be needed.

Cheers, jb

[jbonnet]

@tsoenen hi,

Please do not forget in that list monitoring parameters. Each VNF/NS may have it's own monitoring parameters (service related, e.g., number of simultaneous sessions, not system related, e.g., %CPU used). This information will have to be passed somehow to the Mitring System, which I do not know yet if will be behind the IA or not.

jb

[jbonnet]

@shuaibsiddiqui hi,

within a PoP, and when we're using OpenStack as the VIM, placement is pretty much dealt with (and even hard to replace/complement, as we've tried in T-NOVA, at least with a scalable solution), at least with current versions. Maybe in the near future this part will be more modular and allow for externally triggered placement. In T-NOVA placement focuses on choosing which PoP to use.

jb

[jbonnet]

@mpeuster hi,

No problem at all with message-oriented interfaces such as the kind provided by RabittMQ, but we should focus really on the kind of interface we need, synchronous vs. asynchronous. In this case yes, we're in general (there might be other specific needs to which this reasoning does not apply) dealing with asynchronous messages (at least in OpenStack).

;-)

[tsoenen]

@adrian-rosello : Hi Adrian! Are you planning to work on the SLM development? If so, we should coordinate, since I've been working on it as well (so we prevent doing the same work twice:))

[adrian-rosello]

@tsoenen Hi!

Yes, I was planning to start working specifically in steps 13,14 and 15 of the workflow diagram, that is, receiving the response from the IA, construct the NSR message and send it to repository before answering to GK. Which steps were you planning to do?

[tsoenen]

@adrian-rosello : I was planning on coding all the steps involving the SLM. We can share the workload if you want, but I have no problem doing the entire SLM either...

[adrian-rosello]

@tsoenen : No prob! We really would like to contribute, at least, in the mentioned issue, but we were thinking in extend it to other steps. Do you want to divide the work in SLM ?

[tsoenen]

@adrian-rosello : Great! I'll make a commit later today with what I have for the communication between the SLM and the Repositories. Its not much so far, but feel free to change/add/update where you feel needed:)

[adrian-rosello]

Hi all!

In order to finish the following simplified MSC: http://wiki.sonata-nfv.eu/index.php/NS_LifeCycle_Mgr_MSC_Simplified

Steps 5 and 6 are still to be implemented. Here in i2CAT we would be glad to implement it. Therefore, we need to define the API between SLM and Infrastructure Adapter in order to get resources availability. In first prototype, I would suggest that SLM collects information from all VNFDs and aggregate it as a single resource. So, for example, if we have following requirements coming from GK:

- vdu:
    cpu: 2
    ram: 8 GB
- vdu:
    cpu: 1
    ram: 2 GB

, SLM would include following information in the request to IA:

cpu:3
ram: 10GB

Answer from IA could contain just a field defining if there are available resources or not.

What do you think?

[DarioValocchi]

:+1: for the aggregated information, at least for the first prototype. The call could arrive on the topic “Infrastructure.monitoring.compute.availability" or "Infrastructure.management.compute.resourceAvailability" (not shure which one is semantically more appropriate) Don't forget to include in the payload also the aggreated storage requirements for the VDUs :smiley:

[adrian-rosello]

Yep, sure, will include more information, it was only a short example :) Thanks!

Regarding the topic.. me neither know which is on more appropriate. Since we are asking it before we deploy a service, I would vote for the second one

[DarioValocchi]

@adrian-rosello @tsoenen Something changed a bit on the definition of this API call during today WP4 call: The idea is to have a single call for the MANO framework to collect data on the resource availability of all the PoPs (VIM) registered to the Platform, in order to be able to do service placement. So what I have in mind is an almost empty, asynchronous message from the Orchestrator to the IA on the topic: infrastructure.management.compute.resources

on the same topic with a matching correlation_id the IA will answer with something like this:

compute_resources:
  type: array
  item: 
    type: object
    properties:
      uuid:
        description: "The UUID of the registered VIM(PoP)"
        type: "string"
      cpu:
        type: "integer"
      memory:
        type: "integer"
      memory_unit:
        description: "compliant to memory unit enum format in son-schema"
        type: "memory_unit"
      storage:
        type: "integer"
      storage_unit:
        description: "compliant to memory unit enum format in son-schema"
        type: "memory_unit"