search

typesafehub / conductr-cli

CLI for Lightbend ConductR
Other
16 stars 21 forks source link

WIP - do not merge - volumes flag. #464

Closed longshorej closed 7 years ago

longshorej commented 7 years ago

This PR modifies bndl to allow ports and volumes to be specified. What I'm not sure is if it's the right approach as it only works with docker and oci-image formats.

Perhaps we, instead of the approach in this PR, use annotations to store this information. Thus it becomes relevant to ConductR and would work well with bundles that have multiple components. The downside would be another ConductR PR is required.

Yet another approach would be for an annotation (perhaps com.lightbend.conductr.oci-config-transformations.<component name>) to hold an array of transformations using jq syntax. This way the CLI and end user could have a great deal of control over the final config.json that is executed without requiring changes to be made to the agent.

I think ultimately we need this functionality to make running third party docker images seamless, docker tooling doesn't really help here when you consider we are going to be using our own resolver code that doesn't require docker to be installed to run docker images.

huntc commented 7 years ago

How about building via docker-compose?

longshorej commented 7 years ago

That wouldn't support our goal of conduct load elasticsearch would it? That is, if we use tools such as docker compose then we can no longer use our own docker resolver. Ultimately, the ideas presented here would result in running images with a really natural syntax. Take a problematic image that doesn't declare volumes or ports, and it could still be run via e.g. conduct load bad-image --port 9000 --volume /var/lib/some-path.

markusjura commented 7 years ago

Yet another approach would be for an annotation (perhaps com.lightbend.conductr.oci-config-transformations.) to hold an array of transformations using jq syntax. This way the CLI and end user could have a great deal of control over the final config.json that is executed without requiring changes to be made to the agent.

I am preferring this approach because of its flexibility. Also, it is a dedicated annotation for oci config transformations. This is a better approach instead of having annotations such as volume because these properties belong more to the BundleAttributes itself, similar to memory and nrOfCpus. It feels wrong if some of this information would be part of the bundle attributes and some of them part of the annotations tree.

Another idea is to add the volume property to the bundle attributes itself (for all bundles). We could give it a default for all bundles and then user could override this default with the --volume flag in case of an oci image. Does that makes sense?

longshorej commented 7 years ago

There will be another PR that supersedes this.