OSM Public Wiki - User contributions [en]

OSM-MR8 Hackfest

2020-03-04T16:47:41Z

Romeromonser:

[[File:madrid4.jpg|750px|center|top]]
= Overview =
[[File:OSM-MR8_Hack.png|350px|right|top|link=https://portal.etsi.org/Meetings.aspx#/meeting?MtgId=37071]]

ETSI's Centre for Testing and Interoperability and the OSM community are organizing a new OSM Hackfest on 9-13 March 2020.

The event will be hosted by '''[https://www.telefonica.com/en/home Telefonica]''' in Madrid, Spain, co-located with the '''[https://portal.etsi.org/Meetings.aspx#/meeting?MtgId=37070 OSM-MR#8]''' meeting, offering a great opportunity to share and learn with OSM developers and module leaders, and explore opportunities for synergies and collaboration.

Participation to OSM Hackfests is free and open to all upon '''[https://portal.etsi.org/Meetings.aspx#/meeting?MtgId=37071 Registration]'''

== Venue ==
Distrito Telefónica

Edificio Central “A” - Auditorio del Centro de Demos

Ronda de la Comunicación, s/n

28050 Madrid

SPAIN

* ''[https://osm.etsi.org/wikipub/images/a/a1/Meeting_Invitation_OSM_Mid-Release_8_Madrid.docx Download OSM-MR#8 invitation, hotel recommendations and Visa Invitation Letter]''

[[File:OSM_community_lucca.jpg|800px|center]]

= Scope =
This OSM Hackfest will allow new users to get familiar with '''[https://osm.etsi.org/docs/user-guide OSM Release SEVEN]''' and exercise all the new functionalities, such as:
* OSM deployment on Kubernetes and self-monitoring of OSM Modules
* End-to-end Orchestration and life cycle management of real Network Services
** packaging, on-boarding,
** day-0/day-1/day-2 configuration
** service assurance: monitoring and closed-loop operation
* Running Cloud-Native Network Services
** modeling different types of Network Functions: Virtual, Physical, Cloud-native and Hybrid
** deploying a Kubernetes cluster
** deploying and orchestrating a cloud-native network service wit helm charts
** deploying and orchestrating a cloud-native network service with Juju bundles,
* Automated placement of Network Services for optimized edge deployments

In addition, experienced users and developers will have the opportunity to hack into OSM, build complex examples, fine-tune, test and demonstrate Release EIGHT or experimental features on the OSM Remote Labs network.

= Who should attend =
* VNF vendors, who want to onboard their VNF in OSM following best practices
* System Integrators, who want to develop their expertise with OSM
* Service providers, who want to get first hand operational experience with OSM
* Academia and Universities, who are using or considering OSM as platform for their research activities in networking
* Experimented developers and users that want to share and test with the community

[[File:OSM_hack_lucca2.png|800px|center]]

= Prerequisites =
* Seats are limited, registration is mandatory!
* Participants are expected to have user-level knowledge of Linux and be familiar with NFV and SDN concepts
* Bring your laptop
* A remote environment will be made available for participants, if you prefer to install OSM in your own laptop, please follow [https://osm.etsi.org/docs/user-guide/01-quickstart.html#installing-osm the OSM Quick Start Guide]
* OSM Hack 0: Introduction to NFV and OSM (see [https://osm.etsi.org/wikipub/index.php/OSM-MR8_Hackfest#OSM_Hackfest_Sessions below])

= Agenda =
* ''Tentative: Please note the sessions' times and contents may be subject to change''
<googlespreadsheet style="width:850px; height:400px">1nJn5HIE2D8xzY72MjIxJi4dONdRcnMgT7QQGzk4gGaQ</googlespreadsheet>

== OSM Hackfest Sessions ==
*''' [http://osm-download.etsi.org/ftp/osm-7.0-seven/MR8-hackfest/presentations/OSM%20MR8%20Hackfest%20-%20Hack%200%20-%20%20Introduction%20to%20NFV%20and%20OSM.pdf Hack 0 - Introduction to NFV and OSM]''' by Gianpietro Lavado, Whitestack
** [Virtual] Video & slides available
{{#evu:https://www.youtube.com/watch?v=JK3PpD9RpQc
|alignment=inline
|dimensions="120"
}}
* '''Welcome'''
** [Presentation] '''Welcome to Telefonica''' by José González Díaz, Chief Architecture Officer, Telefónica
** [Presentation] '''OSM-MR#8 Hackfest Logistics for the week''' by Francisco Javier Ramón Salguero. OSM Chair, Telefónica
* '''Hack 1 - OSM Architecture & Installation'''
** [Presentation] '''OSM Architecture overview''' by Gianpietro Lavado, Whitestack
** [Presentation] '''OSM Installation methods''' by Cyndi Alarcon, Whitestack
** [Hands-on] '''OSM Installation over Kubernetes''' by Cyndi Alarcon, Whitestack
** [Hands-on] '''OSM System Monitoring''' by Francisco Rodriguez & Alexis Romero, Indra
** [Hands-on] '''Integrating a VIM in OSM''' by Cyndi Alarcon, Whitestack
* '''Hack 2 - Network Services General Instantiation'''
** [Presentation] '''OSM Packages overview''' by Gianpietro Lavado, Whitestack
** [Hands-on] I'''nstantiating a basic Network Service''' by Cyndi Alarcon, Whitestack
** [Hands-on] '''Multi-VDU Network Services''' by Gianpietro Lavado, Whitestack
** [Hands-on] '''Automating Day-0 configuration through cloud-init''' by Gianpietro Lavado, Whitestack
** [Hands-on] '''Monitoring VNFs''' by Gianpietro Lavado, Whitestack
** [Hands-on] '''Orchestrating Network Slices with OSM''' by Felipe Vicens, Atos
** [Demo] '''Enabling high performance on VNFs - SDN-Assist''' by Alfonso Tierno, Telefonica
** [Demo] '''Automatic Placement of VNFs''' by Lars-Göran Magnusson, Arctos Labs
* '''Hack 3 - Automating VNF Day-1 & 2 operations'''
** [Presentation] '''Introduction to primitives in OSM''' by Gianpietro Lavado, Whitestack & David Garcia, Canonical
** [Presentation, Demo] '''Python Operator Framework''' by Dmitrii Shcherbakov, Canonical
** [Hands-on] '''Running primitives in VNFs''' by David Garcia and Dominik Fleischmann, Canonical
* '''Hack 4 - Running Containerized Network Functions'''
** [Presentation] '''K8s support in OSM''' by Gerardo Garcia de Blas, Telefonica
** [Hands-on] '''Instantiating containerized NFs over Kubernetes (KNFs)''' by Gerardo Garcia de Blas, Telefonica
** [Hands-on] '''Running primitives in KNFs''' by Gerardo Garcia de Blas, Telefonica
* '''Hack 5 - End-to-end VNF Package Onboarding in OSM'''
** [Presentation] '''Introduction to the VNF Onboarding Task Force & Resources''' by Gianpietro Lavado, Whitestack
** [Hands-on] '''Building an Evolved Packet Core VNF package from scratch''' by Gianpietro Lavado, Whitestack
** [Hands-on] '''Building an Evolved Packet Core KNF package from scratch''' by Gianpietro Lavado, Whitestack

== Hackfest Material ==
* [http://osm-download.etsi.org/ftp/osm-7.0-six/MR8-hackfest/presentations/ Presentations]
* [https://www.youtube.com/playlist?list=PLFqLBTy_ZDSj9mE3VPY0jYT0SoYV6fMMo Videos]



= Previous Hackfests =
* [[8th OSM Hackfest | 8th OSM Hackfest - Lucca (Italy)]]
* [[7th OSM Hackfest | 7th OSM Hackfest - Patras (Greece)]]
* [[6th OSM Hackfest | 6th OSM Hackfest - Santa Clara (CA, USA)]]
* [[5th OSM Hackfest | 5th OSM Hackfest - Barcelona (Spain)]]
* [[4th OSM Hackfest | 4th OSM Hackfest - Palo Alto (CA, USA)]]
* [[3rd OSM Hackfest | 3rd OSM Hackfest - Oslo (Norway)]]
* [[2nd OSM Hackfest | 2nd OSM Hackfest - Madrid (Spain)]]
* [[1st OSM Hackfest | 1st OSM Hackfest - Sophia Antipolis (France)]]

= Get involved in OpenSourceMANO =
* Join the [https://join.slack.com/t/opensourcemano/shared_invite/enQtMzQ3MzYzNTQ0NDIyLWVkNTE4ZjZjNWI0ZTQyN2VhOTI1MjViMzU1NWYwMWM3ODI4NTQyY2VlODA2ZjczMWIyYTFkZWNiZmFkM2M2ZDk OSM Community Slack Workspace]
* If your organisation is already an [https://portal.etsi.org/TBSiteMap/OSM/ListofOSMMembers.aspx OSM member], you can also:
** [https://webapp.etsi.org/createaccount/ Request an EOL account] (if you don’t have one yet)
** Subscribe [https://list.etsi.org/scripts/wa.exe?SUBED1=OSG_OSM&A=1 OSM general] and [https://list.etsi.org/scripts/wa.exe?SUBED1=OSM_TECH&A=1 OSM TECH] mailing lists
* If your organisation is not yet an OSM member:
** Learn [https://osm.etsi.org/about/how-to-join how to join], it is free and open to all
* Join the [https://osm.etsi.org/wikipub/index.php/OSM_Ecosystem OSM Ecosystem]

= Contact =
Please send your technical questions to [mailto:OSM_TECH@list.etsi.org OSM_TECH@list.etsi.org] or join the [https://join.slack.com/t/opensourcemano/shared_invite/enQtMzQ3MzYzNTQ0NDIyLWVkNTE4ZjZjNWI0ZTQyN2VhOTI1MjViMzU1NWYwMWM3ODI4NTQyY2VlODA2ZjczMWIyYTFkZWNiZmFkM2M2ZDk OSM Community Slack Workspace]

Questions about ETSI, joining OSM, this hackfest and future events can be sent to: [mailto:OSMSupport@etsi.org OSMSupport@etsi.org]

How to upgrade the OSM Platform

2019-12-10T15:46:56Z

Romeromonser:

__TOC__

== Upgrading the OSM platform ==
Due to the new architecture and dockerized components introduced from OSM Release FOUR, OSM platform upgrade is easier than ever. Upgrading to the latest minor version is as simple as running again the installer:

wget https://osm-download.etsi.org/ftp/osm-6.0-six/install_osm.sh
chmod +x install_osm.sh
./install_osm.sh

You will be asked if you want to proceed with the installation and configuration of LXD, juju, docker CE and the initialization of a local docker swarm, as pre-requirements. Please answer "y".

Then, some dialog messages related to LXD configuration will be shown. This is what you have to answer:
* Do you want to configure the LXD bridge? '''Yes'''
* Do you want to setup an IPv4 subnet? '''Yes'''
* ''<< '''Default values''' apply for next questions >>''
* Do you want to setup an IPv6 subnet? '''No'''

That's all. You will have the newest OSM version installed.

== Upgrading the OSM platform from docker images using the latest daily testing docker image or a specific tag ==

Upgrading to the latest daily docker image might lead to potential issues. Moreover, every new re-deployment of the stack will involve a download of a new docker daily image if it exists. Unless you are really sure about what you are doing, please use this procedure with caution.

You can use option -t in the installer to specify a specific docker tag to be used by the installer.

To install the latest daily images:
./install_osm.sh -t releasesix-daily

To install a previous version e.g. v5.0.3:
./install_osm.sh -t v5.0.3

The previous commands will do the installation and deployment of the stack, but will not make it persistent after re-deployments of the stack (or reboots). In order to make it persistent, you will have to update the file "docker-compose.yaml". Below an example to update it to use releasesix-daily tag:

sudo sed -i "s/ro\:\${TAG\:-latest}/ro\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/lcm\:\${TAG\:-latest}/lcm\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/mon\:\${TAG\:-latest}/mon\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/pol\:\${TAG\:-latest}/pol\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/nbi\:\${TAG\:-latest}/nbi\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/light-ui\:\${TAG\:-latest}/light-ui\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/keystone\:\${TAG\:-latest}/keystone\:\${TAG\:-releasesix-daily}/" /etc/osm/docker/docker-compose.yaml
docker stack rm osm && sleep 20
docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

The osmclient will have to be updated independently. In order to use the latest "testing" osmclient, you will have to update the debian repo to use the testing repo, remove the previous debian package and install the one from the new repo as follows:
sudo apt-get remove python-osmclient
sudo add-apt-repository -r "deb [arch=amd64] https://osm-download.etsi.org/repository/osm/debian/ReleaseSIX stable osmclient"
sudo add-apt-repository -y "deb [arch=amd64] https://osm-download.etsi.org/repository/osm/debian/ReleaseSIX-daily testing osmclient"
sudo apt-get update
sudo apt-get install python-osmclient
dpkg -l |grep python-osmclient #to check the installed version

== Upgrading a specific component to use your own cloned repo (e.g. for developing purposes) ==

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.

The procedure below involves building manually some docker images. The developer environment might require updating manually the MTU of the docker default "bridge" network following the procedure in this link: https://docs.docker.com/network/bridge/

For RO (ro and ro-db):
docker pull mysql:5
git clone https://osm.etsi.org/gerrit/osm/RO
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build RO -f RO/Dockerfile-local -t opensourcemano/ro:develop --no-cache
docker service update osm_ro --force --image opensourcemano/ro:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/ro\:\${TAG\:-latest}/ro\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For LCM:
git clone https://osm.etsi.org/gerrit/osm/LCM
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build LCM -f LCM/Dockerfile.local -t opensourcemano/lcm:develop --no-cache
docker service update osm_lcm --force --image opensourcemano/lcm:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/lcm\:\${TAG\:-latest}/lcm\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For MON:
git clone https://osm.etsi.org/gerrit/osm/MON
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build MON -f MON/docker/Dockerfile -t opensourcemano/mon:develop --no-cache
docker service update osm_mon --force --image opensourcemano/mon:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/mon\:\${TAG\:-latest}/mon\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For POL:
git clone https://osm.etsi.org/gerrit/osm/POL
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build POL -f POL/docker/Dockerfile -t opensourcemano/pol:develop --no-cache
docker service update osm_pol --force --image opensourcemano/pol:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/pol\:\${TAG\:-latest}/pol\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For NBI:
git clone https://osm.etsi.org/gerrit/osm/NBI
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build NBI -f NBI/Dockerfile.local -t opensourcemano/nbi:develop --no-cache
docker service update osm_nbi --force --image opensourcemano/nbi:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/nbi\:\${TAG\:-latest}/nbi\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For light UI:
git clone https://osm.etsi.org/gerrit/osm/LW-UI
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build LW-UI -f LW-UI/docker/Dockerfile -t opensourcemano/light-ui:develop --no-cache
docker service update osm_light-ui --force --image opensourcemano/light-ui:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/light-ui\:\${TAG\:-latest}/light-ui\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

== (OLD, CURRENTLY NOT WORKING) Upgrading only a specific component from source code to use the master branch or an old version (advanced users) ==

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.

You can use options -b and -m in the installer:
./install_osm.sh --help
usage: ./install_osm.sh [OPTIONS]
Install OSM from binaries or source code (by default, from binaries)
OPTIONS
...
-b <refspec>: install OSM from source code using a specific branch (master, v2.0, ...) or tag
-b master (main dev branch)
-b v2.0 (v2.0 branch)
-b tags/v1.1.0 (a specific tag)
...
-m <MODULE>: install OSM but only rebuild the specified docker images (RO, LCM, NBI, LW-UI, MON, KAFKA, MONGO, NONE)

Or to use master branch in LCM:
./install_osm.sh -m LCM -b master

Or to use an old version of MON:
./install_osm.sh -m MON -b tags/v5.0.2

How to upgrade the OSM Platform

2019-04-22T14:08:20Z

Romeromonser:

__TOC__

== Upgrading the OSM platform ==
Due to the new architecture and dockerized components introduced from OSM Release FOUR, OSM platform upgrade is easier than ever. Upgrading to the latest minor version is as simple as running again the installer:

wget https://osm-download.etsi.org/ftp/osm-5.0-five/install_osm.sh
chmod +x install_osm.sh
./install_osm.sh

You will be asked if you want to proceed with the installation and configuration of LXD, juju, docker CE and the initialization of a local docker swarm, as pre-requirements. Please answer "y".

Then, some dialog messages related to LXD configuration will be shown. This is what you have to answer:
* Do you want to configure the LXD bridge? '''Yes'''
* Do you want to setup an IPv4 subnet? '''Yes'''
* ''<< '''Default values''' apply for next questions >>''
* Do you want to setup an IPv6 subnet? '''No'''

That's all. You will have the newest OSM version installed.

== Upgrading the OSM platform from docker images using the latest daily docker image or a specific tag ==

Upgrading to the latest daily docker image might lead to potential issues. Moreover, every new re-deployment of the stack will involve a download of a new docker daily image if it exists. Unless you are really sure about what you are doing, please use this procedure with caution.

You can use option -t in the installer to specify a specific docker tag to be used by the installer.

To install the latest daily images:
./install_osm.sh -t releasefive-daily

To install a previous version e.g. v5.0.3:
./install_osm.sh -t v5.0.3

The previous commands will do the installation and deployment o the stack, but will not make it persistent after re-deployments of the stack. In order to make it persisten, you will have to update the file "docker-compose.yaml". Below an example to update it to use releasefive-daily tag:

sudo sed -i "s/ro\:\${TAG\:-latest}/ro\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/lcm\:\${TAG\:-latest}/lcm\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/mon\:\${TAG\:-latest}/mon\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/pol\:\${TAG\:-latest}/pol\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/nbi\:\${TAG\:-latest}/nbi\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/light-ui\:\${TAG\:-latest}/light-ui\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
sudo sed -i "s/keystone\:\${TAG\:-latest}/keystone\:\${TAG\:-releasefive-daily}/" /etc/osm/docker/docker-compose.yaml
docker stack rm osm && sleep 20
docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

The osmclient will have to be updated independently. In order to use the latest "testing" osmclient, you will have to update the debian repo to use the testing repo, remove the previous debian package and install the one from the new repo as follows:
sudo apt-get remove python-osmclient
sudo add-apt-repository -y "deb [arch=amd64] https://osm-download.etsi.org/repository/osm/debian/ReleaseFIVE-daily testing osmclient"
sudo apt-get update
sudo apt-get install python-osmclient
dpkg -l |grep python-osmclient #to check the installed version

== Upgrading a specific component to use your own cloned repo (e.g. for developing purposes) ==

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.

For RO (ro and ro-db):
docker pull mysql:5
git clone https://osm.etsi.org/gerrit/osm/RO
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build RO -f RO/docker/Dockerfile-local -t opensourcemano/ro:develop --no-cache
docker service update osm_ro --force --image opensourcemano/ro:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/ro\:\${TAG\:-latest}/ro\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For LCM:
git clone https://osm.etsi.org/gerrit/osm/LCM
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build LCM -f LCM/Dockerfile.local -t opensourcemano/lcm:develop --no-cache
docker service update osm_lcm --force --image opensourcemano/lcm:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/lcm\:\${TAG\:-latest}/lcm\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For MON:
git clone https://osm.etsi.org/gerrit/osm/MON
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build MON -f MON/docker/Dockerfile -t opensourcemano/mon:develop --no-cache
docker service update osm_mon --force --image opensourcemano/mon:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/mon\:\${TAG\:-latest}/mon\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For POL:
git clone https://osm.etsi.org/gerrit/osm/POL
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build POL -f POL/docker/Dockerfile -t opensourcemano/pol:develop --no-cache
docker service update osm_mon --force --image opensourcemano/pol:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/pol\:\${TAG\:-latest}/pol\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For NBI:
git clone https://osm.etsi.org/gerrit/osm/NBI
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build NBI -f NBI/Dockerfile.local -t opensourcemano/nbi:develop --no-cache
docker service update osm_nbi --force --image opensourcemano/nbi:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/nbi\:\${TAG\:-latest}/nbi\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

For light UI:
git clone https://osm.etsi.org/gerrit/osm/LW-UI
#you can then work in the cloned repo, apply patches with git pull, etc.
docker build LW-UI -f LW-UI/docker/Dockerfile -t opensourcemano/light-ui:develop --no-cache
docker service update osm_light-ui --force --image opensourcemano/light-ui:develop
# In order to make this change persistent after reboots or restart of the docker stack
# you will have to update the file /etc/osm/docker/docker-compose.yaml to reflect the change
# in the docker image, for instance:
# sudo sed -i "s/light-ui\:\${TAG\:-latest}/light-ui\:\${TAG\:-develop}/" /etc/osm/docker/docker-compose.yaml
# docker stack rm osm && sleep 60
# docker stack deploy -c /etc/osm/docker/docker-compose.yaml osm

== (OLD, CURRENTLY NOT WORKING) Upgrading only a specific component from source code to use the master branch or an old version (advanced users) ==

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.

You can use options -b and -m in the installer:
./install_osm.sh --help
usage: ./install_osm.sh [OPTIONS]
Install OSM from binaries or source code (by default, from binaries)
OPTIONS
...
-b <refspec>: install OSM from source code using a specific branch (master, v2.0, ...) or tag
-b master (main dev branch)
-b v2.0 (v2.0 branch)
-b tags/v1.1.0 (a specific tag)
...
-m <MODULE>: install OSM but only rebuild the specified docker images (RO, LCM, NBI, LW-UI, MON, KAFKA, MONGO, NONE)

Or to use master branch in LCM:
./install_osm.sh -m LCM -b master

Or to use an old version of MON:
./install_osm.sh -m MON -b tags/v5.0.2

OSM instantiation parameters

2019-04-12T07:40:13Z

Romeromonser:

When creating a NS instance, it is possible to pass instantiation parameters to OSM using the "--config" option of the client or the "config" parameter of the UI. In this section we will illustrate through some of the existing examples how to specify those parameters using OSM client:

===Specify a VIM network name for a NS VLD===
In a generic way, the mapping can be specified in the following way, where 'vldnet' is the name of the network in the NS descriptor and 'netVIM1' is the VIM network that you want to use:
--config '{vld: [ {name: vldnet, vim-network-name: netVIM1} ] }'

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_1_vnfd.tar.gz hackfest1-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_1_nsd.tar.gz hackfest1-ns]; images: [https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%202%20-%20Creating%20a%20basic%20VNF%20and%20NS.pdf creating a basic VNF and NS]''') in the following way:

osm ns-create --ns_name hf1 --nsd_name hackfest1-ns --vim_account openstack1 --config '{vld: [ {name: mgmtnet, vim-network-name: mgmt} ] }'

===Specify a VIM network name for an internal VLD of a VNF===
In this scenario, the mapping can be specified in the following way, where '1' is the member vnf index of the constituent vnf in the NS descriptor, 'internal' is the name of internal-vld in the VNF descriptor and 'netVIM1' is the VIM network that you want to use:
--config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal, vim-network-name: netVIM1} ] } ] }'

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:
osm ns-create --ns_name hf2 --nsd_name hackfest2-ns --vim_account openstack1 --config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal, vim-network-name: mgmt} ] } ] }'

===Specify IP profile information and IP for a NS VLD===
In a generic way, the mapping can be specified in the following way, where 'datanet' is the name of the network in the NS descriptor, ip-profile you have to fill the associated parameters with the data model ( [http://osm-download.etsi.org/ftp/osm-doc/nsd.html# NS data model] ), and vnfd-connection-point-ref is the reference to the connection point:
--config '{vld: [ {name: datanet, ip-profile: {...}, vnfd-connection-point-ref: {...} } ] }'

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:
osm ns-create --ns_name hf2 --nsd_name hackfest2-ns --vim_account openstack1 --config '{vld: [ {name: datanet, ip-profile: {ip-version: ipv4 ,subnet-address: "192.168.100.0/24", gateway-address: "0.0.0.0", dns-server: [{address: "8.8.8.8"}],dhcp-params: {count: 100, start-address: "192.168.100.20", enabled: true}}, vnfd-connection-point-ref: [ {member-vnf-index-ref: "1", vnfd-connection-point-ref: vnf-data, ip-address: "192.168.100.17"}]}]}'

===Specify IP profile information for an internal VLD of a VNF===
In this scenario, the mapping can be specified in the following way, where '1' is the member vnf index of the constituent vnf in the NS descriptor, 'internal' is the name of internal-vld in the VNF descriptor and ip-profile you have to fill the associated parameters with the data model ( [http://osm-download.etsi.org/ftp/osm-doc/vnfd.html VNF data model] ):

--config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal, ip-profile: {...} ] } ] }'

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:

osm ns-create --ns_name hf2 --nsd_name hackfest2-ns --vim_account openstack1 --config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal, ip-profile: {ip-version: ipv4 ,subnet-address: "192.168.100.0/24", gateway-address: "0.0.0.0", dns-server: [{address: "8.8.8.8"}] ,dhcp-params: {count: 100, start-address: "192.168.100.20", enabled: true}}}]}]} '

===Specify IP address and/or MAC address for an interface===

====Specify IP address for an interface====
In this scenario, the mapping can be specified in the following way, where '1' is the member vnf index of the constituent vnf in the NS descriptor, 'internal' is the name of internal-vld in the VNF descriptor ,ip-profile you have to fill the associated parameters with the data model ( [http://osm-download.etsi.org/ftp/osm-doc/vnfd.html VNF data model] ), 'id1' is the internal-connection-point id and 'a.b.c.d' is the IP that you have to specify for this scenario:

--config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal, ip-profile: {...}, internal-connection-point: [{id-ref: id1, ip-address: "a.b.c.d"}] ] } ] }'

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:
osm ns-create --ns_name hf2 --nsd_name hackfest2-ns --vim_account ost4 --config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal, ip-profile: {ip-version: ipv4 ,subnet-address: "192.168.100.0/24", gateway-address: "0.0.0.0", dns-server: [{address: "8.8.8.8"}] ,dhcp-params: {count: 100, start-address: "192.168.100.20", enabled: true}}, internal-connection-point: [{id-ref: mgmtVM-internal, ip-address: "192.168.100.3"}]}]}]}'

====Specify MAC address for an interface====
In this scenario, the mapping can be specified in the following way, where '1' is the member vnf index of the constituent vnf in the NS descriptor, 'id1' is the id of VDU in the VNF descriptor and 'interf1' is the name of the interface to which you want to add the MAC address:
--config '{vnf: [ {member-vnf-index: "1", vdu: [ {id: id1, interface: [{name: interf1, mac-address: "aa:bb:cc:dd:ee:ff" }]} ] } ] } '
You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_1_vnfd.tar.gz hackfest1-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_1_nsd.tar.gz hackfest1-ns]; images: [https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%202%20-%20Creating%20a%20basic%20VNF%20and%20NS.pdf creating a basic VNF and NS]''') in the following way:
osm ns-create --ns_name hf12 --nsd_name hackfest1-ns --vim_account openstack1 --config '{vnf: [ {member-vnf-index: "1", vdu: [ {id: hackfest1VM, interface: [{name: vdu-eth0, mac-address: "52:33:44:55:66:21"}]} ] } ] } '

====Specify IP address and MAC address for an interface====
In the following scenario, we will bring together the two previous cases

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:

osm ns-create --ns_name hf12 --nsd_name hackfest2-ns --vim_account ost4 --config '{vnf: [ {member-vnf-index: "1", internal-vld: [ {name: internal , ip-profile: {ip-version: ipv4, subnet-address: "192.168.100.0/24", gateway-address: "0.0.0.0", dns-server: [{address: "8.8.8.8"}] , dhcp-params: {count: 100, start-address: "192.168.100.20", enabled: true} }, internal-connection-point: [ {id-ref: mgmtVM-internal, ip-address: "192.168.100.3"} ] }, ], vdu: [ {id: mgmtVM, interface: [{name: mgmtVM-eth0, mac-address: "52:33:44:55:66:21"}]} ] } ] } '

===Force floating IP address for an interface===
In a generic way, the mapping can be specified in the following way, where 'id1' is the name of the VDU in the VNF descriptor and 'interf1' is the name of the interface:
--config '{vnf: [ {member-vnf-index: "1", vdu: [ {id: id1, interface: [{name: interf1, floating-ip-required: True }]} ] } ] } '

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:
osm ns-create --ns_name hf2 --nsd_name hackfest2-ns --vim_account openstack1 --config '{vnf: [ {member-vnf-index: "1", vdu:[ {id: mgmtVM, interface: [{name: mgmtVM-eth0, floating-ip-required: True }]} ] } ] } '

Make sure 'vim-network-name' in NS Descriptor has access to the outside to be able to use the parameter 'floating-ip-required'.

===Multi-site deployments (specifying different VIM accounts for different VNFs)===
In this scenario, the mapping can be specified in the following way, where '1 and 2' are the member vnf index of the constituent vnfs in the NS descriptor, 'vim1 and vim2' are the names of vim accounts and 'netVIM1 and netVIM2' are the VIM networks that you want to use:

--config '{vnf: [ {member-vnf-index: "1", vim_account: vim1}, {member-vnf-index: "2", vim_account: vim2} ], vld: [ {name: datanet, vim-network-name: {vim1: netVIM1, vim2: netVIM2} } ] }'
# NOTE: From release SIX (current master) add 'wim_account: False' (inside --config) to avoid wim network connectivity if you have not a WIM in your system

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_vnfd.tar.gz hackfest2-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_2_nsd.tar.gz hackfest2-ns]; images:[https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%203%20-%20Modeling%20multi-VDU%20VNF%20v2.pdf modeling multi-VDU VNF]''') in the following way:
osm ns-create --ns_name hf12 --nsd_name hackfest2-ns --vim_account openstack1 --config '{vnf: [ {member-vnf-index: "1", vim_account: openstack1}, {member-vnf-index: "2", vim_account: openstack3} ], vld: [ {name: mgmtnet, vim-network-name: {openstack1: mgmt, openstack3: mgmt} } ] }'

===Specifying a volume ID for a VNF volume===

In a generic way, the mapping can be specified in the following way, where 'VM1' is the name of the VDU, 'Storage1' is the volume name in VNF descriptor and '05301095-d7ee-41dd-b520-e8ca08d18a55' is the volume id:

--config '{vnf: [ {member-vnf-index: "1", vdu: [ {id: VM1, volume: [ {name: Storage1, vim-volume-id: 05301095-d7ee-41dd-b520-e8ca08d18a55} ] } ] } ] }'

You can try it using one of the examples of the hackfest ('''descriptors: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_1_vnfd.tar.gz hackfest1-vnf], [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/packages/hackfest_1_nsd.tar.gz hackfest1-ns]; images: [https://osm-download.etsi.org/ftp/osm-3.0-three/1st-hackfest/images/US1604.qcow2 ubuntu1604], presentation: [https://osm-download.etsi.org/ftp/osm-4.0-four/3rd-hackfest/presentations/20180626%20OSM%20Hackfest%20-%20Session%202%20-%20Creating%20a%20basic%20VNF%20and%20NS.pdf creating a basic VNF and NS]''') in the following way:

With the previous hackfest example, according [http://osm-download.etsi.org/ftp/osm-doc/vnfd.html VNF data model] you will add in VNF Descriptor:
<nowiki>
volumes:
- name: Storage1
size: 'Size of the volume'
</nowiki>

osm ns-create --ns_name h1 --nsd_name hackfest1-ns --vim_account openstack1 --config '{vnf: [ {member-vnf-index: "1", vdu: [ {id: hackfest1VM, volume: [ {name: Storage1, vim-volume-id: 8ab156fd-0f8e-4e01-b434-a0fce63ce1cf} ] } ] } ] }'

===Adding additonal parameters===

From release SIX (current master) additional user parameters can be added, and they land at vdu:cloud-init (Jinja2 format) and/or vnf-configuration primitives (enclosed by <>). Here is an example of VNF descriptor that uses two parameters called "touch_filename" and "touch_filename2"
<pre>
vnfd:
...
vnf-configuration:
config-primitive:
- name: touch
parameter:
- data-type: STRING
default-value: <touch_filename2>
name: filename
initial-config-primitive:
- name: config
parameter:
- name: ssh-hostname
value: <rw_mgmt_ip> # this paramater is internal
- name: ssh-username
value: ubuntu
- name: ssh-password
value: osm4u
seq: '1'
- name: touch
parameter:
- name: filename
value: <touch_filename>
seq: '2'
</pre>

And they can be provided with:
--config '{additionalParamsForVnf: [{member-vnf-index: "1", additionalParams: {touch_filename: your-value, touch_filename2: your-value2}}]}'