Correct internal behaviour per method. In this paragraph, we summarise the internal workflow per method from an high-level point of view. It is impor- tant to note that the (M)RO has a strong relationship with the other components in terms of the exchanged mes- sages. All these messages are printed in the log-file of the process (i.e. modules/resource/orchestrator/log/resource- orchestrator.log) in a pretty XML format. In the GetVersion method, the (M)RO fills the XML-RPC structure with the proper values. In the ListResources method, the (M)RO first verifies the user credentials and then reads from the MongoDB [8] database the information on the nodes and links for the C, SDN, SE and TN resources. At the end, the adver- tisement RSpec is composed and returned to the client. In the Describe method, the (M)RO verifies the user credentials and retrieves the information of the slice composition from the database. Then, it sends the describe command to each involved RMs or ROs. When the responses are correctly received, it creates the manifest RSpec and the list of slivers merging the output of the corresponding message. This information is then returned to the client. The Renew, Status and PerformOperationalAction methods are quite similar and we use the same template for the implementation. In these methods, the (M)RO starts verifying the user credentials and reading the slice composition from the database. AGer that, it sends the proper command (i.e. Renew, Status or PerformOpera- tionalAction) and, when it receives the responses, only the list of slivers is produced and returned to the caller. The Allocate method is the most complex implementation we currently have in the code. AGer the verification of the user credentials and the validation of the incoming request RSpec, the (M)RO tries to extend the request adding the Stitching Entity information. Here, we use a dedicated pathFinder module that simply lookup the database in order to fetch the missing resources description. When the request is completely reformatted, the (M)RO analyses the schema extracting the C, SDN, SE, TN sections. Each section is then introduced in the allocate command to the proper RM or RO. At the end, the (M)RO composes the manifest RSpec as sum of the received responses and fills the list of slivers structure. The Provision and Delete methods are also used to update the Monitoring System with the information related to the slice. As usual, the user credentials are verified and the slice composition retrieved from the database. ...
Correct internal behaviour per method. We have massively used the log file to validate the correct behaviour per each method of the interface. Using the OMNI tool, each method of the API was called and the log file deeply analysed. In case of errors, the problem was reported to the development team. In order to facilitate this procedure, the colorlog module has been introduced, producing different colours for the different levels, e.g green for debug, blue for info, red for error, etc. Moreover, we have added the timestamps and a proper handler for the dumping of the messages. As result, we have no errors in the normal test conditions.
Correct internal behaviour per method. The second item seeks to verify the correctness of the internal workflow of requests. That is done by testing incoming requests that arrive to the manager and traverse all way down until arriving at the driver. It also takes into account the returned information coming from the manager and going down to the driver. For that matter, tests have been automated to ensure a proper internal workflow. Unit tests for the involved methods can be found in the XXXXX repository, located under the corresponding folder [10] within the ocf branch. Looking into detail, the unit tests in CRM look for a proper behaviour/output on the following: • Management of unique identifiers (URN, HRN) for resources: ensure correct retrieval of the identifiers, appropriate parsing of authority, slice and sliver entities, and correct translation of URNs into HRNs and vice-versa. • Management of reservations: validate that reservations are assigned the default expiration time (1 hour) and ensure proper type handling during the management of the projects and slices. • Advertising resources: return (un)available servers, return slivers per slice, etc. • Management of slivers: correctly starting, stopping, rebooting, deleting and renewing resources. • Internal management: ensure credentials are verified correctly, handlers are set up as expected, and re- source specifications are accurately translated into an internal representation (model) used within internal components. The previous tests cover pretty much the full experimenter life cycle, yet further manual tests have been performed during the integration phase with the Resource Orchestrator (RO). These manual tests have been carried out both manually (using a third-party client, such as jFed or OMNI) and also by using the RO to proxy requests to its managed RMs.
Correct internal behaviour per method. During the tests the log file had been used to validate the correct behaviour per each method of the interface. Using the OMNI tool, each method of the API was called and the log file deeply analysed. In case of errors, the problem was fixed by the SERM developers. The correctness of the VLAN translation rules installation on the switching device had been confirmed by using the Ryu REST API and the method that displays all the OpenFlow rules. In first phase of the tests the soGware Open VSwitch has been used as a Stitching Entity. In the next phase the proper VLAN translations on the Juniper MX80 with the OpenFlow support was also tested. As result, no errors in the normal test conditions occurred.
