You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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/hosts
like Kubefwd does./etc/hosts
the exact way you found it. Currently spaces/tabs are modified and I consider that a bug.sudo
is needed in the docs and what the-E
flag 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.
The text was updated successfully, but these errors were encountered: