Hello,
I'm raising an issue with userland-proxy because
we figured it out that nodejs-mongo devfile sample[1]
stopped to work on minishift/minikube.
Previously, chectl required disabled userland-proxy on minikube/minishift
platforms but such requirement was removed since Theia plugins
do not need it (because they're reworked to use localhost).
And the question here - can not we continue to require `userland-proxy=false`?
Please share your thoughts/experience/knowledge of why we should not require it.
When it's needed?
The mongo+nodejs devfile issue can be easily solved on our side by reworking it to use localhost BUT:
We promise users that they are able to use their production code/deployment
for workspace. And for application with DB, it's typical that app and DB are run
in separate pods and communicate via service. Users rely on predictable DB url
and hard-code or at least set use it as a default value. As an example of such an application[2].
We have some technical issues with running separate pods, so we merge everything
that user has to one pod, and in such case, communication via services on
minikube/minishift is not possible. More can be found [3][4].
What it alternative if we do not require `userland-proxy=false`?
If we do not require `userland-proxy=false` then we should at least well-document
such an issue, notify users about possible issues and provide them info that they probably
need to reconfigure their application to use `localhost` instead of relying on DNS
provided by k8s services.
Maybe it's acceptable but I think it does not make things more straightforward.
I believe that we should avoid it if there are no strong reasons not to required userland-proxy=false.
Thanks in advance for sharing opinions!
--
Serhii Leshchenko
SENIOR SOFTWARE ENGINEER
Red Hat
