At the moment the on-boarding system is capable of dynamically on-boarding services into XOS. For more information about the current implementation, please refer to: Dynamic On-boarding System and Service Profiles (Mysterious-Decsion).

There are currently other resource that could be on-boarded:

• Service Related Views
• Cross Service Views
• Third Party Dependencies

It would be good to enumerate all the ways one might want to extend XOS/CORD over time (see the third section below). The open question is whether these extensions should be dynamically added to a running system, or simply require a re-build. We have historically treated Views as "dynamic extensions" to XOS (much like services), so it makes some amount of sense to extend on-boarding to include them.

Service Related Views

This are Single Page Application (refer to User Interfaces#CustomViews) that explicitly depends on a service and have no meaning without it. One example is the "Truckroll View".

Cross Service Views

This are Single Page Application (refer to User Interfaces#CustomViews) that explicitly depends on multiple services and have no meaning without all of them. One example is the "Diagnostic View" that depends on vRouter, vSG and monitoring services.

Third Party Dependencies

This can be any (or any set of) dependencies that can be required for the system to correctly work. Some examples are:

•  UI Libraries
• VM Images

Possible Implementations

From Services to Components

One option can be extend the current implementation to add views and other dependencies. Since none of the defined resource is mandatory in a service it should be pretty easy to include in an external service only the file that are needed in that case. They can be any combination of Service, Views and Dependencies. In case I suggest to refer to this bundle as "Component" instead that calling it "Service" (as it won't be mandatory for it to include a service).

We could keep Views distinct from Services in terms of the API, but reuse much of the same mechanism under the covers. This has the advantage of re-enforcing the fact that Views and Services are not necessarily coupled, without having to start from scratch in the implementation.

As a separate issue, we should figure out a good way to express all dependecies. The service graph includes inter-service dependencies (although we don't currently use this information in the on-boarding process). We will definitely need to make View-to-Service dependencies expicit in some way.

Different Onboarding System

Another option can be to define tailored Onboarding helpers for Services, Views and Dependencies. Design details will come.