Replies: 4 comments 10 replies
-
|
@m3dwards I had forgotten about needing load balancers, that's a good point w.r.t cost. Regarding Minikube, I don't really care? if I'm dev'ing locally, port forward seems fine to me and running a load balancer seems like a PITA. But for a managed cluster, potentially with many users connecting, port forwarding seems less than ideal. My main issues with port-forwarding:
Regarding cost, this would be good to quantify. If it's a fraction on top of what we are already paying for to run these clusters, seems fine? But it if ends up increasing total cost by like, 10%.. less ideal |
Beta Was this translation helpful? Give feedback.
-
|
Locally wouldn't be resource intensive. From the last time I did it (and things may have changed), on Docker Desktop it just magically worked and you can hit localhost. On Minikube you need to start a long running process called |
Beta Was this translation helpful? Give feedback.
-
|
haha minikube tunnel sounds sus |
Beta Was this translation helpful? Give feedback.
-
|
altho minikube tunnel would be a solid improvement over port forwarding if it allows us to get rid of stuff like this in our codebase: #531 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
I can have a go at knocking up a proof of concept but I would prefer to do this after I know we are set for tabconf as I don't think this is a dealbreaker for that. |
Beta Was this translation helpful? Give feedback.
-
|
yeah, agree. mainly just want to keep track of this and keep it top of mind because im starting to see lots of tech debt related to port forwarding and id like to keep track of it so we can hopefully simplify all of this by just moving to ingress. worth mentioning, nothing stops users from port-forwarding on their machine when doing local dev! Id just strongly prefer if we weren't writing code to automatically start / stop port forwarding or having it bleed into our cli commands. |
Beta Was this translation helpful? Give feedback.
-
|
Hate to be on the warpath about this, but I seriously doubt port forwarding is going work for Tabconf. We are trying to build a "production" use case around a debugging feature, which is going to bite us in the ass. From reading the docs a bit, port-forwarding is meant for a single user of kubectl to quickly gain access to ports; I haven't seen anything that indicatese port-forwarding will work with if the idea is we will be the only ones running a dashboard, that might work but I think it will still be flakey and need us to be restarting the port forward. From what ive read, port forwarding is also slow and not meant for lots of data, which is terrible for a dashboard. Theres also nothing from stopping users from accidentally port-forwarding (e.g., via If someone can prove me wrong on this, fantastic, I'll shut up about it! In the absence of that I think we need to do ingress. I can pick it up week after next, but in the meantime I'd suggest we stop building features around port forwarding. There is also nothing that stops us individual devs from port forwarding by just running the kubectl commands ourselves, so really no need for it to be in the python code. |
Beta Was this translation helpful? Give feedback.
-
|
I think you are totally right about ingress being the correct thing here, but I also don't think everyone in the room at tabconf needs to watch grafana locally. There is supposedly one big screen for us to use as a scoreboard. |
Beta Was this translation helpful? Give feedback.
-
I somewhat agree, but I don't see that as an argument to not do ingress? That just means we have ingress and the only person using it is the single browser we have open with the Caddy dashboard. You also didn't address any of the points I made regarding port-forwarding not being able to keep up with a sufficiently large dashboard, or supporting realtime updates. It also doesn't prevent anyone from nuking the dashboard by port-forwarding from their laptop. I almost guarantee someone will look at the commands in warnet , see It's fine if you don't see these as actual concerns, and perhaps I'm being paranoid! But I think that still leaves the concern that even though almost everyone has said "Yeah, I agree ingress is the right way to go," we are still spending time writing and reviewing code that shoe-horns automatic port-forwarding into logging and caddy. So if we all agree ingress is the right way, let's just do ingress and stop adding tech debt to the codebase. If instead people are happy with port-forwading, and that's why we keep writing code for it, then I'd really appreciate someone validating that the concerns I've raised are not actual concerns. If we still feel like ingress is the right way but we don't have time before Tabconf to do it, as a compromise I'd say lets rip out all the port-forwarding code and do it all manually. Since we will be the only ones running a dashboard, the users wont need to do anything manual , so we are all good. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with all your points, we should do it |
Beta Was this translation helpful? Give feedback.
-
|
yeah port forwarding sucks. it dropped on my laptop and i dont know how to get it back using warnet without |
Beta Was this translation helpful? Give feedback.
-
|
Merged in #607 |
Beta Was this translation helpful? Give feedback.
-
Starting a thread from #526 (comment):
Beta Was this translation helpful? Give feedback.
All reactions