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

Support OpenShift Origin #132

Closed
elyscape opened this Issue May 1, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@elyscape
Contributor

elyscape commented May 1, 2017

This tool seems very useful, but does not currently work with OpenShift Origin, which is based on Kubernetes. Some fairly minor changes are needed to get Telepresence working with Origin:

  1. Allow the remote pod to be run as non-root (#131)
  2. Improve logic for identifying the remote pod (related to #130)
  3. Allow configuration of the binary to run (e.g. call oc instead of kubectl)
  4. Either:
    1. create a pod directly or
    2. let the server choose which generator to use

For item 4.ii, the generator can be guided by the --restart flag to kubectl/oc run. When provided --restart=Always, kubectl will create a Deployment and oc will create a DeploymentConfig.

@itamarst

This comment has been minimized.

Contributor

itamarst commented May 2, 2017

Thanks for the detailed gap analysis!

Additional thought: item 3 could be done manually, but might be nice if there was some autodetection. Like, "I'm in an OpenShift repo, switch to oc" or something.

Beyond working at all, there's also working naturally as part of the OpenShift workflow. Telepresence needs some work just for Kubernetes (see #9), and similar work would probably make OpenShift nicer. That is:

  1. I am OpenShift user, I have some config for my service (or whatever OpenShift calls it). My service is running in OpenShift.
  2. Oops, bug report, I want to run a local copy and proxy it into OpenShift. I therefore want to automatically, with no editing/typing, swap out a telepresence proxy for my existing service.
  3. Done with that, want to swap back to the real image.

Something like that. That might be easier to think through given some real world usage, so this won't be part of an initial OpenShift support goal. I'll maybe move it into a new ticket once this work is done.

@itamarst

This comment has been minimized.

Contributor

itamarst commented May 2, 2017

Current thoughts on implementation plan:

  1. Do #131.
  2. Switch --new-deployment to rely on --restart.
  3. Add a new telepresence-openshift command line tool that knows about oc and identifies things based on DeploymentConfig instead of Deployment.

@itamarst itamarst added this to Next in Telepresence May 2, 2017

@itamarst itamarst added the enhancement label May 3, 2017

@elyscape

This comment has been minimized.

Contributor

elyscape commented May 3, 2017

I'm not sure creating a new tool is really that necessary. By doing something like kubectl/oc run telepresence --image=datawire/telepresence-k8s:0.42 --restart=Always --label telepresence=$TIMESTAMP to create the Deployment/DeploymentConfig, and then identifying the pod with kubectl/oc get pods --selector telepresence=$TIMESTAMP and deleting resources with kubectl/oc delete all --selector telepresence=$TIMESTAMP, the only thing that should really need to be added is the ability to select which binary to use, and that could be autodetected. OpenShift exposes an endpoint /version/openshift on the API server, but I believe Kubernetes will return a 404.

@itamarst itamarst moved this from Next to In progress in Telepresence May 12, 2017

@itamarst

This comment has been minimized.

Contributor

itamarst commented May 12, 2017

So, I think all the prerequisites are done... so plausibly all that needs doing (famous last words) is swap out oc for kubectl and DeploymentConfig for Deployment. I will attempt to do that next, testing against OpenShift Online version.

@itamarst

This comment has been minimized.

Contributor

itamarst commented May 12, 2017

Ah... it seems oc and kubectl share the same config and therefore the same context. So that means autodetection should be possible.

@itamarst

This comment has been minimized.

Contributor

itamarst commented May 12, 2017

Sketch of implementation:

  1. Check if oc is in path. If not, switch straight to Kubernetes mode.
  2. If yes, run oc version to verify it is OpenShift's oc. If it is.
  3. Parse kube config, figure out server URL. Check if server has /version/openshift endpoint. If so, use oc. Otherwise use kubectl.

If in OpenShift mode look for DeploymentConfig instead of Deployment. That should be only difference (theoretically...)

@itamarst

This comment has been minimized.

Contributor

itamarst commented May 12, 2017

I haven't done the conditional stuff, and tests aren't passing, but a simple end-to-end experiment of "can I run manually against OpenShift" appeared to work, so looking promising.

itamarst added a commit that referenced this issue May 16, 2017

Merge pull request #148 from datawire/openshift
OpenShift Origin support.

Fixes #132.

@itamarst itamarst moved this from In progress to Done in Telepresence May 16, 2017

@itamarst itamarst removed this from Done in Telepresence Jun 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment