atomicapp icon indicating copy to clipboard operation
atomicapp copied to clipboard

PROPOSAL: run provider client as another container

Open aweiteka opened this issue 10 years ago • 8 comments

Currently we rely on the host having the provider installed as installed software. There is a move to run these CLI clients as containers. Since we don't want to ship all providers in the atomic app itself it would be ideal to execute the provider call as an atomic run call. This requires two things:

  1. A library of supported providers is available to call.
  2. Update the providers to call atomic run <provider_image> from item no.1 above.

aweiteka avatar Jul 14 '15 13:07 aweiteka

+1, meant to add: I took a pass at this a while back, but got distracted. However, its a start: https://github.com/whitel/kubectl-docker. I think I hacked it up based on some other version(s). Let me know if I should take another look at it.

langdon avatar Jul 14 '15 14:07 langdon

@aweiteka by library you meen a list of images in Docker Hub which represent specific providers?

vpavlin avatar Aug 20 '15 12:08 vpavlin

@vpavlin yes, that was the thought. A set of images in <some_registry>. I think it's just a matter of time before clients (openshift, heat, kube, etc) will be containerized by default.

aweiteka avatar Aug 20 '15 12:08 aweiteka

so we wait a little before client containers do appear and in the meantime we spec out how that could be used with atomicapp?

goern avatar Aug 20 '15 18:08 goern

Wouldn't it be better to use providers API directly (if they have one) instead of relying on CLI clients?

kadel avatar Oct 20 '15 11:10 kadel

Yes, I think that would be a valid approach. The biggest issue might be tracking the API version.

I don't think the containerized client would be too hard to implement. If we provide a config key to specify the client image we could simply run the container. We would need to consider how provider artifacts are passed into the container.

aweiteka avatar Oct 20 '15 13:10 aweiteka

@kadel I think you're right about the API in the near-term, especially for openshift since we currently don't have a model to run "sidecar" images in pods. I closed #336.

aweiteka avatar Oct 21 '15 12:10 aweiteka

If we are moving to using the providers APIs rather than using the CLI then we should be able to close this: https://github.com/projectatomic/atomicapp/issues/407

For openshift provider I think we have PR already: https://github.com/projectatomic/atomicapp/pull/420

@aweiteka should we close this?

dustymabe avatar Nov 25 '15 14:11 dustymabe