Hello and thank you for the tool. I wanted to drop in my feedback after trying this tool out for the first time after reading your blog post introducing the tool from 4 days ago.
- Call out clearly in the docs the similarities and differences with Kubefwd.
- Create a back-up of the original
/etc/hosts like Kubefwd does.
- Always leave
/etc/hosts the exact way you found it. Currently spaces/tabs are modified and I consider that a bug.
- Explain why
sudo is needed in the docs and what the -E flag does to forward the environment.
- Update the CLI so it's clear when the tool is ready to use. Right now it's not clear.
- Provide better documentation explaining the hosts file modifications and give an example to help people grok the tool.
I was hoping this tool would solve the problem of helping my local macOS dev environment match production by way of serving as a kind of proxy (a la Ergo) in addition to doing what Kubefwd does. Unfortunately that's not the case and I find my apps unable to function because "production" doesn't use service ports where the end-user is concerned.
I'm in agreement K8s is lacking some basic development tooling. I've spent the last few days trying to figure out how I can run a functional local dev environment to run a realistic use case without having to set up a separate proxy or doing funny stuff with TunTap or dnsmasq: https://github.com/slingshotlabs/reaction-oss-helm-chart.
If you can make a tool that makes setting up Reaction for local development a snap I feel that would greatly help with product differentiation in the space. Otherwise I found myself a bit confused at how (besided gRPC perhaps?) this tool differentiates itself from Kubefwd and why I might want to use it over Kubefwd.
Again, using a real-world use case and giving users a walkthru will go 100 miles in explaining why they need tools like this and help support the vision I believe you're trying to achieve. And thanks again for this tool.
Hello and thank you for the tool. I wanted to drop in my feedback after trying this tool out for the first time after reading your blog post introducing the tool from 4 days ago.
/etc/hostslike Kubefwd does./etc/hoststhe exact way you found it. Currently spaces/tabs are modified and I consider that a bug.sudois needed in the docs and what the-Eflag does to forward the environment.I was hoping this tool would solve the problem of helping my local macOS dev environment match production by way of serving as a kind of proxy (a la Ergo) in addition to doing what Kubefwd does. Unfortunately that's not the case and I find my apps unable to function because "production" doesn't use service ports where the end-user is concerned.
I'm in agreement K8s is lacking some basic development tooling. I've spent the last few days trying to figure out how I can run a functional local dev environment to run a realistic use case without having to set up a separate proxy or doing funny stuff with TunTap or dnsmasq: https://github.com/slingshotlabs/reaction-oss-helm-chart.
If you can make a tool that makes setting up Reaction for local development a snap I feel that would greatly help with product differentiation in the space. Otherwise I found myself a bit confused at how (besided gRPC perhaps?) this tool differentiates itself from Kubefwd and why I might want to use it over Kubefwd.
Again, using a real-world use case and giving users a walkthru will go 100 miles in explaining why they need tools like this and help support the vision I believe you're trying to achieve. And thanks again for this tool.