Can't get the kube context working
mastoj opened this issue · comments
Great stuff you have going here, I just need to get it working :)
I want the kubernetes context in my status bar, but it is just blank. My guess is that the script is running in some weird context so it doesn't have access to kubectl.
Is there a way to verify my assumption? Do you know how to fix it?
@mastoj Thanks for filing, and sorry you're having some trouble!
Can you verify that:
- You symlinked
/path/to/iterm-components/kubectl_context.pyto~/Library/Application\ Support/iTerm2/Scripts/AutoLaunch/kubectl_context.pyand that it's selected in the Scripts -> AutoLaunch menu kubectl contextshows up in the list of components in Preferences -> Profiles -> Session -> Configure Status Bar
Additionally, can you see if one/any of the other components work? The hello_world.py component in particular would be a good starting place, because it doesn't do anything based dynamically on your shell.
Let me know, and we'll see if we can get you sorted!
@daneah, I had already tried those things and it worked :). I even pulled up the iTerm REPL and tried to execute https://github.com/daneah/iterm-components/blob/master/kubectl_context.py#L18-L23 manually, and that is when I got the feedback on missing kubectl (I should probably have provided that information at start).
I don't know in what context the REPL is running, is it the same as for when the scripts are executed?
Also, if I use the absolute path it does work, but that is annoying :)
Understood! Is kubectl located in the usual place (/usr/local/bin/kubectl) and, more importantly, somewhere that's on your $PATH? I haven't run into this so I'm also trying to debug in my own head 😉
So I wasn't aware of the iTerm2 REPL feature. After trying it, the REPL also doesn't know about kubectl on my machine. The REPL appears to run in a different context than the AutoLaunch scripts, which appear to run in an interactive login shell. Can you try this?
First, remove the scrpit from AutoLaunch:
$ rm ~/Library/Application\ Support/iTerm2/Scripts/AutoLaunch/kubectl_context.pyThen restart iTerm2 and try running it manually:
$ cd /path/to/iterm-components/
$ python -m venv .venv
$ source .venv/bin/activate
$ pip install iterm2
$ python kubectl_context.py # this should bring up an "API access request" window
Let me know how this behaves.
Didn't work:
Traceback (most recent call last):
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/connection.py", line 284, in async_connect
await coro(self)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/connection.py", line 171, in async_main
await coro(connection)
File "kubectl_context.py", line 22, in main
await component.async_register(connection, kubectl_context_coroutine)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/statusbar.py", line 208, in async_register
await coro.async_register(connection, self)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/registration.py", line 238, in async_register
status_bar_component=component)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/notifications.py", line 315, in async_subscribe_to_server_originated_rpc_notification
rpc_registration_request=rpc_registration_request)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/notifications.py", line 434, in _async_subscribe
raise SubscriptionException(iterm2.api_pb2.NotificationResponse.Status.Name(status))
iterm2.notifications.SubscriptionException: DUPLICATE_SERVER_ORIGINATED_RPC
Traceback (most recent call last):
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/protocol.py", line 795, in transfer_data
message = await self.read_message()
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/protocol.py", line 863, in read_message
frame = await self.read_data_frame(max_size=self.max_size)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/protocol.py", line 938, in read_data_frame
frame = await self.read_frame(max_size)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/protocol.py", line 1018, in read_frame
extensions=self.extensions,
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/framing.py", line 121, in read
data = await reader(2)
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/streams.py", line 672, in readexactly
raise IncompleteReadError(incomplete, n)
asyncio.streams.IncompleteReadError: 0 bytes read on a total of 2 expected bytesThe above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/connection.py", line 130, in _async_dispatch_forever
data = await self.websocket.recv()
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/protocol.py", line 484, in recv
await self.ensure_open()
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/websockets/protocol.py", line 771, in ensure_open
raise self.connection_closed_exc()
websockets.exceptions.ConnectionClosedError: code = 1006 (connection closed abnormally [internal]), no reason
I think the above was due to the fact that I had the coroutine registered twice or something. Cleaned that up but it still doesn't work. It just hangs forever it seems. I cancelled it with ctrl-c and the following stack trace was written:
➜ iterm-components git:(master) python3 kubectl_context.py
^CTraceback (most recent call last):
File "kubectl_context.py", line 28, in
iterm2.run_forever(main)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/connection.py", line 343, in run_forever
Connection().run_forever(coro, retry, debug)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/connection.py", line 114, in run_forever
self.run(True, coro, retry, debug)
File "/Users/tomasjansson/git/mastoj/iterm-components/.venv/lib/python3.6/site-packages/iterm2/connection.py", line 181, in run
loop.run_until_complete(self.async_connect(async_main, retry))
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 471, in run_until_complete
self.run_forever()
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 438, in run_forever
self._run_once()
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 1415, in _run_once
event_list = self._selector.select(timeout)
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/selectors.py", line 577, in select
kev_list = self._kqueue.control(None, max_ev, timeout)
KeyboardInterrupt
It's supposed to run forever 😉 if you start it running, you should be able to add the status bar component and see the output of kubectl as the value.
So that is how it works... I'll try that.
Running it like that actually works... so for some reason it doesn't pick up my environment when running through AutoLaunch.
I'm afraid I'm not sure what else could be going on. Mine runs properly the manual way, and then when I add it to AutoLaunch it shows up as below and continues to work 😖
strange, mine shows up but for some reason the path when running doesn't seem to be correct.
Does the generic_command, when passed kubectl config current-context, yield you the proper result? I'd be thoroughly perplexed by that as they seem equivalent! Unless you're including the full path to the command there? I'm able to pass just the command without a path. You could debug this a bit by using which kubectl as your arbitrary command 😄
@mastoj I just tried echo "$PATH" as a generic command and was surprised to see that my $PATH was not the same as it is in my interactive login shell. Even which kubectl turned out to return nothing! But it still knows what kubectl is because it has /usr/local/bin in the path.
No worries, speak to you tomorrow maybe! As above, the which kubectl returns empty string for me.
do you get empty string if you do echo $(which kubectl) as well (should be the same as running which kubectl though)
Really strange that you get empty string but it still works for you :)
Yeah I tried this too, with the same result! Not sure what to make of it.
I'll keep this open and explore where I can 😄