Merge pull request #821 from nuagenetworks/vsc_health_username

Patch fixes staged for v2.4.5

Documentation/RELEASE_NOTES.md

@@ -1,4 +1,14 @@
 # Metro Automation Engine Release Notes
+## Release 2.4.5
+### Resolved Issues
+* Set validate_certs to no for VMware playbooks
+* Clean socket files to work around Ansible persistent connection bug
+* Fix vsc_health and vstat_health to support custom username and password
+* Remove vstat_health from UPGRADE procedures
+* Fix vstat-vsd-health role to only run when VSTATs are defined
+* Removed unused datafile, upgrade_vars.yml
+* Removed unused playbooks, vsc_ha_node1_upgrade.yml and vsc_ha_node2_upgrade.yml
+
 ## Release 2.4.4
 ### New Features and Enhancements
 * upgrade VSTAT and VSC operating with user other than root
@@ -13,10 +23,10 @@
 ## Release 2.4.3
 ### New Features and Enhancements
 * add 5.3.1 from version to VSTAT upgrade skip list
-* refactor logic behind destroy during install and upgrade, edit VSTAT list of versions to be skipped during upgrade.  
-* add vnc console access in VSD template  
+* refactor logic behind destroy during install and upgrade, edit VSTAT list of versions to be skipped during upgrade.
+* add vnc console access in VSD template
 * add vault encryption procedure doc
-* check the 'show router interface' command to verify that states for Adm and Oprv4 are correct for control interface  
+* check the 'show router interface' command to verify that states for Adm and Oprv4 are correct for control interface
 * add support for new cloud-init version for 5.3.2
 * add support for upgrade to version 5.3.2
 * add suppport for non-root usernames for VSD upgrade
@@ -29,7 +39,7 @@
 * add ability to customize passwords for VSD programs and services
 * add playbook to copy qcow2 files before predeploy step, add checks in predeploy step for qcow2 existence if skipCopyImages is set
 ### Resolved Issues
-* user-related fixes  
+* user-related fixes
    - vsd-predeploy role tries to use the password listed in user_creds.yml to authenticate in the vmware_vm_shell tasks, rather than root/Alcateldc, which it should be using for a freshly-deployed OVF.
    - roles/vstat-vsd-health/tasks/main.yml: Needs remote_user: "{{ vstat_username }}" on the monit_waitfor_service task, otherwise it tries to SSH into vstat using the local username on the metro host, not the root user.
    - roles/vstat-health/tasks/main.yml: Needs delegate to localhost.

Documentation/UPGRADE_HA.md

@@ -45,7 +45,7 @@ For this example, our clustered (HA) deployment consists of:
      `./metro-ansible vsd_ha_upgrade_deploy_2_and_3 -vvvv`
 
      The VSD nodes have been upgraded. If you experience a failure before the VSD install script runs, re-execute the command. If it fails a second time or if the failure occurs after the VSD install script runs, destroy the VMs (either manually or with the command `./metro-ansible vsd_ha_upgrade_destroy_2_and_3`) then re-execute the deploy command.
-     
+
 4. Power off VSD node one.
 
      `./metro-ansible vsd_ha_upgrade_shutdown_1 -vvvv`
@@ -83,7 +83,7 @@ For this example, our clustered (HA) deployment consists of:
 2. Backup and prepare VSC node one.
 
      `./metro-ansible vsc_ha_upgrade_backup_and_prep_1 -vvvv`
-     
+
      Ir you experience a failure, you can re-execute the command.
 
 3. Deploy VSC node one.
@@ -106,7 +106,7 @@ Upgrade your VRS(s) and then continue with this procedure. Do not proceed withou
 1. Backup and prepare VSC node two.
 
      `./metro-ansible vsc_ha_upgrade_backup_and_prep_2 -vvvv`
-     
+
      If you experience a failure, you can re-execute the command.
 
 2. Deploy VSC node two.
@@ -124,37 +124,31 @@ Upgrade your VRS(s) and then continue with this procedure. Do not proceed withou
 ## Upgrade VSTAT
 Our example includes a VSTAT node. If your topology does not include one, proceed to *Finalize the Upgrade* below.
 
-1. Run VSTAT health check (optional).
-
-     `./metro-ansible vstat_health -e report_filename=vstat_preupgrade_health.txt -vvvv`
-
-     You performed health checks during preupgrade preparations, but it is good practice to run the check here as well to make sure the VSD upgrade has not caused any problems.
-
-2. Backup the VSTAT node.
+1. Backup the VSTAT node.
 
      `./metro-ansible vstat_upgrade_data_backup -vvvv`
 
      Data from the VSTAT node is backed up in the NFS shared folder. If you experience a failure, you can re-execute the command.
 
-3. Power off the VSTAT node.
+2. Power off the VSTAT node.
 
      `./metro-ansible vstat_destroy -vvvv`
 
      VSTAT shuts down; it is not deleted. (The new node will be brought up with the new VM name.) You have the option of performing this step manually instead. If you experience a failure you can re-execute the command or power off the VM manually.
 
-4. Predeploy the new VSTAT node.
+3. Predeploy the new VSTAT node.
 
      `./metro-ansible vstat_predeploy`
 
-     The new VSD node is now up and running; it is not yet configured. If you experience a failure, delete the new node by executing the command `./metro-ansible vstat_upgrade_destroy` then re-execute the predeploy command.  
+     The new VSD node is now up and running; it is not yet configured. If you experience a failure, delete the new node by executing the command `./metro-ansible vstat_upgrade_destroy` then re-execute the predeploy command.
 
-5. Deploy the new VSTAT node.
+4. Deploy the new VSTAT node.
 
      `./metro-ansible vstat_deploy -vvvv`
 
      The new VSTAT node has been deployed and configured to talk with the VSD node. If you experience a failure, re-execute the command. If it fails a second time, destroy the VMs (either manually or with the command `./metro-ansible vstat_upgrade_destroy`) then proceed from the predeploy step above.
 
-6. Migrate data to new VSTAT node.
+5. Migrate data to new VSTAT node.
 
      `./metro-ansible vstat_upgrade_data_migrate -vvvv`
 
@@ -175,9 +169,9 @@ Our example includes a VSTAT node. If your topology does not include one, procee
 
 ## Questions, Feedback, and Contributing
 
-Ask questions and get support via email.  
-  Outside Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")  
-  Internal Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")  
+Ask questions and get support via email.
+  Outside Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")
+  Internal Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")
 
 Report bugs you find and suggest new features and enhancements via the [GitHub Issues](https://github.com/nuagenetworks/nuage-metro/issues "nuage-metro issues") feature.
 

Documentation/UPGRADE_SA.md

@@ -65,7 +65,7 @@ This example is for one VSC node. If your topology has more than one VSC node, p
 2. Backup and prepare the VSC node.
 
      `./metro-ansible vsc_sa_upgrade_backup_and_prep -vvvv`
-     
+
      If you experience failure, you can re-execute the command.
 
 3. Deploy VSC.
@@ -86,37 +86,31 @@ Upgrade your VRS(s) and then continue with this procedure. Do not proceed withou
 ## Upgrade VSTAT
 Our example includes a VSTAT node. If your topology does not include one, proceed to *Finalize the Upgrade* below.
 
-1. Run VSTAT health check (optional).
-
-     `./metro-ansible vstat_health -e report_filename=vstat_preupgrade_health.txt -vvvv`
-
-     You performed health checks during preupgrade preparations, but it is good practice to run the check here as well to make sure the VSD upgrade has not caused any problems.
-
-2. Backup the VSTAT node.
+1. Backup the VSTAT node.
 
      `./metro-ansible vstat_upgrade_data_backup -vvvv`
 
      Data from the VSTAT node is backed up in the NFS shared folder. If you experience a failure, you can re-execute the command.
 
-3. Power off the VSTAT node.
+2. Power off the VSTAT node.
 
      `./metro-ansible vstat_destroy -vvvv`
 
      VSTAT shuts down; it is not deleted. (The new node will be brought up with the new VM name.) You have the option of performing this step manually instead. If you experience a failure you can re-execute the command or power off the VM manually.
 
-4. Predeploy the new VSTAT node.
+3. Predeploy the new VSTAT node.
 
      `./metro-ansible vstat_predeploy`
 
-     The new VSD node is now up and running; it is not yet configured. If you experience a failure, delete the new node by executing the command then re-execute the predeploy command.  
+     The new VSD node is now up and running; it is not yet configured. If you experience a failure, delete the new node by executing the command then re-execute the predeploy command.
 
-5. Deploy the new VSTAT node.
+4. Deploy the new VSTAT node.
 
      `./metro-ansible vstat_deploy -vvvv`
 
      The new VSTAT node has been deployed and configured to talk with the VSD node. If you experience a failure, re-execute the command. If it fails a second time, destroy the VMs (either manually or with the command `./metro-ansible vstat_upgrade_destroy`) then proceed from the predeploy step above.
 
-6. Migrate data to new VSTAT node.
+5. Migrate data to new VSTAT node.
 
      `./metro-ansible vstat_upgrade_data_migrate -vvvv`
 
@@ -137,9 +131,9 @@ Our example includes a VSTAT node. If your topology does not include one, procee
 
 ## Questions, Feedback, and Contributing
 
-Ask questions and get support via email.  
-  Outside Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")  
-  Internal Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")  
+Ask questions and get support via email.
+  Outside Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")
+  Internal Nokia: [[email protected]](mailto:[email protected] "send email to nuage-metro project")
 
 Report bugs you find and suggest new features and enhancements via the [GitHub Issues](https://github.com/nuagenetworks/nuage-metro/issues "nuage-metro issues") feature.
 

build_vars.yml

@@ -42,7 +42,6 @@ upgrade_from_version: '4.0.11'
 upgrade_to_version: '5.2.1'
 
 ## VSTAT UPGRADE ONLY!
-# Required only when upgarding to 4.0.11 versions and below
 ## NFS export that will be mounted on the VSTAT for backup and restore.
 ## Includes the server ip with the folder path. The default is 'NONE'
 ## Uncomment and provide an NFS export to mount if VSTAT upgrade.

library/monit_waitfor_service.py

@@ -92,7 +92,7 @@ def status(proc_name):
     if desired_state:
         module.exit_json(changed=True, name=proc_name, state=monit_stats)
     else:
-        module.fail_json(msg="Process %s did not transitioned to active within %i seconds" % (proc_name, timeout_seconds))
+        module.fail_json(msg="Process %s did not transition to active within %i seconds" % (proc_name, timeout_seconds))
         # Run the main