Running kubefirst changes my stty settings

[mwoodpatrick]

Which version of kubefirst are you using?

kubefirst-cli golang utility version: v2.4.6

Which cloud provider?

k3d (local)

Which DNS?

None specific

Which installation type?

CLI

Which distributed Git provider?

GitHub

Did you use a fork of gitops-template?

No

Which Operating System?

None specific

What is the issue?

Running the following kubefirst command:

kubefirst k3d create --cluster-name kubefirst_test1 --github-user mwoodpatrick --git-provider github

changes my stty settings so nothing is displayed to my terminal until I run:

tset

Changes seen in stty settings (stty -a)

 diff stty.kubefirst stty.orig
6c6
< -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
---
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
9c9
< -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
---
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt

Not all kubefirst commands do this e.g.:

kubefirst version

Code of Conduct

• I agree to follow this project's Code of Conduct

[fharper]

@mwoodpatrick: thanks for reporting this issue. I can replicate this, but I have no idea why we would modify stty settings, so let me check with the engineering team.

[mwoodpatrick]

Any updates on this issue?

[fharper]

@fharper no sorry, the team is quite swamped at the moment, and didn't have time to investigate to find what is changing stty.

[CristhianF7]

I was not able to reproduce the issue, I don't see any stty difference even the k3d commands returns the same error exit status 1

Here's the stty diff before and after running k3d create

1c1
< gfmt1:cflag=4800:iflag=6800:lflag=2000014f:oflag=7:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600
---
> gfmt1:cflag=4800:iflag=6800:lflag=47:oflag=7:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600

[mwoodpatrick]

Cristhian what OS did you test on? Was this using a distro running on WSL-2?

[fharper]

@mwoodpatrick can you try this PR? #2184

I'm struggling to test on my machine for another reason right now.

[mwoodpatrick]

Where are we on this issue?

Seems like we hit this issue if kubefirst is failing using stty I see the following differences

$ diff stty-a.good stty-a.bad
6c6
< -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
---
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
9c9
< -isig -icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
---
> -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt

Once in the bad state running:

stty echo echoe echok icrnl

Fixes the issue

[CristhianF7]

Hey @mwoodpatrick,

Are you still having the issue with the above PR that @fharper mentioned?

@mwoodpatrick can you try this PR? #2184

I'm struggling to test on my machine for another reason right now.

[fharper]

@fharper: let me try it again tomorrow.

@mwoodpatrick: did you fix your other issue? If so, can you try this PR also please?

[mwoodpatrick]

It didn't work for me I believe the change did not create the git repo's with the desired names.

As mentioned in #2195 I'm doing some prototyping in a fork of kubefirst to support multiple simultaneous configs of kubefirst with each config having its cluster, git repos, k3d/k3s config settings. I'll let you know how it goes.

[fharper]

I was able to test it on macOS, using the script you created @CristhianF7 and the PR didn't fix it for me. Here is the differences:

< gfmt1:cflag=4b00:iflag=6b02:lflag=200005cf:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400
---
> gfmt1:cflag=4800:iflag=6800:lflag=47:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400

[fharper]

Another use has this issue with ZSH on Fedora Linux.

[fharper]

I thought it was shell-specific since I'm also on ZSH, but @CristhianF7 who can't replicate the issue is also using the same shell.

[fharper]

I just tried on Ubuntu myself, and I also got the issue, but on a smaller scale (I also wasn't able to move passed the preflight checks because of something else on my side, so it may explain the smallest change:

< 4100:5:bf:a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
---
> 4000:5:bf:a30:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

On my test Ubuntu machine I'm on Bash.

[mwoodpatrick]

The error seems to manifest only when kubefirst does an error exit, if the command completes without error it seems that the stty settings are ok. I suspect the stty settings are being controlled by the bubble tea GUI. BTW running bubble tea seems to have a big impact on vscode performance (at least on WSL) I had to add a disable for bubble tea so I could make reasonable progress in my debug.

[fharper]

@mwoodpatrick: can you test this other PR instead please #2220 ? It fixed it for me. Let us know if you can reproduce or not anymore. /cc @jokestax

[fharper]

Three of us tried it and we weren't able to replicate the issue anymore with @jokestax's fix. Let us know how it goes @mwoodpatrick, and you still have a problem, please let us know, but we consider it fixed. @CristhianF7 will release a new kubefirst version today with this fix as it's super annoying. Thanks again for reporting it :)