Resource Orchestrator. The Resource Orchestrator (RO) module has been developed from scratch to fulfil the XXXXX requirements, which have been documented in the XXXXX D2.2 deliverable. We recall the major key functionalities that the RO needs to provide as follows: • Manage different kind of resources (computing, networking, etc) and allow data access policies, for in- stance through the AAA system (user's identity and permissions) or through domain specific restrictions. • Mediate between the user/experimenter and the technology-specific Resource Managers (RMs) in order to reserve, provision, monitor, release and operate on both resources and slices. • Maintain a high-level and cross-island topological view (updated by the underlying RMs) for better decision making. • Manage end-to-end services spawned on the federated testbed and coordinate the correct sequence of actions to instantiate the service. • Interact with the Monitoring System to provide measurements, statistics and resources provisioned per slice, as well as to provide such System with the overview of the physical topology. The following sections describe the technical design of the RO, which has been inspired by the previous requirements. In addition, we present some internal workflows that explain how the basic operations are per- formed inside this module and also document in a simple manner the interaction between the RO and other modules from the XXXXX project that are related to it.
Resource Orchestrator. The RO is a pure Python module based on the SFA architecture [14] and (partially) the eiSoil [17] framework. Basically it is composed of 2 main threads that follow an event-driven approach. The first one, based on the flask-rpc server, is responsible to manage the GENIv3 interface and provide the provisioning for the different kind of resources. The (GENI) XML messages that are exchanged among processes or daemons are parsed and formatted according to proposed schemas (using the lxml library). Moreover, the operations are performed only in case of a success of the authentication and authorization mechanisms (based on the GENI ClearingHouse directives). The second one, based on apscheduler python module, manages auto-generated events (periodic or one- shot) to obtain and update the discovered physical topology. The resources are stored into a non-relational database, based on the mongo-db server. The following sections want to clarify the aforementioned dependencies trying to give further soGware de- tails.
Resource Orchestrator. The Resource Orchestrator (RO) is at the heart of the XXXXX virtual infrastructure configuration, coordinating user's actions for resource instantiation (computing, OpenFlow-enabled switches, stitching entities and transit networks) with C-BAS and monitoring. RO can run in two operation modes: RO (default) and Master RO (MRO), thus acting as parent orchestrator and coordinator of other ROs. Each island (but iMinds, where FOAM is reused from Fed4FIRE) has deployed its own RO, which is responsi- ble for orchestrating local resources made available for the federation. As per the design of the XXXXX architec- ture, two MROs are deployed in XXXXX: one in i2CAT (European region) and one in AIST (Japanese region). MROs communicate with each other to implement inter-continental infrastructure provisioning. Further details on the location of such modules are provided in Appendix A. The source code for RO is available in the GitHub public repository, under the resource-orchestrator branch. A number of configuration files are provided so that the administrator fills those with data such as the address, port and endpoint provided per RO (see "Annex A" to consult them) or enabling/disabling features during test- ing phases, such as RSpec validation, credential verification and so on. AGer introducing the Monitoring System (MS), we saw necessary to add extra configuration files for CRM, SDNRM and SERM in order to provide the miss- ing information on how to access monitoring information (i.e. metrics) on the hardware. This information is not provided by the GENIv3 APIs, therefore is filled internally by each administrator during the configuration of RO/MRO. o help with this process, a sample configuration file is provided with blanks to be filled. The internal communications of RO-MRO have been interactively tested and validated to consolidate the intra-region orchestration workflows and GENIv3 API contents described in WP3 deliverables, e.g. towards the resource database, the various RMs or the northbound API to users.
Resource Orchestrator. As previously described, RO is the XXXXX component designed to orchestrate the end-to-end network service and to reserve and monitor the underlying resources through RMs and MS. This module has been developed from scratch in XXXXX project. The soGware system can operate in two operational modes: Resource Orchestrator (RO) per island and Mas- ter Resource Orchestrator (MRO) per continent. The only difference is the meaning of the resources that it can manage. Indeed, the RO is connected to the RMs in order to control the physical (i.e. Computing, SDN and Stitch- ing) resources of the island in which it is installed. On the other hand, the MRO cooperates with the others ROs and with the TNRM in order to set-up the inter-islands paths within the continent (i.e. Europe or Japan) realising the architectural hierarchical approach described in the D2.2 document [3]. This different behaviour is simply obtained changing some parameters (e.g. mro_enables) of the configuration file of the module. Moreover, set- ting up a proper list of peers allows the component to activate the dedicated drivers to connect the interworking modules. Due to its peculiarity, the (M)RO has undergone a Sandwich Testing procedure. That means we had firstly validated the procedures for the RO component following a Bo1om-to-Up Testing approach, using an emulated test environment with simulated RMs. In this phase, we have verified the basic functionalities of the module, i.e.
