Consider options for applying different configuration options to different chaincode

[jt-nti]

It may be desirable to deploy different chaincode in different namespaces and, with #102, with different resource requests and limits.

Currently the chaincode packages only contain information about what is being deployed, not how to deploy it, and I am keen to keep this distinction. For example, requiring a new package to go through the chaincode lifecycle to change resource limits is not ideal. It would also reduce the likelihood of different organisations being able to share the same chaincode package.

[davidfdr]

Having a way for deploying each chaincode in a specifc namespace will be good and is a solution for the weird chaincode hash names. :)

[labibfarag]

consider also the pod availability if the pod is deleted / stopped, what are the other options other than restarting the peer to create the pod

[jt-nti]

Having a way for deploying each chaincode in a specifc namespace will be good and is a solution for the weird chaincode hash names. :)

@davidfdr I've also opened #105 to improve the pod names :)

consider also the pod availability if the pod is deleted / stopped, what are the other options other than restarting the peer to create the pod

@labibfarag The peer should already restart the chaincode if the pod is deleted/stopped as part of the Fabric builder and launcher implementation, so definitely open an issue if that isn't happening

[jt-nti]

The k8s builder is on the agenda for upcoming Fabric call on 17th April where I'm hoping to discuss what options there might be in Fabric for providing per-chaincode configuration to builders and launchers.