You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 5, 2024. It is now read-only.
Update [02-18-2022]
I've been experimenting with deploying multiple peers for an org in the same namespace. Using the existing configuration with external chaincode, im able to deploy a peer 2 to the same namespace and use the same chaincode pod that was deployed as part of the peer 1 release.
There's a modification that is required here. For chaincode operator, each release will deploy a chaincode deployment and operator if there's a chaincode object from values.yaml. The current implementation packages a new cc package(for each release) and this creation of package causes a potential conflict of the same intended chaincode to be used across the org.
I have a working example that will allow peer 2 to use the same chaincode package from a secret that was published from peer1's release.
I think this design is optimal as you can export the secret to import it across clusters if you have peers in other clusters to use.
Will add a PR when I get a chance but any feedback on this approach is appreciated OR if there's already an existing method from current implementation that I had missed would save me some effort.
The text was updated successfully, but these errors were encountered:
Hello do we have an example for this?
Update [02-18-2022]
I've been experimenting with deploying multiple peers for an org in the same namespace. Using the existing configuration with external chaincode, im able to deploy a peer 2 to the same namespace and use the same chaincode pod that was deployed as part of the peer 1 release.
There's a modification that is required here. For chaincode operator, each release will deploy a chaincode deployment and operator if there's a chaincode object from values.yaml. The current implementation packages a new cc package(for each release) and this creation of package causes a potential conflict of the same intended chaincode to be used across the org.
I have a working example that will allow peer 2 to use the same chaincode package from a secret that was published from peer1's release.
I think this design is optimal as you can export the secret to import it across clusters if you have peers in other clusters to use.
Will add a PR when I get a chance but any feedback on this approach is appreciated OR if there's already an existing method from current implementation that I had missed would save me some effort.
The text was updated successfully, but these errors were encountered: