In my testing of the new MetroAE Croxley container deployment on CentOS 7, I have found the following installation instructions for Docker CE to be accurate and reliable: https://docs.docker.com/install/linux/docker-ce/centos/ Docker Community Edition (CE) is ideal for individual developers and small teams looking to get started
1.1.0 and 1.1.1 versions of the MetroÆ Docker container were built with a defect that caused them put the UI database inside the container instead of in the data directory on the Docker host. The following procedure details the steps to upgrade the container without
If you have passwords that break the yaml format. i.e. beginning with ! or | etc, they need to be special handled. They can be entered into the credentials.yml deployment file surrounded by quotes. However, due to the way encrypted passwords are processed by MetroAE,
We’ve recently provided support for a Nuage Networks VSP upgrade scenario in which the existing Nuage components had been installed months back. The customer had a 3-VSD cluster, a pair of VSCs, and a 3-ES cluster. Metro is designed to support exactly this scenario. One
We recently saw a user encounter this error when running vsc_health prior to upgrading an existing installation of VSP: unable to open shell. Please see: https://docs.ansible.com/ansible /network_debug_troubleshooting.html#unable-to-open-shell There are several other Forum topics on this error. For example: https://devops.nuagenetworks.net/forums/topic/unable-to-open-shell-error-take-2/. But this case was a bit different.
Question In the GitHub repo the DOCKER.md refers to the metroae command being used to launch the container as well as initiate automation deployments and workflows within. How can the container be launched from the command line with command examples? Answer When you run the
We recently had a report of the following error during vsd-predeploy: TASK [vsd-predeploy : Get the public key for the current user] ************************************* fatal: [vsd1.xlelab.lab -> localhost]: FAILED! => {“changed”: true, “cmd”: [“cat”, “~/.ssh/id_rsa.pub”], “delta”: “0:00:00.022623”, “end”: “2018-10-09 10:57:24.514944”, “failed”: true, “msg”: “non-zero return code”,
Have you seen this error? unable to open shell. Please see: https://docs.ansible.com/ansible /network_debug_troubleshooting.html#unable-to-open-shell We’ve written previously about a few ways to handle the situation when MetroÆ hits a problem connecting to the VSC using the Ansible sros_command and sros_config modules. The other topic focuses on making sure that you
As part of the installation of VRS on Linux compute blades, MetroAE follows best practices and executes a yum update. It also installs mandatory prerequisite packages that VRS software requires. Under certain conditions, we have found that the package updates fail with an error message of
The VSP Install Guide makes a best-practice recommendation to use the fallocate command on a Linux hypervisor when copying the qcow2 image file. fallocate will tell the file system on the hypervisor to pre-allocate disk space for the file, preventing a potential out-of-space error as the qcow2 grows. The
You can download MetroÆ from github.com as a zip file. It is just over 2 MB in size. scp the file to your MetroÆ host and unzip it. That will get the latest MetroÆ code into your server without Internet access. netaddr andn other packages
MetroAE does not require that you have used it to install when you want to use it for upgrade or health checking. We 100% support working for this use case. There is an additional requirement for such a use case, however: You must manually copy
We recently saw a problem where a user was having trouble doing an install via ./metroae install_everything. The problem: metroae was completing without doing anything. In the output, every component type displayed a message like this: [WARNING]: Could not match supplied host pattern, ignoring: vstats PLAY
We recently had a user stumble over input data validation. In MetroAE v3, all input data in your deployments folder is schema validated. This means that every file in your deployment must conform to the schema. This includes required data. In the case under discussion,
Our lab machines tend to have small memory sizes. When we do our testing, we often ‘cheat’ by allocating less RAM for Nuage VMs that we spin up on hypervisors. This is *Not* acceptable in a production environment, but can be useful in a PoC
We faced a scenario in our lab that may be of interest to some of you. We re-purposed an old bare-metal server running CentOS 7.3 as a hypervisor/target server for a MetroÆ test. On our first attempt to install a VSD, we ran out of
MetroAE tests to see if a node is already running before it tries to instantiate it. For example, if a VSD is up and running, we will skip the vsd-predeploy step, saving you time. One of the conditions that can cause the check-node-running task to
Jinja2 substitution in deployment files is not currently supported. Many build_vars files included “{{ dns_domain }}” tags. In the v3.0.0 convert_build_vars_to_deployment script, it carried these substitutions into the deployment files and thus corrupted them. This is fixed in v3.0.1 to perform the substitution beforehand. If
If when running the convert_build_vars_to_deployment.py script, you get the following error: AttributeError: ‘IPAddress’ object has no attribute ‘netmask_bits’ This is likely because the Python “netaddr” package is old on your system. The package can be upgraded using: $ pip install –upgrade netaddr You can check
In my testing of the new MetroAE Croxley container deployment on CentOS 7, I have found the following installation instructions for Docker CE to be accurate and reliable: https://docs.docker.com/install/linux/docker-ce/centos/ Docker Community Edition (CE) is ideal for individual developers and small teams looking to get started
By default, MetroAE will establish TLS OpenFlow channels from the VSCs to the forwarding-plane components, VRS and NSGv. TLS is required for NSGV/VNS, but not for VRS/VCS. In order to turn off TLS for your data-center VCS deployment, you would edit the following parameter in common.yml in
We sometimes see an issue when running an install with MetroAE that results in the following error: 2018-10-27 15:42:48,890 p=17607 u=root | fatal: [vsc2.mgmt.vnspoc.net -> localhost]: FAILED! => { “changed”: false, “failed”: true, “msg”: “unable to open shell. Please see:https://docs.ansible.com/ansible/network_debug_troubleshooting.html#unable-to-open-shell” } If you follow
A common problem we hear from the field is an error when MetroAE attempts to execute a yum update on the VSDs. This takes place during the vsd-deploy phase and results in this error text: This problem is going to prevent you from moving forward
We recently saw a user experiencing an error running the MetroAE setup script: # ./metro-setup.sh Setting up Nuage Metro Automation Engine Checking user privileges… [ OK ] Checking OS type… [ OK ] Checking OS version… [ OK ] Installing epel-release… [ OK ] Installing
With the introduction of Croxley, MetroÆ supports a new, schema-validated method of user input. The implementatino is such that now each section of the old build_vars.yml file now has its own file: vsds.yml vscs.yml common.yml and so on As an aid to hep you convert
