Cisco CloudCenter 4.10.0.11 Release Notes

Release Date

First Published: December 2, 2020

Updated:

  • December 7, 2020: Updated the Documentation section to include a list of pages that were updated.

  • December 11, 2020: Added a post-upgrade issue (last bullet) to the Known Issues section.

  • January 21, 2021: Changed 4.9.1.1 to 4.9.1.

Installation

CloudCenter 4.10.0.11 is only available as an upgrade for existing customers from CloudCenter 4.10.0.3, CloudCenter 4.10.0.4, CloudCenter 4.10.0.5,  CloudCenter 4.10.0.6, CloudCenter 4.10.0.7, CloudCenter 4.10.0.8, CloudCenter 4.10.0.9 or CloudCenter 4.10.0.10. Contact the CloudCenter Support team for additional details.

Upgrade Path

You must be at a minimum version of CloudCenter 4.10.0.3 to upgrade to CloudCenter 4.10.0.11.

Effective CloudCenter 4.10.0.7 and later, the CloudCenter upgrade process downloads packages from a CentOS base and the extras repository via the internet. If you do not have internet connectivity, you must setup a local CentOS mirror and configure the CloudCenter components (CCM, CCO etc) to use the local mirror.

If you are upgrading directly to CloudCenter 4.10.0.11 from CloudCenter 4.10.0.10 or earlier release, be sure to review the CloudCenter 4.10.0.10 documentation.


See the Upgrade Overview page and the following table for additional details. 

Upgrading CentOS CloudCenter Components to CloudCenter 4.10.0.11
From

core_upgrade

Appliance Jar Files?Notes
 os_upgrade1?

MongoDB?

Component?
4.10.0.5 or earlierYesYes (for CCO only)YesYes
4.10.0.6NoYes (for CCO only)YesYesYou should have already run os_upgrade when you upgraded to 4.10.0.6 – if you have not, you can run this upgrade now!
4.10.0.7 or laterNoNoNoYesApplicable to CloudCenter 4.10.0.7 or later
Upgrading Non-CentOS CloudCenter Components (RHEL) to CloudCenter 4.10.0.11
4.10.0.10 or earlierNoYesYesYes

1 The os_upgrade command is not required when upgrading the REPO or Bundle store.

Architecture

  • CloudCenter 4.10.0.11 includes an enhancement to support application deployments on CentOS 8. See Operating Systems and Install Worker on a Linux Image for additional details.  

  • In some environments (for example, security concerns may prevent you from disabling IPtables after installing the worker), you may need to re-enable IPtables after installing the worker, if you do not want the application VMs to be disabled.  

    • If using customized AMIs for public clouds and if these AMIs contain IPtables rules (other than the cloud's security group details), then some applications may fail to run if you do not flush these rules.

    • The CloudCenter platform flushes the rules once during the dynamic bootstrap process. However, this flush is temporary – once the node reboots all the rules are restored in all OSs where the firewalld is operational. If you are unable to reboot your VM, try enabling the firewall rules that you need to re-add. If you opt to re-add these firewall rules, ensure that the ports required by your applications are open.

    • In OSs which only use IPtables (CentOS6 systems), be sure to enable IPtables using the following commands to restore the rules.

      chkconfig iptables on
      service iptables start
    • Ensure to correctly set the firewall rules required by your applications using the scripts.

    • The CloudCenter agent opens a the following non-standard port connections to Rabbit-MQ via TLS:

      tcp 0 0 172.31.18.150:44680 204.236.187.160:443 ESTABLISHED 11070/agent-lite
      tcp 0 0 172.31.18.150:44682 204.236.187.160:443 ESTABLISHED 11070/agent-lite
    • See Management Agent (Worker) Installation for additional details.

Clouds

CloudCenter platform 4.10.0.11 introduces support for VMware vCenter 7.0. See Datacenters and Private Clouds for additional details.  

Applications and Services

You can now have the option to create recurring schedules for your deployments. You can limit the recurrence time to a 15-minute granularity. See Application Tasks > Schedule Deployment for additional details.

This option is an enhancement to the scheduling of deployments functionalitySee Deploying an Application for details on this function.  

CloudCenter Management

No updates 

Administration and Governance

Restarting a VM on initial boot up can conflict with the agent installation process and lead to the deployment being stuck in the IN_PROGRESS state. If you expect any other service upgrade (for example, VMware tools upgrade) to trigger a restart of the VM at boot up time, be sure to delay the installation of the CloudCenter agent. After you restart the the other service (for example, VMware tools upgrade), you can begin the installation process for CloudCenter agent. To configure a delay in the CloudCenter agent installation process, follow these tips:  

  • In the worker image, create a pre-documented file (/etc/opt/.delay_in_agent_installation) and specify the delay period in seconds.

    If you do not specify the delay in the exact format, the agent installation starts immediately and causes the restart conflict. 

  • This delay should be sufficient enough to allow the VM reboot to finish first and not collide with the agent installation process.

  • See Install Worker on a Linux Image for additional details.

End of Life Notices

See End of Support Notices for additional details.

Deprecated

  • The CloudCenter Platform has officially deprecated support for the following clouds: 

  • Effective CloudCenter 4.10.0.11, Cisco does not disable SELinux on worker VMs and thus preserves image defaults. However, installing the worker or agent requires SELinux to be disabled. You will now see an error message to this effect during worker/agent installation and you may need to disable them as required in your environment.  

Documentation

The following documentation changes were implemented in CloudCenter 4.10.0.11:

Known Issues

The following issues were identified in CloudCenter 4.10.0.11:

  • If your environment has scripts that were specifically configured for lifecycle phases that run on Docker containers (for example, pre/post VM launch), then be aware that these applications fail to deploy when upgraded from CloudCenter 4.10.0.8 to 4.10.0.11. To work around this issue, run the following command on each of the CCO servers in your environment:  

    systemctl restart docker.service
  • Deployments in a Suspended state in CloudCenter 4.9.1 get stuck during the Resuming state if you resume them after upgrading to CloudCenter 4.10.0.11. To workaround this issue, be sure to verify that there are no deployments in a suspended state in CloudCenter  4.9.1 before trying the upgrade operation. All Suspended deployments need to have Resumed successfully while your environment is still in CloudCenter 4.9.1.  

  • The Schedule Benchmark function displays a recurring schedules option in the UI, but the recurrence is not triggered. The recurring schedules option (explained in the Applications and Services section above) is only supported for normal deployments, it is not supported for Benchmarking. This recurrence option should not be visible in the UI and will be removed in an upcoming release.  

  • Deployments on AzureRM cloud environments fail when upgraded from 4.10.0.3 to 4.10.0.11. Apply the steps provided in the 4.10.0.10 release notes > Editing AzureRM Settings section to ensure that the deployments complete.   


  • Out of the box images for CentOS 8 deployments fail on AWS due to subscription restrictions. You can optionally use custom images for CentOS 8 for deployments on AWS cloud. See Operating Systems for additional details.

  • As part of a post upgrade procedure from CloudCenter 4.10.0.3 to 4.10.0.8 if the VMs display an Error state, be sure to manually restart the agent to address this issue. To restart the agent, follow this procedure:

    1. SSH to the VM.

    2. Navigate to the required location. For example: 
      cd /etc/init.d/ 

    3. Execute the following command:
      ./agentd restart 

Resolved Issues

The following issue was resolved/addressed in CloudCenter 4.10.0.11:

  • CSCvu82774: The Docker version running on the CCO in CloudCenter 4.10.x has reached EOL and is deprecated. This version should be upgraded.   
    Resolution:  In CloudCenter 4.10.0.11, the CCO running on both CentOS and RHEL have been upgraded to use the Docker patch version 1.13.1-162.docker-1.13.1-162.git64e9980.el7.

  • CSCvv83682: When deploying a service without the CloudCenter agent or an agentless service, the deployment never ends. This is because of the dependency on VMware tools to provision the IP and hostname in vCenter. A virtual appliance that has a hardened proprietary OS (for example, IBM SDS appliance or another type of black box appliance) does not package VMware tools.  
    Resolution
    As part of the fix included in CloudCenter 4.10.0.11, the deployment skips the IP Address verification if the deployed VM does not have VMware tools installed and the deployment proceeds as designed.


  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks