|
|
# Clone the Mosaic5G repository
|
|
|
|
|
|
# Build JoX
|
|
|
JoX comes with an automated build script.Note that the steps detailed here are tested with Ubuntu 18.04, Juju version 2.5.1 (Juju version 2+ recommended).
|
|
|
In order to use JoX, please follow the next steps:
|
|
|
# 1. Clone stable source
|
|
|
firstly, install `git`:
|
|
|
```bash
|
|
|
git clone http://gitlab.eurecom.fr/mosaic5g/mosaic5g.git
|
|
|
cd mosaic5g/
|
|
|
$ sudo apt install git -y
|
|
|
```
|
|
|
# Set up and run JoX
|
|
|
|
|
|
```bash
|
|
|
./build_m5g -j
|
|
|
cd jox
|
|
|
and then clone JoX:
|
|
|
```bash
|
|
|
$ git clone -b develop https://gitlab.eurecom.fr/mosaic5g/jox.git OR
|
|
|
$ git clone -b develop git@gitlab.eurecom.fr:mosaic5g/jox.git
|
|
|
```
|
|
|
This will install all required packages (JUJU, rabiitmq,pika etc)
|
|
|
> JOX is tested for UBUNTU based machines, for other distributions these packages need to be manually installed
|
|
|
|
|
|
|
|
|
# How to start JOX
|
|
|
---------------------
|
|
|
- step1: JOX is using REDIS as the backend database. If redis is not already running, start redis-server:
|
|
|
$redis-server
|
|
|
|
|
|
- step2: Start the rabbitMQ service that is used for the message-bus implementation:
|
|
|
$service rabbitmq-server start
|
|
|
|
|
|
- step3: verify that JUJU is installed
|
|
|
$juju version
|
|
|
$juju status
|
|
|
$juju controllers
|
|
|
|
|
|
We refer to JUJU documentation for details. Currently JOX is tested for version JUJU 2.3.4:
|
|
|
www.jujucharms.com/docs
|
|
|
|
|
|
- step4: start JOX
|
|
|
$python3 jox.py
|
|
|
|
|
|
|
|
|
# When JOX is started
|
|
|
---------------------
|
|
|
When JOX is loaded the following configuration files are used `jox_config.json` and `default_slice_config.json`.
|
|
|
|
|
|
## jox_config.json Configuration File
|
|
|
|
|
|
In this file all the necessary information is stored regarding:
|
|
|
- the connection of JOX to redis
|
|
|
- the connection of JOX to rabbitmq
|
|
|
- the connection of JOX to juju local store
|
|
|
- information for the configuration of flask-based webapi
|
|
|
- definition of VM templates
|
|
|
- qemu paths etc.
|
|
|
|
|
|
## default_slice_config.json Configuration File
|
|
|
|
|
|
When JOX is loaded a default empty slice is created.
|
|
|
In default_slice_config.json information like the onwer of the slice or the juju target version is depicted.
|
|
|
This default slice is operational and through the web API, models resources and services can be added or removed.
|
|
|
|
|
|
# Operating JOX
|
|
|
JOX is a lightweight orchestrator targeting the mobile network operations. With JOX you are able to add/modify/remove network slices.
|
|
|
|
|
|
## Main Features
|
|
|
|
|
|
Inside the JOX core two main services are used in support of network slicing:
|
|
|
* JOX Slices Controller (JSC): responsible to host and control all the instantiated JSlices.
|
|
|
* JOX Clouds Controller (JCC): responsible to host and control all the instantiated JClouds. JCC offers services
|
|
|
to the JSC.
|
|
|
|
|
|
> How to create a JCloud ?
|
|
|
|
|
|
Every JCloud object inside JOX hosts information of a cloud-specific underlying cloud resources. A JCloud object interacts with the physical infrastructure and the cloud control mechanisms
|
|
|
through two channels:
|
|
|
* JUJU for a set of basic funtionalities. This is automatically made through JOX internal opeations.
|
|
|
* directly with the VIM for fine-grain monitoring and control. This interaction requires a specific JOX plugin (as part of JOX) and a JOX agent that needs to be installed in the VIM.
|
|
|
Currently two VIM agents are implemented one for LXD and one for KMV systems.
|
|
|
|
|
|
For example in a local environment a JCloud object can be connected to a LXD manager and can exploit all the container recourses that exposes for the local machine.
|
|
|
|
|
|
> How to build a JSlice ?
|
|
|
|
|
|
Every JOX Slice (JSlice) is a set of JModels. Every JModel is a set of JServices, JResources and service relationships.
|
|
|
Every JService is a service that is directly related to a JUJU charm. A service may refer to application (e.g. MySQL, Apache etc.) or a Virtual Network Funtion (VNF) (e.g. VNF for LTE eNodeB, VNF for HSS etc.)
|
|
|
All the JUJU charms available from the JUJU store are ad-hoc available and can be exploited.
|
|
|
|
|
|
See www.jujucharms.com/docs
|
|
|
|
|
|
JUJU charms for the OAI-based LTE network are here:
|
|
|
www.jujucharms.com/u/navid-nikaein
|
|
|
|
|
|
With these charms the entire LTE infrastucture can be build over commercial hardware, for various implementation scenarions like "vanilla" LTE and Cloud-RAN.
|
|
|
From the JUJU VNFM perspective, JUJU is unaware of the JOX operation. JOX is connected to JUJU as a normal (defaualt) user.
|
|
|
|
|
|
Every JModel is connected and can only operate over a single JCloud.
|
|
|
|
|
|
The creation of a JSlice and all interactions with the JSlice are made through the JOX REST web API.
|
|
|
see Web API documentaiton on how to create and operate a JSlice
|
|
|
|
|
|
|
|
|
> How plugins are operating in JOX?
|
|
|
|
|
|
For each resource, a local agent (called JAgent) is instantiated responsible for providing two functionalities:
|
|
|
|
|
|
* monitoring: lated to the statistics, measurements and status reports that JOX and the JSlices need to know. A Pub/Sub mechanism is used
|
|
|
for the JAgent/JPlugin messaging. The agent publishes the monitoring information and the consumer plugin inside JOX receives information from a queue.
|
|
|
|
|
|
* event handling: This is related to the events that are driven by the orchestration logic, or generated by the slice-specific applications, or even manually
|
|
|
from the JSlice owner. For the event handling, JOX relies on the RPC communication with a request/reply pattern.
|
|
|
|
|
|
For example a local LXD agent is implemented. In order to start the LXD agent
|
|
|
$python lxd_agent.py
|
|
|
|
|
|
This will automatically be connected to the plugin and the communication through the message bus will be initiated.
|
|
|
If the agent can be in the local machine or any remote machine. The only requirement is that the ip address/port are properly configured for the message bus. In the current implementation message bus is implemented with RabbitMQ and reside on the same machine were JOX is installed.
|
|
|
|
|
|
# Web API Documentation
|
|
|
## JOX Configuration
|
|
|
|
|
|
When JOX is loaded the configuration information is stored as a REDIS entry:
|
|
|
|
|
|
In order to retrieve information relevant to the JOX configuration the following method is used:
|
|
|
* path: `http://ip_address:8001/jox/config`
|
|
|
* methods:
|
|
|
* GET: Retrieves and returns JOX configuration in JSON format
|
|
|
|
|
|
|
|
|
## JUJU Information (Slice unaware)
|
|
|
|
|
|
Every JUJU model has one to one mapping to a JModel. This method can be used to retrieve information regarding JUJU models status, directly from JUJU:
|
|
|
|
|
|
* path: `http://ip_address:8001/jox/cloud/models?cloud=XXX&model=all`
|
|
|
* methods:
|
|
|
* GET:
|
|
|
* Retrieves and returns JUJU model information (not JModel information)
|
|
|
|
|
|
|
|
|
Every JUJU cloud controller has one to one mapping to a JCloud. This method can be used to retrieve information regarding JUJU users status, directly from JUJU. Every JSlice is associated to JUJU user. For the first version all JSlices are associated with the default JUJU user:
|
|
|
# 2. Build JoX
|
|
|
To build JoX, use the build script (you can find it at DIR_JOX/scripts/build_jox.sh) as follows;
|
|
|
|
|
|
* path: `http://ip_address:8001//jox/cloud/users?cloud=XXX&slice=YYY`
|
|
|
* methods:
|
|
|
* GET: Returns JUJU user information in JSON format
|
|
|
|
|
|
|
|
|
# Plugin Interaction (Slice unaware)
|
|
|
|
|
|
Every JCloud interacts with the cloud system through a plugin-agent interaction through the message-bus.
|
|
|
|
|
|
## LXD-QEMU
|
|
|
The messaging for JOX interaction with LXD. Two interactions are possible:
|
|
|
|
|
|
### Statistics retrieval.
|
|
|
This is made through the message-bus following the pub/sub pattern. When the agent is loaded the statistics are periodically send to JOX plugin and stored in REDIS. On call, the latest stats are retrieved.
|
|
|
|
|
|
* path: `http://ip_address:8001/jox/cloud/plugins/psutil/stats?cloud= & host_ip=YYY`
|
|
|
* methods:
|
|
|
* GET: Retrieves and returns statistics information
|
|
|
|
|
|
|
|
|
### LXD-QEMU event creation
|
|
|
|
|
|
In parallel with the statistics broadcasting from the agent, the agent is able to retrieve/send messages from/to the plugin regarding events creation.
|
|
|
|
|
|
* path: `http://ip_address:8001//jox/cloud/plugins/psutil/event?cloud= & host_ip=YYY`
|
|
|
* methods:
|
|
|
* POST: creates an event on the agent
|
|
|
Message body for POST
|
|
|
{
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
## Create/Modify/Delete JSlice
|
|
|
|
|
|
Every JSlice is composed by a set JModels. Every JModel is a set of services, their relationships and resources.
|
|
|
|
|
|
### JSlice:
|
|
|
* path: `http://ip_address:8001/jox/slice?slice=XXX&config=YYY`
|
|
|
* methods:
|
|
|
* GET:
|
|
|
* Retrieves and returns Information of the JSlice, where:
|
|
|
* slice: is the name of the JSlice (e.g. my_slice)
|
|
|
* config:
|
|
|
- if config="initial", the initial configuration of the JSlice is returned in JSON format. This inforamtion is retrieved by REDIS.
|
|
|
- If config="running" then a serialized version of the entire JSlice object is returned with all the information about the running state of the slice. This information is also periodically stored in Redis.
|
|
|
* POST: post is used to create a network slice (Jslice).
|
|
|
Message body for POST:
|
|
|
{
|
|
|
"jox-slice-template-version": 1.0,
|
|
|
"jox-template-date": "2017-23-07",
|
|
|
"juju-version": "2.3.4",
|
|
|
"description": "Simple template to deploy a single slice in jox",
|
|
|
|
|
|
"slice-name": "default-slice",
|
|
|
"slice-owner": "admin",
|
|
|
|
|
|
"models-list": [j
|
|
|
{
|
|
|
"model-name": "default-model",
|
|
|
"model-cloud": "localhost",
|
|
|
"region": "Greece",
|
|
|
"resources": {
|
|
|
"machines-list": [
|
|
|
],
|
|
|
"networks-list": [
|
|
|
]
|
|
|
},
|
|
|
"services-list": [
|
|
|
],
|
|
|
"service-relations": {
|
|
|
"description": "Type of instance (flavor) to be used",
|
|
|
"service-relations-list": []
|
|
|
},
|
|
|
"service-chains": {
|
|
|
"description": "Type of instance (flavor) to be used",
|
|
|
"service-chains-list": []
|
|
|
}
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
|
|
|
This body will create an empty slice. If at each part of the body the relevant fields are filled, the slice can be created in one step.
|
|
|
|
|
|
* DELETE: is used to delete the entire JSlice (models, services, resources).
|
|
|
```bash
|
|
|
$ cd DIR_JOX/scripts/
|
|
|
$ ./build_jox.sh -i # to build JoX
|
|
|
```
|
|
|
This will build all the dependencies of JoX. For more options,
|
|
|
|
|
|
### JModels:
|
|
|
* path: `http://ip_address:8001/jox/slice/model?slice=XXX&model=YYY¶m=ZZZ`
|
|
|
* methods:
|
|
|
* GET:
|
|
|
* Retrieves and returns Information of the JModel, where:
|
|
|
* slice: is the name of the JSlice (e.g. my_slice) hosting the model
|
|
|
* model: is the name of the model
|
|
|
* param:
|
|
|
- if param="info": the corresponding JUJU model information is returned in JSON format
|
|
|
- if param="status", the corresponding JUJU model status report is returned in JSON format
|
|
|
* config:
|
|
|
- if config="initial", the initial configuration of the JModel is returned in JSON format. This inforamtion is retrieved by REDIS.
|
|
|
- If config="running" then a serialized version of the entire JModel object is returned with all the information about the running state of the model.
|
|
|
* field: filter to only retrieve a specific part of the response (for all previous combinations)
|
|
|
```bash
|
|
|
$ ./build_jox.sh -h # to print help
|
|
|
$ ./build_jox.sh -i # to build JoX
|
|
|
$ ./build_jox.sh -x # to install ubuntu-xenial image necessary for kvm
|
|
|
```
|
|
|
|
|
|
|
|
|
* POST: post is used to create a network slice (JModel). The only parameter required is the name of the hosting slice.
|
|
|
*slice_name= the name of the slice where to deploy one or more models
|
|
|
Message body for POST: The following body will create an empty model under slice with name "new-jox-model".
|
|
|
"models-list": [
|
|
|
{
|
|
|
"model-name": "new-jox-model",
|
|
|
"model-cloud": "localhost",
|
|
|
"region": "Greece",
|
|
|
"resources": {
|
|
|
"machines-list": [
|
|
|
],
|
|
|
"networks-list": [
|
|
|
]
|
|
|
},
|
|
|
"services-list": [
|
|
|
],
|
|
|
"service-relations": {
|
|
|
"description": "Type of instance (flavor) to be used",
|
|
|
"service-relations-list": []
|
|
|
},
|
|
|
"service-chains": {
|
|
|
"description": "Type of instance (flavor) to be used",
|
|
|
"service-chains-list": []
|
|
|
}
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
|
|
|
This body will create an empty model. If at each part of the body the relevant fields are filled, the model can be created in one step.
|
|
|
When building JoX, at the end of the build you should see the following message:
|
|
|
```bash
|
|
|
###### JoX built successfully !!! ######
|
|
|
Creating cache dir in /mnt/jox_store
|
|
|
JoX store was not mounted, Mounting ...
|
|
|
Mount success
|
|
|
```
|
|
|
|
|
|
# 3. Fetch cloud image for kvm
|
|
|
If you plan to use kvm (Optional), which is the case for some juju charms like oai-spgw, you should firstly fetch the Ubuntu cloud image(Xenial) as follows:
|
|
|
|
|
|
* DELETE: is used to delete the entire JModel (services, relations and resources). Parameters required are the slice name and the model name. All the services are destroyed and all the resources are released for this slice.
|
|
|
*slice_name= the name of the slice that is hosting the model
|
|
|
*model_name= the name of the model to delete
|
|
|
```bash
|
|
|
./build_jox.sh -x
|
|
|
```
|
|
|
|
|
|
### JMachines:
|
|
|
* path: `http://ip_address:8001/jox/slice/machines?slice=XXX&model=YYY`
|
|
|
* methods:
|
|
|
* GET:
|
|
|
* Retrieves information the Jmachines (e.g. LXC VMs) in JSON format, where:
|
|
|
* slice: is the name of the JSlice (e.g. my_slice) hosting the model
|
|
|
* model: is the name of the model where the machines are hosted
|
|
|
|
|
|
|
|
|
* POST: post is used to create a network slice (JModel). The only parameter required is the name of the hosting slice.
|
|
|
*slice_name= the name of the slice where to deploy one or more models
|
|
|
Message body for POST: The following body will create a set of machines.
|
|
|
{
|
|
|
"machines-list":[
|
|
|
{
|
|
|
"machine-type": "lxc",
|
|
|
"machine-template": "",
|
|
|
"mid_model": "k2",
|
|
|
"series": "xedial",
|
|
|
"mid-model-host": "",
|
|
|
"memory": "5",
|
|
|
"disc-size":"2",
|
|
|
"os-series":"xenial",
|
|
|
"auto": "True"
|
|
|
|
|
|
},
|
|
|
{
|
|
|
"machine-type": "lxc",
|
|
|
"machine-template": "",
|
|
|
"mid_model": "k3",
|
|
|
"series": "xedial",
|
|
|
"mid-model-host": "",
|
|
|
"memory": "5",
|
|
|
"disc-size":"2",
|
|
|
"os-series":"xenial",
|
|
|
"auto": "False"
|
|
|
}
|
|
|
|
|
|
]
|
|
|
|
|
|
}
|
|
|
|
|
|
This body will create two LXC VMs. A specific name is used to identify the machine within the model (for the first VM the id is "k2" and for the second VM the id is "k3". When the VM is created JUJU identification and VIM identification for thsi machine are corellated to the JMachine object.
|
|
|
|
|
|
* DELETE: is used to delete the Jmachine. Parameters required are the slice name, the model name and machines list to delete.
|
|
|
*slice_name= the name of the slice that is hosting the model
|
|
|
*model_name= the name of the model to delete
|
|
|
# 4. Prepare lxd for juju
|
|
|
Before using juju with lxd, you should firstly configure it, please refer to [https://docs.jujucharms.com](https://docs.jujucharms.com) for more details:
|
|
|
```bash
|
|
|
sudo lxd init
|
|
|
```
|
|
|
Here is an example of the configuration:
|
|
|
```
|
|
|
Would you like to use LXD clustering? (yes/no) [default=no]:
|
|
|
Do you want to configure a new storage pool? (yes/no) [default=yes]:
|
|
|
Name of the new storage pool [default=default]: lxd
|
|
|
Name of the storage backend to use (btrfs, ceph, dir, lvm, zfs) [default=zfs]:
|
|
|
Create a new ZFS pool? (yes/no) [default=yes]:
|
|
|
Would you like to use an existing block device? (yes/no) [default=no]:
|
|
|
Size in GB of the new loop device (1GB minimum) [default=15GB]:
|
|
|
Would you like to connect to a MAAS server? (yes/no) [default=no]:
|
|
|
Would you like to create a new local network bridge? (yes/no) [default=yes]:
|
|
|
What should the new bridge be called? [default=lxdbr0]:
|
|
|
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
|
|
|
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none
|
|
|
Would you like LXD to be available over the network? (yes/no) [default=no]:
|
|
|
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]
|
|
|
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:
|
|
|
```
|
|
|
After lxd configuration, use the following commands to add user as member of the 'lxd' group.
|
|
|
```bash
|
|
|
$ sudo adduser $USER lxd
|
|
|
$ newgrp lxd
|
|
|
```
|
|
|
# 5. Prepare juju for JoX
|
|
|
In order to use JoX, you should create the juju controller that you can use it later in JoX. TO list all the clouds configured with juju, please type:
|
|
|
```bash
|
|
|
$ juju clouds
|
|
|
```
|
|
|
In order to create juju controller, you can use:
|
|
|
```bash
|
|
|
$ juju bootstrap "cloud name" "name of your juju controller"
|
|
|
```
|
|
|
|
|
|
Message Body:
|
|
|
{
|
|
|
"m1":"k2",
|
|
|
"m2":"k3",
|
|
|
}
|
|
|
This body will delete machines "k2" and "k3"
|
|
|
In this documentation we use localhost (of lxd type) as cloud.
|
|
|
```bash
|
|
|
$ juju bootstrap localhost localhost
|
|
|
```
|
|
|
where `localhost` is the name of your controller. After that add your juju controller to the list of
|
|
|
*"clouds-list"* that is in the file ``DIR_JOX/common/config/jox_config.json``. If the name of your juju controller is
|
|
|
*localhost* then, you the *"clouds-list"* you can add it like
|
|
|
```
|
|
|
"clouds-list":
|
|
|
[
|
|
|
{
|
|
|
"cloud-name": "localhost",
|
|
|
"description": "name of you juju controller"
|
|
|
}
|
|
|
],
|
|
|
```
|
|
|
# 7. Add ssh-key to be used for kvm
|
|
|
If you intend to use kvm, you need to configure jox for the right ssh-key, user, and password.
|
|
|
For that, go the *"ssh-config"* in jox configuration file that is located at
|
|
|
``DIR_JOX/common/config/jox_config.json``
|
|
|
where *"ssh-key-directory"* is the full path to your ssh-key that you will use for kvm machines
|
|
|
|
|
|
## Note:
|
|
|
*If you would like run jox, nbi, and elasticsearch on
|
|
|
the same machine, then there is no need for further
|
|
|
changes in the jox_config.json. Otherwise,
|
|
|
change the host and the port for every component accordingly*
|
|
|
|
|
|
|
|
|
|
|
|
# 6. Run rabbitMQ (RBMQ)
|
|
|
JoX uses RabbitMq (RBMQ) as message bus between jox and nbi modules. You can run RBMQ by typing the following:
|
|
|
```bash
|
|
|
$ sudo service rabbitmq-server start
|
|
|
```
|
|
|
|
|
|
### JServices:
|
|
|
* path: `http://ip_address:8001/jox/slice/services?slice=XXX&model=YYY`
|
|
|
* methods:
|
|
|
* GET:
|
|
|
* Retrieves information about the JServices (e.g. HSS VNF) in JSON format, where:
|
|
|
* slice: is the name of the JSlice (e.g. my_slice) hosting the model
|
|
|
* model: is the name of the model where the services are hosted
|
|
|
|
|
|
|
|
|
* POST: post is used to create a network service (JService). The parameters required are the name of the hosting slice and the relevant model to deploy the service.
|
|
|
*slice: the name of the slice where to deploy one or more models
|
|
|
* model: is the name of the model where the services are hosted
|
|
|
Message body for POST: The following body will create a list of services.
|
|
|
{
|
|
|
"services-list": [
|
|
|
{
|
|
|
"description":"test service",
|
|
|
"entity_url":"mysql",
|
|
|
"application_name":"test-mysql",
|
|
|
"series":"xenial",
|
|
|
"channel":"stable",
|
|
|
"to":"k2"
|
|
|
},
|
|
|
{
|
|
|
"description":"test service",
|
|
|
"entity_url":"wordpress",
|
|
|
"application_name":"test-wordpress",
|
|
|
"series":"xenial",
|
|
|
"channel":"stable",
|
|
|
"to":"k3"
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
|
|
|
This body will create two services. The first service is the mysql service and is deployed in machine "k2" created in the previous section. The second service is the wordpress service and will be deployed in machine "k3" created in the previous section. Entity url is the name JUJU identifies a specific charm.
|
|
|
# 7. Run Elasticsearch (ES)
|
|
|
For monitoring, JoX uses elasticsearch where monitoring information are pushed automatically from juju models to ES. in order to use ES with JoX, run ES by the following:
|
|
|
```bash
|
|
|
$ sudo -i service elasticsearch start
|
|
|
```
|
|
|
|
|
|
* DELETE: is used to delete a list of services. Parameters required are the slice name, the model name and service list to delete.
|
|
|
*slice_name= the name of the slice that is hosting the model
|
|
|
*model_name= the name of the model to delete
|
|
|
# 8. Start JoX and nbi
|
|
|
At this stage, there is nothing to do other than just run jox and nbi.
|
|
|
For that, go to jox directory *DIR_JOX* and then in two different
|
|
|
terminals type ``./jox.sh`` in the first and ``./nbi.sh`` in the second
|
|
|
|
|
|
Message Body:
|
|
|
{
|
|
|
"s1":"test-mysql",
|
|
|
"s2":"test-wordpress",
|
|
|
}
|
|
|
This body will delete machines "test-mysql" and "test-wordpress". It also the resources that are related to them (i.e container machines "k2" and "k3")
|
|
|
### JRelations:
|
|
|
* path: `http://ip_address:8001/jox/slice/relations?slice=XXX&model=YYY`
|
|
|
* methods:
|
|
|
* GET: Retrieves the service relationships for a specific model that are returned in JSON format. Required parameters:
|
|
|
* slice: is the name of the JSlice (e.g. my_slice) hosting the model
|
|
|
* model: is the name of the model where the services are hosted
|
|
|
|
|
|
|
|
|
* POST: post is used to create service relations. The parameters required are the name of the hosting slice and the relevant model to deploy the relations.
|
|
|
*slice= the name of the slice where to deploy one or more models
|
|
|
* model: is the name of the model where the services are hosted
|
|
|
Message body for POST: The following body will create a list of services.
|
|
|
{
|
|
|
"relations-list": [
|
|
|
{
|
|
|
"service_a":"mysql",
|
|
|
"service_b":"mediawiki"
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
|
|
|
|
|
|
This body will create a service relationship between the "mysql" and the "mediawiki" applications.
|
|
|
- [Package Onboarding](https://gitlab.eurecom.fr/mosaic5g/jox/wikis/Package-Onboarding)
|
|
|
- [oai-epc use-case](https://gitlab.eurecom.fr/mosaic5g/jox/wikis/oai-epc-use-case)
|
|
|
- [Troubleshooting](https://gitlab.eurecom.fr/mosaic5g/jox/wikis/troubleshooting)
|
|
|
- [Come back to Home](Home)
|
|
|
|
|
|
|
|
|
\ No newline at end of file |