fix(ccaas): use peer-specific archive name to prevent package overwrite

[hellokitty09]

In CCaaS setups with multiple peers, the chaincode connection package ($CHAINCODE_LABEL.tar.gz) was being overwritten during the packaging loop because the filename didn't include the peer name. This caused all peers to install the last package, routing all chaincode requests to the last CCaaS container.

Changes:

• chaincodePackageCCaaS(): archive name now includes peer name (${CHAINCODE_LABEL}_${PEER_NAME}.tar.gz)
• chaincodeInstall(): detects peer-specific package if available, falls back to shared package for non-CCaaS chaincodes

TLS support is fully preserved.

Fixes #653

[joaormatos]

Hi,

This PR is attempting to solve the same problem as PR #680, which initially had a similar approach to this one — one package per peer — but has since been revised to address the fundamental issue with that approach that I described here: #653 (comment)

Also note the ensuing discussion about the distinction between:

A) using TLS at the network level, which is an important feature to maintain, and

B) using TLS in Peer-to-CCaaS connections, which is independent of the above and has very limited usefulness in typical Fablo use cases while introducing significant complexity and overhead.

PR #680 should currently fix issue #653 while preserving A and removing B.

Having optional support for B would be nice, but it may not be worth it considering the development and maintenance cost.

[joaormatos]

Hi,

This PR is attempting to solve the same problem as PR #680, which initially had a similar approach to this one — one package per peer — but has since been revised to address the fundamental issue with that approach that I described here: #653 (comment)

Also note the ensuing discussion about the distinction between:

A) using TLS at the network level, which is an important feature to maintain, and

B) using TLS in Peer-to-CCaaS connections, which is independent of the above and has very limited usefulness in typical Fablo use cases while introducing significant complexity and overhead.

PR #680 should currently fix issue #653 while preserving A and removing B.

Having optional support for B would be nice, but it may not be worth it considering the development and maintenance cost.