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
Minishift and Kubernetes default to different namespaces, myproject and default respectively and that makes the service discovery chapter non-consistent across environments.
will work on Kubernetes cluster, but not in OpenShift as default is restricted and in most installation including minishift the user will no be allowed to use the namespace.
In case the tutorials want to as well target on-lin service users, it should not rely on hard-coded name, as the namespace names has to be unique across users, it would only work for one user.
There are some possible ways how to solve this.
The content could be tweaked so that the user is well aware of the namespaces. But that would require creation of separate paths for Kubernetes and OpenShift, as they have different ways to create them.
Other way is to teach the user some way how to learn the namepace, (is there actually some simple command on kubectl level what would return the current namespace ?) e.g.
kubectl get pod jumpod -o jsonpath="{.metadata.namespace}"
and then let the user substitute the name in the command
Minishift and Kubernetes default to different namespaces,
myproject
anddefault
respectively and that makes the service discovery chapter non-consistent across environments.The command
will work on Kubernetes cluster, but not in OpenShift as
default
is restricted and in most installation including minishift the user will no be allowed to use the namespace.In case the tutorials want to as well target on-lin service users, it should not rely on hard-coded name, as the namespace names has to be unique across users, it would only work for one user.
There are some possible ways how to solve this.
The content could be tweaked so that the user is well aware of the namespaces. But that would require creation of separate paths for Kubernetes and OpenShift, as they have different ways to create them.
Other way is to teach the user some way how to learn the namepace, (is there actually some simple command on kubectl level what would return the current namespace ?) e.g.
and then let the user substitute the name in the command
Another one is provide some command that would figure out the FQDN on the server at runtime, like this dirty hack
The text was updated successfully, but these errors were encountered: