- Ubuntu20.04 server image (64-bit variant required) (<http://releases.ubuntu.com/20.04/>)
**Reminder**: Although OSM could work with other base images, the only recommended are the ones above, since these are the images used in our daily tests.
In addition, you will need a Virtual Infrastructure Manager available so that OSM can orchestrate workloads on it. The following figure illustrates OSM interaction with VIMs and the VNFs to be deployed there:
- OSM communicates with the VIM for the deployment of VNFs.
...
...
@@ -55,8 +57,9 @@ Optionally, you can use the option `--k8s_monitor` to install an add-on to monit
You can include optional components in your installation by adding the following flags:
-**Kubernetes Monitor:**:`--k8s_monitor` (install an add-on to monitor the Kubernetes cluster and OSM running on top of it, through prometheus and grafana)
-**Kubernetes Monitor:**`--k8s_monitor` (install an add-on to monitor the Kubernetes cluster and OSM running on top of it, through prometheus and grafana)
-**PLA:**`--pla` (install the PLA module for placement support)
-**Old Service Assurance:**`--old-sa` (install old Service Assurance framework with MON and POL; do not install Airflow and Pushgateway)"
Example:
...
...
@@ -72,8 +75,6 @@ OSM installer includes a larger number of install options. The general usage is
./install_osm.sh [OPTIONS]
```
With no options, it will install OSM from binaries.
**Options:**
```text
...
...
@@ -82,45 +83,13 @@ With no options, it will install OSM from binaries.
-R <release>: use specified release for osm binaries (deb packages, lxd images, ...)
-u <repo base>: use specified repository url for osm packages
-k <repo key>: use specified repository public key url
--k8s_monitor: install the OSM kubernetes monitoring with prometheus and grafana
-m <MODULE>: install OSM but only rebuild the specified docker images (NG-UI, NBI, LCM, RO, MON, POL, KAFKA, MONGO, PROMETHEUS, PROMETHEUS-CADVISOR, KEYSTONE-DB, NONE)
-o <ADDON>: do not install OSM, but ONLY one of the addons (vimemu, elk_stack) (assumes OSM is already installed)
--showopts: print chosen options and exit (only for debugging)
--uninstall: uninstall OSM: remove the containers and delete NAT rules
-D <devops path> use local devops installation path
-h / --help: prints help
```
## Other installation methods
### How to install OSM in a remote OpenStack infrastructure
OSM could be installed to a remote OpenStack infrastructure from the OSM standard installer. It is based on Ansible and it takes care of configuring the OpenStack infrastructure before deploying a VM with OSM. The Ansible playbook performs the following steps:
1. Creation of a new VM flavour (4 CPUs, 8 GB RAM, 40 GB disk)
2. Download of Ubuntu 20.04 image and upload it to OpenStack Glance
3. Generation of a new SSH private and public key pair
4. Setup of a new security group to allow external SSH and HTTP access
5. Deployment of a clean Ubuntu 20.04 VM and installation of OSM to it
**Important note:** The OpenStack user needs Admin rights or similar to perform those operations.
The installation can be performed with the following command:
The options `-O` and `-N` are mandatory. The `-O` accepts both a path to an OpenStack openrc file or a cloud name. If a cloud name is used, the clouds.yaml file should be under `~/.config/openstack/` or `/etc/openstack/`. More information about the `clouds.yaml` file can be found [here](https://docs.openstack.org/python-openstackclient/latest/configuration/index.html)
The `-N` requires an external network name or ID. This is going to be the OpenStack network where the OSM VM is going to be attached.
The `--volume` option is used to instruct OpenStack to create an external volume attached to the VM instead of using a local one. This may be suitable for production environments. It requires OpenStack Cinder configured on the OpenStack infrastructure.
Some OSM installer options are supported, in particular the following: `-r -k -u -R -t`. Other options will be supported in the future.
### How to install Charmed OSM
Some cases where the Charmed installer might be more suitable:
### How to upgrade components from daily images in standard deployment
### How to install OSM in a remote OpenStack infrastructure
OSM could be installed to a remote OpenStack infrastructure from the OSM standard installer. It is based on Ansible and it takes care of configuring the OpenStack infrastructure before deploying a VM with OSM. The Ansible playbook performs the following steps:
1. Creation of a new VM flavour (4 CPUs, 8 GB RAM, 40 GB disk)
2. Download of Ubuntu 20.04 image and upload it to OpenStack Glance
3. Generation of a new SSH private and public key pair
4. Setup of a new security group to allow external SSH and HTTP access
5. Deployment of a clean Ubuntu 20.04 VM and installation of OSM to it
**Important note:** The OpenStack user needs Admin rights or similar to perform those operations.
The installation can be performed with the following command:
The options `-O` and `-N` are mandatory. The `-O` accepts both a path to an OpenStack openrc file or a cloud name. If a cloud name is used, the clouds.yaml file should be under `~/.config/openstack/` or `/etc/openstack/`. More information about the `clouds.yaml` file can be found [here](https://docs.openstack.org/python-openstackclient/latest/configuration/index.html)
The `-N` requires an external network name or ID. This is going to be the OpenStack network where the OSM VM is going to be attached.
The `--volume` option is used to instruct OpenStack to create an external volume attached to the VM instead of using a local one. This may be suitable for production environments. It requires OpenStack Cinder configured on the OpenStack infrastructure.
Some OSM installer options are supported, in particular the following: `-r -k -u -R -t`. Other options will be supported in the future.
## How to upgrade components from daily images in standard deployment
**Upgrading a specific OSM component without upgrading the others accordingly may lead to potential inconsistencies.** Unless you are really sure about what you are doing, please use this procedure with caution.
One of the commonest reasons for this type of upgrade is using your own cloned repo of a module for development purposes.
