# Import
After initial setup, publicly available content (e.g., service offerings) can be imported into your instance of the Service Lifecycle Management.
# Service Registry
To import content into the Service Registry of the Service Lifecycle Management local directories or git repositories can be used. See the two sections below for more information how to configure import from local directories or git repositories. The import can be started using this command:
docker-compose up --force-recreate service-registry-init
# Local Directories
Update in the .env
file in the compose
directory the variable SERVICE_REGISTRY_INITIALIZATION_LOCAL_DIRECTORIES
with your directories. Multiple directories must be seperated by comma. The defined directories must be added as volumes to the service-registry-init
service in the docker-compose.yml
.
Example of .env
:
SERVICE_REGISTRY_INITIALIZATION_LOCAL_DIRECTORIES=/my/local/dir1,/my/local/dir2
Example of docker-compose.yml
:
...
service-registry-init:
...
volumes:
...
- "/my/local/dir1:/my/local/dir1"
- "/my/local/dir2:/my/local/dir2"
...
# Git Repositories
Update in the .env
file in the compose
directory the variable SERVICE_REGISTRY_INITIALIZATION_GIT_REPOS
with your git repositories. Default value is the public service registry content repository (opens new window). Multiple git repositories must be seperated by comma. Authentication for a git repository can be defined in the form {Username}:{PasswordOrAccessToken}@{RepoUrl}
.
Example:
SERVICE_REGISTRY_INITIALIZATION_GIT_REPOS=https://github.com/FabOS-AI/fabos-slm-service-registry-content.git,myGitUser:myGitUserPassword@https://my-private-git-repo.git
# Resource Registry
To populate the Resource Registry of the Service Lifecycle Management with an already available list of known, a simple utility tool can be used to speed up the process. The tool can be found on GitHub (opens new window). In the current version, the tool parses a given Excel file and populates the Resource Registry with the contained resources.
ATTENTION
The tool was initially only intended for a quick repopulation of the Resource Registry in demo setups. Consequently, the tool is rudimentary in design and will be changed in the future in order to be more aligned with the SLM base setup and components.
Since the tool interacts with the REST-API of the Resource Registry
, to use the tool just clone the repo into any directory:
git clone https://github.com/FabOS-AI/fabos-slm-resource-registry-init && cd fabos-slm-resource-registry-init
Now the Excel file example.xlsx
needs to be adapted to the list of resources to be added to the Resource Registry. There are two example devices listed to familiarize with the pattern. The following fields are definitely required to be filled (per device):
variable | type | description |
---|---|---|
Device | string | An arbitrary device name, for easier reference |
user | string | The user name of the resource, in order to be accessed |
password | string | The password of the corresponding user |
hostname | string | The hostname of the resource |
eth0 IP | string | The IP of the resource. Additionally, eth1 IP can be filled as well, but eth0 will be prefered |
is_resource | string | A flag that determines if device is added to the resource registry. Set it to "yes" in order to be added |
UUID | string | The UUID of the resource, can be generated externally |
Additionally, following flags can be used to trigger the install of an capability for the resource (optional):
variable | type | description |
---|---|---|
DC_Docker | string | If set to "yes", Docker capability will be added to resource |
DC_Swarm | string | If set to "yes", Swarm capability will be added to resource |
DC_K3s | string | If set to "yes", K3s capability will be added to resource |
In a second step, the settings for the tool need to be adapted and verified. Therefore open the docker-compose.yaml
in a text editor and change the variables in the environment
-section accoding to your local environment. When the Service Lifecycle Management was setup through the inital setup, all variables should already be matching the local environment. See the following table for details on the settings:
variable | type | default | description |
---|---|---|---|
SLM_HOST | string | "http://172.17.0.1" | The full qualified domain name of the SLM host or IP address, including the http prefix |
SLM_USER | string | "fabos" | The user to be used to add the resources to the SLM |
SLM_PASSWORD | string | "password" | The corresponding password for the SLM user |
XLSX_FILE | string | "/files/example.xlsx" | The Excel file inside the container. On default all file of the cloned directory are mounted under "/files" |
SHEET_NAME | string | "DEVICES" | The sheet name inside the Excel file which contains the list of resources |
FORCE_OVERWRITE | bool (as string) | "False" | Determines if resources and their capabilites should be overwritten if they already exist |
FORCE_DELETE | bool (as string) | "False" | Determines if a resources listed in the EXCEL sheet should be deleted in the first step |
DELETE_ALL | bool (as string) | "False" | Determines if all resources (not only listed resources in the EXCEL) should be deleted in the first step, to start with a clean resource registry |
PING_CHECK | bool (as string) | "False" | Determines if resources should be pinged before added to the resource registry |
ATTENTION
Especially in a setup with docker be aware of the correct host used in the SLM_HOST
variable. In Docker localhost and 127.0.0.1 will not work, instead try the magic internal Docker host host.docker.internal, 172.17.0.1 or in best case the regular IP of the host.
Finally, the tool can be run through Docker. Therefore use Docker-Compose to build and run the tool:
docker-compose up --build
A successful run of the tool will print a summary at the end of the run. For the given resource in the example.xlsx
file, the summary looks like this:
resource-registry-init | SUMMARY -------------------------------------------------------------------------------------------------------------------
resource-registry-init | Resources deleted (via REST): []
resource-registry-init | Resources accessible (via ping): []
resource-registry-init | Resources added to registry (via REST): [
resource-registry-init | "0226a355-3156-43e8-b51e-3b670c6ba7c3, SOCP2001-20011111, 192.168.153.48",
resource-registry-init | "7fd248f5-e698-46f1-b30e-1ac568d66c15, RevPi30562, 192.168.153.51"
resource-registry-init | ]
resource-registry-init | Capabilities added to resources (via REST): [
resource-registry-init | "7fd248f5-e698-46f1-b30e-1ac568d66c15, RevPi30562, ['DOCKER']"
resource-registry-init | ]
resource-registry-init | Resource Registry Setup Done!
resource-registry-init | Took: 24.11s
This indicates that the two listed resources (SOCP2001-20011111
, RevPi30562
) were successfully added to the Resource Registry and that the Docker
capability was also added for the RevPi
device.