Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Upgrade documentation for v3.0 #4980

Merged
merged 1 commit into from
Sep 17, 2024
Merged

Upgrade documentation for v3.0 #4980

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
219 changes: 0 additions & 219 deletions docs/source/enable_cc_lifecycle.md
View file
Open in desktop

This file was deleted.

6 changes: 3 additions & 3 deletions docs/source/updating_capabilities.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ In this example, the ``capabilities.json`` file looks like this (note: if you ar
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
"V3_0": {}
}
},
"version": "0"
Expand All @@ -74,7 +74,7 @@ In this example, the ``capabilities.json`` file looks like this (note: if you ar
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
"V2_5": {}
}
},
"version": "0"
Expand Down Expand Up @@ -134,7 +134,7 @@ Note that the `mod_policy` for this capability defaults to requiring signatures

**As a result, be very careful to not change this capability to a level that does not exist**. Because ordering nodes neither understand nor validate `Application` capabilities, they will approve a configuration to any level and send the new config block to the peers to be committed to their ledgers. However, the peers will be unable to process the capability and will crash. And even it was possible to drive a corrected configuration change to a valid capability level, the previous config block with the faulty capability would still exist on the ledger and cause peers to crash when trying to process it.

This is one reason why a file like `capabilities.json` can be useful. It prevents a simple user error --- for example, setting the `Application` capability to `V20` when the intent was to set it to `V2_0` --- that can cause a channel to be unusable and unrecoverable.
This is one reason why a file like `capabilities.json` can be useful. It prevents a simple user error --- for example, setting the `Application` capability to `V25` when the intent was to set it to `V2_5` --- that can cause a channel to be unusable and unrecoverable.

## Verify a transaction after capabilities have been enabled

Expand Down
24 changes: 7 additions & 17 deletions docs/source/upgrade.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,37 +8,27 @@ high level, a four step process.
1. Backup the ledger and MSPs.
2. Upgrade the orderer binaries in a rolling fashion to the latest Fabric version.
3. Upgrade the peer binaries in a rolling fashion to the latest Fabric version.
4. Update the orderer system channel and any application channels to the latest
4. Update application channels to the latest
capability levels, where available. Note that some releases will have
capabilities in all groups while other releases may have few or even no new
capabilities at all.
5. If you want to migrate your network by removing the orderer system channel,
check out :doc:`create_channel/create_channel_participation`.

For more information about capabilities, check out :doc:`capabilities_concept`.

For a look at how these upgrade processes are accomplished, please consult these
tutorials:

1. :doc:`upgrade_to_newest_version`. This topic discusses the important considerations
for getting to the latest release from the previous release as well as from
the most recent long term support (LTS) release.
for getting to the latest release.
2. :doc:`upgrading_your_components`. Components should be upgraded to the latest
version before updating any capabilities.
3. :doc:`updating_capabilities`. Completed after updating the versions of all nodes.

As the upgrading of nodes and increasing the capability levels of channels is by
now considered a standard Fabric process, we will not show the specific commands
for upgrading to the newest release. Similarly, there is no script in the ``fabric-samples``
repo that will upgrade a sample network from the previous release to this one,
as there has been for previous releases.

.. note:: It is a best practice to upgrade your SDK to the latest version as a
part of a general upgrade of your network. While the SDK will always
be compatible with equivalent releases of Fabric and higher, it might
be necessary to upgrade to the latest SDK to leverage the latest Fabric
features. Consult the documentation of the Fabric SDK you are using
for information about how to upgrade.
.. note:: SDK applications can be upgraded separate from a general upgrade of your Fabric network.
The `Fabric Gateway client API <https://github.com/hyperledger/fabric-gateway>`_ has been tested with Fabric v2.5 and v3.0.
If you have not yet migrated to the Fabric Gateway client API,
you can `migrate <https://hyperledger.github.io/fabric-gateway/migration/>`_ while using a Fabric v2.5 network,
or after you have upgraded to a Fabric v3.0 network. The legacy SDKs are no longer maintained and are not compatible with new v3.0 Fabric features such as SmartBFT consensus.

.. toctree::
:maxdepth: 1
Expand Down
Loading