There are four common development workflows:
Deployment
The most important workflow from an operational perspective is to deploy a POD. This involves bringing up a static XOS service stack (aka "service profile") with POD-specific configurations applied. It's not interactive. It's a matter of selecting a pre-built set of components and a site-specific configuration, fire and forget, and several hours later you have a running POD.
There are multiple service profiles (e.g., cord-pod) and there are multiple site-specific configurations (e.g., reference POD, OpenCloud).
This is a heavy-weight development pattern as it requires approximately 3 hours for the full development loop to rebuild an entire CORD-in-a-Box experiment. On lesser hardware than CloudLab, this process can sometimes take up to 6 hours. (Hence, this is not a viable development workflow... it's a deployment procedure).
Service Profile or Core Data Model Development
This is the development pattern of building a stack of XOS services. The development loop with this workflow is to tear down XOS, destroy the database, and re-initialize XOS. We do this without destroying the platform -- for example OpenStack and ONOS remain installed. Compute nodes remain online. The traditional way we have done this in the past is:
- Destroy XOS (make cleanup)
- Alter the service profile recipes to select a new service graph or to reconfigure the settings for the current services (git pull service-profile)
- Optionally rebuild XOS (make local_containers)
- Bring up XOS (make; make vtn; make fabric; make cord; make cord-subscriber)
This is a medium-weight development pattern. It takes 15-25 minutes to tear down XOS and rebuild a new one and to get the vSG service back online. XOS database state is destroyed along with any slices or networks.
In addition to developing service graphs, this is also the pattern that you would follow to make major modifications to the core data model, because this is the development pattern that involves destroying and re-creating the database.
Individual Service Development
This loop involves restarting individual synchronizers. The traditional way we have done this is with either "make rebuild" or having a synchronizer or UI container run a "sleep" command instead of it's usual command, and running processes manually.
This is a light-weight development pattern, with a loop time ranging from a few seconds to 5 minutes depending on how you go about it. XOS database state is preserved between iterations of the development loop.
As much as practical, we want to be able to isolate the rebuild to a single service, so that services can be developed without having to teardown the whole of XOS. Service developers like to be able to develop services in isolation. Developing service "in isolation" doesn't necessarily mean without XOS or without other services. By nature, services depend on one another, but you shouldn't need to touch a service that you're not actively working on.
UI / API / TOSCA Development
This is just like service development, but you're working on a UI or API container instead of a synchronizer container. You want it lightweight and isolated to just the parts you're working on.