White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue

Navigation

Page 100 of 144

Understanding OPNFV 100 os-odl_l3-fdio_dvr-ha x os-odl_l3-fdio-ha x os-odl_l3-nofeature-ha x x x os-odl_l3-ovs-ha x os-odl-bgpvpn-ha x os-onos-nofeature-ha x x x os-onos-sfc-ha x os-ovn-nofeature-ha x As you can see, if we ignore the association of scenarios to a specific installer, we are down to 21 scenarios that could be used as candidates for creating production environments. Installers In the spirit of providing choices, OPNFV uses four installers. These installers deploy all the software required for a scenario, and then also configure the software. Even though there are many differences, the fundamental mechanism of every installer is similar: the installer first installs an application on a specified "jumphost", which in turn runs and downloads, installs and configures all of the necessary software on designated compute and controller nodes resulting in a fully deployed scenario. This sets the stage for tests to be run against the scenario. The use of installers is fully automated through the CI pipeline. Frankly, if the only job of the installer was to set up these scenarios, there is no need for using more than one installer. However, these installers also have a life outside of CI testing. Beyond installation, they can also be used for day-2 lifecycle management tasks such as post-deployment configuration changes, capacity expansion, functionality enhancements, updates and upgrades. Some installers also have integration with monitoring software. For this reason, OPNFV provides installer choices. At this time, OPNFV does not test any day-2 functionality, so while interesting, a discussion about those capabilities is outside the scope of this book. Let's take a deeper look at the 4

Articles in this issue

view archives of White Papers - Understanding OPNFV