CORD : Service-profile to platform-install migration guide


Introduction

 Due to the complexity of maintaining multiple profiles, the CORD project has eliminated running `make` targets inside of service-profile to bring up a profile.   This functionality has been moved into the `platform-install` repo, where it can be expressed in a more declarative fashion.   This allows us to better support the different profiles such as M-CORD and OpenCloud, in addition to the primary R-CORD profile.

 NOTE - before reading this, read the README.md in the `platform-install` repo, which describes the existing profile manifests, how to create a new profile manifest from scratch, and how to use ansible-playbook to start and tear down a profile.

Where is everything?

Previously in service-profile, the Makefile mechanisms (the “how”) to load a were intermixed with the profile TOSCA files (the “what”) and various other files.

The closest analogy to the Makefile is the profile_manfests/<name>.yaml file (the “profile manifest”), which has lists of services to onboard, TOSCA to run, and other variables used to configure the profile.  This also contains many similar configuration options that the Makefile contained.

The TOSCA files are now templates and live in the roles/cord-profile/templates directory.  As these may be shared between multiple profiles, use great care when modifying a template that may be used by other profiles.

When the deploy-xos-playbook.yml playbook in platform-install is run, it will take the profile manifest, create a directory named `cord_profile` and generate all the templated TOSCA files that are listed in the profile manifest, create the docker compose file for bootstrapping the XOS profile, then start the bootstrap containers that bring up XOS and load the generated TOSCA.

Passwords are randomly autogenerated if you don’t set them in some other way, and stored in the platform-install/credentials directory, where the filename is the login, and the file contents is the password.  The default admin user in most profiles is xosadmin@opencord.org.

I used to…

… onboard a service during the onboarding target 

Add the service name and path to the `xos_services` array in the profile manifest.

If a SSH key or other file needs to be copied for this profile, add those to the `xos_service_sshkeys` array

… send XOS a TOSCA file with `$(RUN_TOSCA) file.yaml`

Create a template version of the TOSCA file in `roles/cord-profile/templates`, with an extension of `.yaml.j2` . If you generated this file with a script, you can use the Jinja2 template system to perform analogous steps as the script.

Some of the TOSCA templates are shared between profiles, so be careful when modifying them - if you are adding optional features, using Jinja2 to optionally include them with a conditional like `{% if … %} … {% endif %}` is recommended, then adding a default setting for the variable you’re switching on to roles/cord-profile/defaults/main.yml. Most of these variables are named `use_*`, and should usually default to being False, but enabled by setting the variable to True in your profile manifest.

Add the name of the TOSCA file (without the .j2 suffix) to the `xos_tosca_config_templates` array in the profile manifest - it will then be loaded into XOS after onboarding has occurred.

… create a non-TOSCA file with a script

Create a template version of the file in `roles/cord-profile/templates`, with an extension of `.j2`, and add it to the `xos_other_templates` array in the profile manifest.

… have a target that onboarded something after the main onboarding step

Look at the `onboard-exampleservice-playbook.yml` and the roles: `exampleservice-config` and `exampleservice-onboard` - you should create a playbook and roles similar to those.

Run the playbook with ansible-playbook after running the `deploy-xos-playbook.yml`, with the same parameters.

… run an arbitrary command(s) as a target

There’s no single solution for this. If it’s a simple command, it would be best to add it to your profile’s documentation, and run it manually.  If it’s complex, needs templated files, or other automation, make a playbook that runs roles that perform the tasks.