emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 55eabe96c9: ; Improve manual for Tramp kubernetes method


From: Michael Albinus
Subject: Re: master 55eabe96c9: ; Improve manual for Tramp kubernetes method
Date: Tue, 25 Oct 2022 19:48:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> Hi Michael,

Hi Filipp,

> Something messed up in the mailing list (or in my Gnus config :-), I see
> only some messages in this thread from today.

I recommend to read such MLs via news.gmane.io (as I do). No problems today.

> Anyway: I'll test the new patch a bit later, now just wanted to return
> to current-context thing.  I'm still sure that we need to cache full
> config, because a user may change context as easily as a namespace.  In
> fact, a context _is_ a namespace, in a sense, just higher-level
> namespace.

My proposal is to check all fields of current-context. Like this:

--8<---------------cut here---------------start------------->8---
# kubectl config view -o jsonpath='{.contexts[?(@.name == "docker-desktop")]}'
{"context":{"cluster":"docker-desktop","user":"docker-desktop"},"name":"docker-desktop"}
--8<---------------cut here---------------end--------------->8---

This includes the name of the current context ("docker-desktop"), and if
the user switches to another context, or changes an attribute of the
current context, it will differ.

> Also, context refers to "cluster" by name, and cluster config also may
> change, etc.

Yes, but we cannot check everything. Compare it to an ssh connection,
which uses a Host entry in .ssh/config. If a user changes the Hostname
part of that Host entry, it isn't detected either by Tramp. The user is
responsible for this kind of changes, and the consequences.

And remember, this discussion started because you were concerned about a
changed namespace, nothing else.

> About checksum: it should not be very important to see what changed,
> because the user did the change herself.  It's more important to avoid
> storing sensitive data.

My proposal avoids to store sensitive data. The authentication token
you've mentioned is part of the Users config. We don't see it anymore
according to the latest patch.

> Filipp

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]