Cisco CloudCenter 22.214.171.124 Release Notes
First Published: December 2, 2020
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 126.96.36.199 to 4.9.1.
CloudCenter 188.8.131.52 is only available as an upgrade for existing customers from CloudCenter 184.108.40.206, CloudCenter 220.127.116.11, CloudCenter 18.104.22.168, CloudCenter 22.214.171.124, CloudCenter 126.96.36.199, CloudCenter 188.8.131.52, CloudCenter 184.108.40.206 or CloudCenter 220.127.116.11. Contact the CloudCenter Support team for additional details.
You must be at a minimum version of CloudCenter 18.104.22.168 to upgrade to CloudCenter 22.214.171.124.
Effective CloudCenter 126.96.36.199 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 188.8.131.52 from CloudCenter 184.108.40.206 or earlier release, be sure to review the CloudCenter 220.127.116.11 documentation.
See the Upgrade Overview page and the following table for additional details.
|Upgrading CentOS CloudCenter Components to CloudCenter 18.104.22.168|
|Appliance Jar Files?||Notes|
|22.214.171.124 or earlier||Yes||Yes (for CCO only)||Yes||Yes|
|126.96.36.199||No||Yes (for CCO only)||Yes||Yes||You should have already run os_upgrade when you upgraded to 188.8.131.52 – if you have not, you can run this upgrade now!|
|184.108.40.206 or later||No||No||No||Yes||Applicable to CloudCenter 220.127.116.11 or later|
|Upgrading Non-CentOS CloudCenter Components (RHEL) to CloudCenter 18.104.22.168|
|22.214.171.124 or earlier||No||Yes||Yes||Yes|
1 The os_upgrade command is not required when upgrading the REPO or Bundle store.
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.
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:
See Management Agent (Worker) Installation for additional details.
CloudCenter platform 126.96.36.199 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 functionality. See Deploying an Application for details on this function.
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
The CloudCenter Platform has officially deprecated support for the following clouds:
Effective CloudCenter 188.8.131.52, 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.
The following documentation changes were implemented in
Upgrade Issues (updated to used Init caps for Java and Docker)
Operating Systems (updated to add RHEL8 support)
Deployment Environments (added the limitations section)
End of Support Notices (updated the page to reflect the latest information for the EOL and EOS for Cisco CloudCenter products)
The following issues were identified in CloudCenter 184.108.40.206:
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 220.127.116.11 to 18.104.22.168. To work around this issue, run the following command on each of the CCO servers in your environment:
Deployments in a Suspended state in CloudCenter 4.9.1 get stuck during the Resuming state if you resume them after upgrading to CloudCenter 22.214.171.124. 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 126.96.36.199 to 188.8.131.52. Apply the steps provided in the 184.108.40.206 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 220.127.116.11 to 18.104.22.168 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:
SSH to the VM.
Navigate to the required location. For example:
Execute the following command:
The following issue was resolved/addressed in CloudCenter 22.214.171.124:
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 126.96.36.199, 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 188.8.131.52, 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