On Thu, May 11, 2017 at 2:08 PM, Hardy Ferentschik <[email protected]> wrote:
> Hi, > > On Wed, 10-May-2017 19:14, Lalatendu Mohanty wrote: > > On Wed, May 10, 2017 at 5:11 PM, James Strachan <[email protected]> > wrote: > > > > > or let me say that differently - lets try be as similar to minikube as > we > > > can? > > > > > > > > Sure, thats the general idea/guideline. But then we have some > sub-commands > > which is under openshift command and we moved the service command under > > OpenShift (after fixing it for OpenShift) and put it with other > > sub-commands which should be logically grouped together. > > +1, I second this. We try to align as much as possible with Minikube, but > in some cases it also makes sense to take a different approach. > > We introduced the openshift sub-command to group together some > functionality > which deal with OpenShift specifics. Given that we changed the > implementation > of the service command and the fact that in OpenShift you are dealing with > routes, it felt natural to move the 'service' command. > As a user it doesn't feel natural at all as kubernetes services are a core part of kubernetes; they are not openshift specifics. Also OpenShift resources are being refactored to use API groups; so minikube could even detect the Route resource along with Ingress/NodePort and use it in the "minikube service" command. So it seems to make lesse sense hiding "service" in an openshift specific menu. Where possible OpenShift should look and feel like Kubernetes. -- James ------- Red Hat Twitter: @jstrachan Email: [email protected] Blog: https://medium.com/@jstrachan/ fabric8: https://fabric8.io/ open source development platform funktion: https://funktion.fabric8.io/ open source event based lambda programming
_______________________________________________ Devtools mailing list [email protected] https://www.redhat.com/mailman/listinfo/devtools
