-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define infrabstract - MANO Framework APIs for initial implmentaion of year 1 #1 #2
Comments
First 2 questions, we briefly discusse off-line with @mpeuster. Question1: The service offered by the adaptor would be relatively slow: e.g. download and push VM into VIM image repo, deploy and configire a VM or a whole NS, trigger configuration changes...
Question 2: Sholud the Adaptor behave like a plugin and register to the plugin manager, providing also its own hearthbeat mechanism, practically extending Manuel plugin interface? |
@DarioValocchi @mpeuster @adrian-rosello : Hi all! As suggested by Dario on gitter, lets sync up on the SLM <--> IA interaction. At this point, the SLM sends a request to the IA in the following way (yaml):
The info behind forwarding_graph explains how the vnfs should be connected, and is a copy from https://github.com/sonata-nfv/son-schema/blob/master/service-descriptor/examples/sonata-demo.yml. @DarioValocchi: Is this enough information for deployment, or do you need more? The SLM expects the following response from the IA(yaml):
The status can be RUNNING/FAILED/... the content of nsr, vnfr1, vnfr2, ... is still undefined. I think we should start with the basics (things like name, id, ip, ...) and add additional fields later when someone needs them. Any thoughts? (I'm out of the office this afternoon, so I won't be able to respond before this evening/tomorrow morning) |
Hi Thomas! I totally agree with you. Taking a look at ETSI standard, at least the ip and the vnf_address (described as a network address configured for the management access) are required. We can include the status of the VNF as well. This will make the VNFR part look like:
|
Thank you for the good work. @tsoenen @adrian-rosello: a quick question that has came to my mind just now: Do we have a formalization of the message sent through the message broker? Topic, content, format, etc...? Is the payload sent over the msgbus in yaml or json? |
I'm going through the SD and I have another question: I would like also @smendel @mbredel and @jbonnet opinions' on this. Is the NS forwarding graph something to be parsed and "enforced" by the IA? |
@DarioValocchi Very good question. In general (not for Y1), the forwarding graph could span multiple different VIMs. Therefore, the parsing of the forwarding graph (FG) should be done in the VNF adapter (or at least outside the IA). However, the IA has to offer an API such that the VNF adapter can talk to it. The VNF addapter could send parts of the FG to the IA, which means the IA has to be able to parse it as well ... |
@mbredel @DarioValocchi @DarioValocchi What do you mean by 'enforcing'? Checking if data is coherent? If so, yes, the IA may do something about validating semantically what is being asked... |
@jbonnet @mbredel about the VNFFG role in the SD : isn't the connection between VNF described in the "connection_points" and "virtual_links" sections of the descriptor? |
@DarioValocchi : Sending the entire NSD and VNFD's is not a problem. I propose the following format for that
It is send on the topic 'infrastructure.service.deploy', encrypted as a yaml message. Each packet has a correlation_id property in its header. The response should have the same correlation_id. |
@DarioValocchi |
@jbonnet I think I see. The FG is configured in the VIM+WIM through the Networking facilities, and this is moslty kept outside of the VNFs. |
@tsoenen 👍 for the format. |
@jbonnet Oh - yes you are right regarding the VNF Adaptor and the VNFFG. @DarioValocchi You can have Virtual Links in a VNF descriptor that describes a VNF which is composed of several (>1) VDUs, where each VDU is a VM (or Docker). The NS descriptor again can have Virtual Links between multiple VNFs .... |
@mbredel Yes, I was talking about the links in the NS. Now I think I see what José mean. That is something not going through the VNF adaptor, as it acts per VNF. |
@tsoenen as for the message the SLM sends: Would it be nicer to have something like:
I am not an expert with YAML, so maybe is a stupid question. Seems to me it would be mush easyer to parse. |
@DarioValocchi : If you prefer this format, we can do it that way. From the SLM point of view, I think both are fairly equal when it comes to parsing. In your example, does VNFDs contain a list of dictionaries (where each vnfd is a dictionary) or a dictionary of dictionaries (where each dictionary is a vnfd, and vnfd1, vnfd2 are the keys)? |
@tsoenen I think is a List of dictionaries, speaking python. So to allow variable number of VNFD.
|
Other issue that came up now I'm implementing the mock response generation. Any policy for the Instances ID? What information is expected in the Service Record? Id and status, again? |
@DarioValochi jb Enviado de Samsung Mobile -------- Mensagem original -------- Other issue that came up now I'm implementing the mock response generation. Any policy for the Instances ID? What information is expected in the Service Record? Id and status, again? — |
Ok, I feel stupid now. 😄 |
@tsoenen , The mock's almost ready. Just one more question. |
@DarioValocchi : It's a lot of fields indeed:) It's the first time I see it, so right now I don't now which originate where. But I think that for now, it is ok if the NSRs are not complete. As long as their is a NSR and it has some fields, we can continu. So I would suggest that you include a (small) subset of te fields that originate in the IA, and we can add fields later when needed. |
@tsoenen, just pushed a new commit on the DV-branch of the adapter with the promised MockWrapper.
that is basically a copy of the required fields of the VNFR from the relevant VNFD. The NSR now contains just a status and an ID of the instance. There's room, of course, for other fields, if they are originated in the IA. |
Revert "updated the status option to return more"
fixed sending message and close connection
as initial step for year 1 demo we would like to implement a simple deploy service flow.
more details from the MANO framework side can be found here -
sonata-nfv/son-mano-framework#23.
we need to define the Infrabstract-SLM Plugin APIs as 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
The text was updated successfully, but these errors were encountered: