NCP container plugin v4.1.2 changes in Tanzu Application Service Environments
Article ID: 297310
Updated On:
Products
VMware Tanzu Application Service
Issue/Introduction
NSX is strategically transitioning the consumption layer from the manager API to the policy API for its clients. As part of this continuous effort, Tanzu Application Service (TAS) environments leveraging NCP CNI now have the ability to migrate objects created on the manager API to the policy API starting in NSX-T tile v4.1.2.
This migration involves a lot of planning and it is recommended to get in touch with your field team's Solutions Architect so they can help you design and confirm your plan across multiple architectural layers before proceeding with the migration.
This Knowledge Base (KB) article is very specific to a known configuration issue while upgrading to NSX-T tile v4.1.2.
Prior to v4.1.2, the NSX-T tile resulted in a BOSH runtime-config only. As there was no VM to create, there was no need to configure an AZ or network for the NCP tile.
Starting in NSX-T tile v4.1.2, a post-deployment errand named "migrate-mp2p" to migrate TAS foundations to NSX Policy will run on a dedicated VM in the deployment created for the VMware NSX-t tile. Due to this, there is now a need to define a network and AZ. However Operations Manager (opsman) will not allow modifications to a tile's AZ or network after it is deployed as a safety precaution to avoid unexpected downtime.
Upgrading the NSX-T tile to v4.1.2 from an earlier version introduces a situation where an additional step is required to configure the tile. Please note, this is only applicable to upgrades of the NSX-T tile to v4.1.2 but not new installations. New installations of NSX-T tile v4.1.2 will be just fine as its the first time configuring the tile before deploying. There is a story to patch this behavior in opsman and this KB will be updated with patched versions once they are known. Until that time the following workaround can be used to proceed.
This migration involves a lot of planning and it is recommended to get in touch with your field team's Solutions Architect so they can help you design and confirm your plan across multiple architectural layers before proceeding with the migration.
This Knowledge Base (KB) article is very specific to a known configuration issue while upgrading to NSX-T tile v4.1.2.
Prior to v4.1.2, the NSX-T tile resulted in a BOSH runtime-config only. As there was no VM to create, there was no need to configure an AZ or network for the NCP tile.
Starting in NSX-T tile v4.1.2, a post-deployment errand named "migrate-mp2p" to migrate TAS foundations to NSX Policy will run on a dedicated VM in the deployment created for the VMware NSX-t tile. Due to this, there is now a need to define a network and AZ. However Operations Manager (opsman) will not allow modifications to a tile's AZ or network after it is deployed as a safety precaution to avoid unexpected downtime.
Upgrading the NSX-T tile to v4.1.2 from an earlier version introduces a situation where an additional step is required to configure the tile. Please note, this is only applicable to upgrades of the NSX-T tile to v4.1.2 but not new installations. New installations of NSX-T tile v4.1.2 will be just fine as its the first time configuring the tile before deploying. There is a story to patch this behavior in opsman and this KB will be updated with patched versions once they are known. Until that time the following workaround can be used to proceed.
Environment
Product Version: NSX Container Plugin v4.1.2 or later
Resolution
To update a tile's network and AZ after it has been previously deployed you can enable advanced mode in opsman.
This document has a walkthrough of enabling advanced mode.
Alternatively, if you have the om cli, then the following can be ran to put opsman in advanced mode
Once advanced mode is enabled, the AZ and network can be configured. Once its configured and saved, you can relock opsman by running the above commands with
This document has a walkthrough of enabling advanced mode.
Alternatively, if you have the om cli, then the following can be ran to put opsman in advanced mode
om curl -p /api/v0/staged/infrastructure/locked -x PUT --data '{"locked" : "false"}'
Once advanced mode is enabled, the AZ and network can be configured. Once its configured and saved, you can relock opsman by running the above commands with
'{"locked" : "true"}'
as the data.Feedback
Yes
No
Powered by
