-
Notifications
You must be signed in to change notification settings - Fork 23
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
v1.2.2 #74
v1.2.2 #74
Conversation
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
I've started having a look through these changes (more formal review to come here later) - one question I do immediately have maybe one for discussion with @EnriqueL8 / wider community, is around how we're positioning these helm charts. Currently we have the FF CLI for getting people up and running with FireFly, this PR introduces similar functionality for KiND. We currently do not indicate that the FF CLI should be used for setting up production-capable FF networks, my concern is around whether or not we should be very clear in expressing the same thing for this helm chart. Is this helm chart a means for us to start local stacks using K8s, or is this actually now a basis from which we expect people to draw their actual networks from? |
Had a good chat here with @EnriqueL8 this morning, we're still strongly of the opinion that these are positioned as a means of deploying a development ready environment, but not something we would recommend for production usages. |
Summarising another discussion with @EnriqueL8 here - my concern is that right now this chart is copying in files from another consensys-owned helm chart (even though it is also OSS) and we don't want to keep those files in this repo. This problem is quite tricky to work around since the chart for besu is not published properly so we can't reference it externally. I think (and we've agreed) that the path forward here is to remove the besu charts, and change the Makefile to do a clone of the parent repository and then use the helm charts that way, thereby removing the dependency on us to maintain those charts, and preserving the same functionality. I'll add the changes into this PR. |
This PR adds a new set of charts to deploy more dependencies and a single command to start everything. Details on how to use it can be found in the README.md
This commit will deploy the latest release (v1.2.2) and I have another branch off of this one that will deploy v1.3.0 (when it is released)