Open 2opremio opened 8 years ago
Related: #1049
Terminals: strong :-1:, Scope is not and should not be an ersatz terminal emulator, the security implications alone are horrifying
Logs: :+1:, "attach to multiple and mux" seems like a good and coherent extension of current attach functionality
should not
Let's try to keep an open mind and not talk in absolute terms, please.
the security implications alone are horrifying
Not considerably worse than what we have today. We allow terminals in priviledged containers plus, even in the case of the unpriviledged ones, the security guarantees offered by containers are not very strong.
Also, I am just trying to be realistic. There's administrative/diagnostic tasks for which scope is not going to be enough and you will need a terminal. In my perspective, making this simple and easy adds a lot of value.
Not considerably worse than what we have today
What we have today is horrifying in equal measure. I hope we all recognize that and will work to limit and scale back, rather than enhance, that horror. (edit) By that I mean adding security measures, perhaps ACLs with default-deny policies for example.
What we have today is horrifying in equal measure. I hope we all recognize that and will work to limit and scale back, rather than enhance, that horror.
I beg to differ, I've found it very useful when administering the service.
I've found it very useful when administering the service.
Of course it is useful. To you, and to anyone who happens to gain access to any host on port 4040 :)
(edit) In any case, I don't mean to usurp the discussion here, just one datapoint.
Of course it is useful. To you, and to anyone who happens to gain access to any host on port 4040 :)
Agreed. We should work on providing better security.
Please can we discuss this on Monday
Absolutely
On Friday, February 26, 2016, alexis richardson notifications@github.com wrote:
Please can we discuss this on Monday
— Reply to this email directly or view it on GitHub https://github.com/weaveworks/scope/issues/1050#issuecomment-189399939.
For the record we haven't resolved the points of contention here. I still feel strongly that multiple terminals as described in the OP would be an antifeature. Please don't begin implementation before we can have a roundtable on it :)
I am going to begin with the host logs, which are not controversial.
:+1:
You can already have multiple terminals in scope, by opening them in turn and using the "detach" button.
So what are we actually missing?
So what are we actually missing?
Those terminals are not synched nor tiled and we don't (yet) have host terminals.
The same applies to container/host logs. In this case you also want them interspersed.
Those terminals are not synched
What does "synched" mean?
nor tiled
IMO we should avoid creating a window manager in scope. If you want tiled windows then use a tiling window manager to do that for your detached scope terminal windows.
we don't (yet) have host terminals.
That is #1049. Not this issue.
In the container/host logs case you also want them interspersed.
That should be a separate issue. And presumably "interspersed" means there would only be one terminal.
What does "synced" mean?
The same keyboard input is sent to all terminals, which is very useful to diagnose problems across a group of machines (containers).
IMO we should avoid creating a window manager in scope. If you want tiled windows then use a tiling window manager to do that for your detached scope terminal windows.
As a user, that extra requirement/complexity of managing the detached windows (e.g. by installing a tiling window manager) wouldn't justify switching from my usual tmux setup (but this may be just me ...).
To clarify this further, my idea is to have a single terminal button for groups of containers/hosts (e.g. containers by image, all hosts ...) which would spawn all terminals at once, tiled into a single block. In order to provide this, Scope doesn't need to support custom tiling.
And presumably "interspersed" means there would only be one terminal.
Yes
For terminals: allow creating synched terminals à la tmux for multiple containers/hosts.
For logs: show the interspersed logs of multiple containers/hosts in the same window
This will greatly simplify doing diagnostics/administrative tasks:
First though, we may need a way to group containers/hosts. In any case we probably want a way to launch a terminal in all host, and we already have the aggregation of containers by image and by kubernetes service, which is a good starting point. @pidster has some great ideas about this.