-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade guide document #1229
Upgrade guide document #1229
Conversation
NSX Terraform Provider offers support for [upgrading NSX components](https://docs.vmware.com/en/VMware-NSX/4.1/upgrade/GUID-E04242D7-EF09-4601-8906-3FA77FBB06BD.html). | ||
|
||
The provider support consists of several resources and data sources which can perform a complete upgrade cycle when applied correctly. | ||
The NSX upgrade process upgrades the manager components of NSX, Edge appliances, and the NSX bits on the compute hosts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another pedant suggestion, consider replacing with:
"The NSX Terraform provider support upgrades for NSX on ESX hosts, NSX Edge appliances, and NSX manager appliances"
|
||
The provider support consists of several resources and data sources which can perform a complete upgrade cycle. | ||
The NSX Terraform provider support upgrades for NSX on ESX hosts, NSX Edge appliances, and NSX manager appliances. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets emphasize that upgrade configuration and state should be dedicated to upgrade only, and not shared with regular terraform config and state
Also do we want to recommend that state is cleared post successful upgrade?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done - I added a note at the beginning of the doc, about state management for upgrade.
host_group { | ||
display_name = "HostWithDifferentSettings" | ||
parallel = false | ||
hosts = ["375c260d-3196-487c-b5eb-046de958f6af"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should add host data source for this..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean, within the example? As we do have a host data source (transport_node, and host_transport_node).
Or do you mean a list-providing DS, e.g. nsxt_host_transport_nodes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think single one is enough. If we can use the existing DS for the transport node here, I think its preferrable
c9a5266
to
2ec4ba4
Compare
|
||
When preparation is complete, it is required to validate the readiness for upgrade using the | ||
[nsxt_upgrade_prepare_ready](../data-sources/upgrade_prepare_ready.html.markdown) data source. | ||
When NSX preparation results with failures or warnings, the data source will result will fail the upgrade. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will result will fail
=> will fail
Add a document describing the upgrade process. Signed-off-by: Kobi Samoray <[email protected]>
Add a document describing the upgrade process.
Plus improve precheck failure and warning reporting, as it lacks documentation on NSX side.