Use existing cluster modifications

[vdesabou]

Description

What behavior does this PR change, and why?

Author Validation

Describe the validation already done, or needs to be done, by the PR submitter.

Reviewer Tasks

Describe the tasks/validation that the PR submitter is requesting to be done by the reviewer.

[ybyzek]

@vdesabou the current method for cluster reuse in docker playground is described here, where the user has to export all this ENV parameters:

In case you want to use your own existing cluster, you need to setup these environment variables:

ENVIRONMENT: The environment id where your cluster is located (example: env-xxxxx)
CLUSTER_NAME: The cluster name
CLUSTER_CLOUD: The Cloud provider (possible values: aws, gcp and azure)
CLUSTER_REGION: The Cloud region (example us-east-2)
CLUSTER_CREDS: The Kafka api key and secret to use, it should be separated with semi-colon (example: <API_KEY>:<API_KEY_SECRET>)
SCHEMA_REGISTRY_CREDS (optional, if not set, new one will be created): The Schema Registry api key and secret to use, it should be separated with semi-colon (example: <SR_API_KEY>:<SR_API_KEY_SECRET>)

However, there is already a function in ccloud_library that does this from a source config file: it's called ccloud::generate_configs(). It is useful especially when the user already used ccloud-stack before which outputs a properties file, so user won't have to redefine those env parameters. Instead of setting ENV parameters, here is what the user workflow would be:

1. If the user created the original cluster via ccloud-stack, save the generated ccloud-stack output properties file from the original run. If user has a cluster NOT created via ccloud-stack, define a properties file that resembles this template. It encompasses the parameters requested by ENV in your usage
2. Run ccloud::generate_configs <configfile>, which automatically creates delta_configs/env.delta
3. Run source delta_configs/env.delta
4. Set additional parameters if needed, e.g. export CLUSTER_CREDS=$CLOUD_KEY:$CLOUD_SECRET

So ccloud_library.sh already sort of handles "existing" clusters, but it assumes user provides the properties file method for passing in the info (which is easy if ccloud-stack was used to create it) versus ENV parameters. What the library does NOT do is confluent [environment|kafka cluster|etc] set so the CLI won't be set properly. If you agree with the above workflow, maybe the better PR (see https://github.com/confluentinc/examples/pull/1095) would be to set the CLI properly based on the input properties file generated by the original creation of ccloud-stack. It actually has uses for people who switch between ccloud-stack configs.

WDYT? Can you please evaluate if this PR meets the need?

cc: @javabrett @gianlucanatali

[javabrett]

@vdesabou any thoughts on whether this can be closed, or is all or part of it still of use despite other related changes?

[vdesabou]

@javabrett Yes it can be closed. I'll continue to use my own fork for my needs.