Installing and upgrading 1.2.1 #868
Conversation
stuclem
changed the title
|
Pending the information about the workaround to perform if you answer @anchal-agrawal @andrewtchin and @lgayatri can you please take a look? Thanks! |
| If the upgrade script detects that you are performing an upgrade from 1.1.x to 1.2.y, it migrates 1.1.x data to the new data model for 1.2.y. If it detects an upgrade from 1.2.x to 1.2.y, the data model is the same, so no data migration is required. | ||
|
|
||
| - If the script detects your upgrade path correctly, enter `y` to proceed with the upgrade. | ||
| - If the upgrade script detects the upgrade path incorrectly, for example if it asks you to proceed with an upgrade from 1.1.x to 1.2.y when you are upgrading 1.2.x to 1.2.y, enter `n` to abort the upgrade. |
There was a problem hiding this comment.
The prompt says to, but maybe add to contact GSS here?
There was a problem hiding this comment.
My assumption was that we would add a link to the workaround / troubleshooting doc that Anchal is working on here.
There was a problem hiding this comment.
Added placeholder link to troubleshooting doc.
| 11. Navigate to the upgrade script and run it. | ||
|
|
||
| <pre>$ cd /etc/vmware/upgrade</pre> | ||
| <pre>$ ./upgrade_1.1_to_1.2.sh</i></pre> | ||
| <pre>$ ./upgrade.sh</i></pre> |
There was a problem hiding this comment.
Will this doc be present only in the 1.2.1 tree? The file is still called upgrade_1.1_to_1.2.sh in a 1.2.0 OVA.
There was a problem hiding this comment.
We will only have one set of doc for 1.2.x. However, @mdubya66 says that we will be taking the download of 1.2.0 offline once 1.2.1 is out. So, after 1.2.1 is released, the 1.2.0 way of doing things will be redundant. Of course, there is a risk that a user might have downloaded the 1.2.0 OVA before 1.2.1 was released, and then attempts the upgrade after we publish the 1.2.1 doc update, but I decided to take that risk. The procedure is already long and complicated enough without adding the extra complexity of documenting alternative steps for a version that we don't want people to use anyway...
There was a problem hiding this comment.
I could add a note at the tops of the install and upgrade topics that says that the procedures relate to 1.2.1, and that they should not attempt to install or upgrade to 1.2.0. That doesn't look great, but at least it makes it clear that we don't want folks using 1.2.0.
There was a problem hiding this comment.
Makes sense. This is only an issue if the user is upgrading to 1.2.0, which we won't recommend anyway.
There was a problem hiding this comment.
I could add a note at the tops of the install and upgrade topics that says that the procedures relate to 1.2.1, and that they should not attempt to install or upgrade to 1.2.0. That doesn't look great, but at least it makes it clear that we don't want folks using 1.2.0.
That would be great. @mdubya66?
| 4. If vCenter Server is managed by an external Platform Services Controller, enter the administrator domain for the Platform Services Controller. If vCenter Server is managed by an embedded Platform Services Controller, press Enter without entering anything. | ||
| 5. Verify that the upgrade script has detected your upgrade path correctly. | ||
|
|
||
| If the upgrade script detects that you are performing an upgrade from 1.1.x to 1.2.y, it migrates 1.1.x data to the new data model for 1.2.y. If it detects an upgrade from 1.2.x to 1.2.y, the data model is the same, so no data migration is required. |
|
|
||
| - In the **Home** tab of the vSphere Integrated Containers Management Portal, check that all existing applications, containers, networks, volumes, and virtual container hosts have migrated successfully. | ||
| - In the **Administration** tab, check that projects, registries, repositories, and replication configurations have migrated successfully. | ||
|
|
||
| **IMPORTANT**: If you added the vSphere Integrated Containers Registry instance from the previous appliance to the previous version of the vSphere Integrated Containers Management Portal, and if the address of the appliance changed during the upgrade, two instances of vSphere Integrated Containers Registry appear in the **Administration** > **Registries** > **Source Registries** view. The registry named `default-vic-registry` is the registry instance that is running in the new appliance. Data from the registry that was running in the previous appliance has migrated to this instance. A registry instance with the name and address from the old, and now defunct, appliance is present in the list of registries. Delete this instance from the list. | ||
|
|
||
|
|
||
|
|
||
| **What to Do Next** |
There was a problem hiding this comment.
Should we link to troubleshoot_appliance_upgrade.md in this section?
There was a problem hiding this comment.
I added the link directly in the step when the script verifies the path
|
Towards #847. |
Fixes #840
Fixes #859
I will merge this once we release 1.2.1