-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Exec into Pod #1345
Comments
I may be getting ahead of myself, but a couple of thoughts re: requirements:
|
Here are a few browser based terminal libraries I'm looking at: xterm.js seems like the best based on a cursory look. It's a fairly active project and is used as part of Microsoft Visual Studio Code for their integrated terminal. |
In terms of requirements it looks like debugging is the main use case for exec into pod. This might affect the UI and how users discover the feature, but for now it doesn't seem like it's going to affect base functionality from what I described above. |
No |
@colemickens Cool. I didn't know about that one. |
Yep, I also think so.
Do you suggest to enable or disable this option by default? AFAIU this should be always enabled to make interactivity work? Or am I missing something?
Yes, exactly :) |
Do you have any proposals for interaction flow of this feature? My rough understanding is that users look at a pod and then there is a button or already opened card to start the interaction. But then there are problems. What's the interaction with the exec functionality? I sketched a rough mock of how I see it: It has some problems, though. E.g., it is hard to use when all you want to do is to open a bash inside your pod. But on the other hand it allows you to do everything that I'm interested what do you folks think. @romlein @rf232 ? |
You indeed need the About the mocks. I think it looks good if you really only want to do two/three things in the shell, but if you want to do more you might want to be able to 'popout' the terminal window and move it around yourself. |
Yeah, this may be pop-out-able card or a window by default. Like chrome debugging tools. |
Agreed with all stated above. @ianlewis Can you propose a complete user journey for a use case? E.g., "I want to debug a pod. First I start with |
@bryk Sure I'll write something up here. I think pop-out functionality isn't core. What do you think about doing it as a separate PR? |
@bryk can you assign this to me? |
Yes, definitely. If you can I'd even suggest doing this in several incremental PRs. Like: start with backend, then do frontend prototype that is still hidden, then finalize look and feel, then productionize. |
Here's a typical user journey on our side. I'm a developer, I'm testing out my new container and related manifest. I realized that the behavior isn't correct so I log in the Kubebernetes-Dashboard, looks at the deployment tab, identify my deployment, open up the pod page. I would then like to have a TAB where I could get access to a terminal for all of my containers running in my pod. I always like to run a Let me destroy the previous POD and have k8s recreate it to see if that helps. Ohhh my previous poped out Terminal just closed. I guess that the shutdown is now completed. |
Random thoughts since this popped in my Inbox again: I'm never just running I guess where I'm going with this is... it seems really awkward, to me, to have the input textbox above the output area. In fact, why is there a separate box at all? |
(And then of course after sending this comment, I realize that |
@colemickens I think we want to support both scenarios. I don't think anyone is saying |
@colemickens I think it could be possible to have a "exec into pod" prompt that is part of the terminal itself where you can type commands. Something like this? |
Yes, that was my first proposal to kick off the discussion. What we can do is to start a terminal-like window where you type exec commands. When you type something bogus, we tell you this and advice to run "bash". PS. in the middle of me writing this post I noticed @ianlewis with the same idea... :) That's good sign. |
@bryk I'm curious how you would figure something is bogus or not. I think we can just try to run the command given and give an error like "command not found" as returned by the API or container. BTW AFAIK Thoughts:
|
Yes, but they modify the pod, which I'd like us to avoid if possible.
Yes, exactly. And then augment this error with info that one should typically run "bash" or "sh" to do interactive sessions.
Yes, my example in the mock is unfortunate.
Yes, for exec commands.
Awesome idea. We'd say there that one can exec or start a terminal (if it is installed in the container).
That's a hard problem... I look forward to any ideas here. |
Agreed.
My thought is that we could just say this as part of the welcome message and be done with it. |
Hello everyone, while I have not much of personal experience with kubernetes:
I just want to point out that we would be really happy to help moving this feature forward in the following ways:
I already subscribed to stay up to date with the progress and please feel free to mention, if there is anything you believe we could help. |
I think I'm ok. I'm close to having a prototype working. I hit some snags In terms of xterm.js I don't have much of a problem yet though having the I hope to have a couple prototypes with different libraries so others can On Fri, Nov 4, 2016, 22:05 Piotr Bryk notifications@github.com wrote:
|
I thought I was close but the tooling just keeps getting in my way.
I would rather not but I guess I could try and implement something based on long-polling? For the prototype I am trying to make it work without the proxy by requiring that it be run by gulp serve:prod but that means I have to wrestle with the closure compiler, and making sure the 3rd party dependencies (xterm.js or hterm etc) get bundled properly. So much yak shaving... Any pointers or insights into how I could save some time writing the prototype would be helpful... |
I think we can leave these issues until a future time and just live with the inconvenience when doing work on the exec/attach feature until the issue is fixed in 1.6 (hopefully). |
All right, SGTM |
I've pushed a version that's working end-to-end to #1455. Currently it doesn't have a way to specify the command; it just uses "bash" and the command for testing purposes. I hope to resolve how to specify the command as part of UX discussions. For now the terminal works (doesn't support color yet). As I mentioned though, it requires that you run gulp build and run the dashboard binary out of the dist/amd64 directory with a local kubeconfig for auth with the API because kubectl proxy doesn't work with websockets. I hope this can suffice as a prototype. |
@bryk I think we can start UX discussions. I'm thinking of creating an Invision mock and having folks review it and add comments. Any other ideas to get started? Maybe set up a meeting? |
@ianlewis From what we've done in the past, the most effective strategy was to craft a rough design doc and follow it up with a meeting with eng + UX. The design doc served as the base for discussion. |
Ok. I'll write a markdown design doc and create a PR or is there a better
medium for the design doc?
…On Fri, Dec 2, 2016, 19:14 Piotr Bryk ***@***.***> wrote:
@ianlewis <https://github.com/IanLewis> From what we've done in the past,
the most effective strategy was to craft a rough design doc and follow it
up with a meeting with eng + UX. The design doc served as the base for
discussion.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1345 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADAibj4cVWyCear4p3FJh5ACYgXwsl3ks5rD-9ygaJpZM4KZcQ->
.
|
That's the best way. |
PR with design doc is up at #1585. PTAL |
Hi @ianlewis , this is an awesome feature, can't wait to see it included in stable release of K8s :) just want to share, that a simple shell implemented in Rancher too, and maybe you'd like to have a look at their implementation, who knows maybe you can get some new idea :) . in Rancher it's very basic, but works good and we use it for all troubleshooting needs (the scheduler we use is Kubernetes, but Rancher shows all containers on all hosts in a nice fashion so we use it too). btw my 2 cents (as K8s user) for "why would people need that" discussion, is that ALL our developers in department like the quick Rancher terminal, for experiments/debugging, it's available on their Staging/Dev Rancher cluster web UI, and everyone thinks it's supercool :) huge thanks to Ian for proposing this and working on it! (if I can help somehow with testing, let me know) |
@ianlewis any progress updates on this? |
It's been difficult to get time to work on dashboard due to work responsibilities/travel etc. Not likely to let up anytime soon either :-/ We might want to look at getting someone else to take a look at it since I'm solidly booked into late summer. |
The other day I too have started playing with this idea and I have created a separate prototype. I haven't looked at the code in #1455 yet. I think this can be finished with a couple of days work. I will post some code later. |
How should we handle the existence of both this issue and #1939? Should we close this issue in favor of the other? I've added #1939 to the 2017 milestone. |
Hi guys! I've just discovered Exec into Pod feature, thanks to #2155. Looks pretty useful! After trying the new button for a few containers, I noticed that the shell does not launch and the error says the following:
This occurs for the lightweight alpine-based images, which do not have Shall I open a new issue to discuss the customisation of bash/shell path? What do you think of this? |
We have actually a fallback mechanism that tries to access another supported shell if some is unavailable. It's first bash then sh. Only if all of them are unavailable then you won't be able to do anything. |
Thanks for your comment @floreks – the fact that bash falls back to shell explains why I see Any ideas what could be causing this? My containers with this behaviour are based on the alpine image (e.g. |
This is a bigger problem with session handling. In fact if first error occurs dashboard crashes. This is a known issue and we are working on improving exec feature. Right now it was added only for testing purposes so we can catch all issues. It is not considered stable. |
OK, I see. Just found another issue where you mention the problem I just described – will subscribed to it now. #2029 |
I am planning on working on "exec into Pod" functionality. I'm planning on gathering requirements via this issue and creating a proof of concept.
My general thought is that I will search for and use an existing library on the client side to display the terminal and take input. I'll use something like websockets or whatever transport the client side library supports for terminal events. The server side will use the exec endpoint from the Kubernetes API for connecting to the actual pod.
Related issues: #21 #550
The text was updated successfully, but these errors were encountered: