Agreed. BTW 'minikube service foo` seems to work fine upstream on minikube for services with nodeports - haven't tested on ingress yet (and route isn't possible I suspect on minikube?)
On Wed, May 10, 2017 at 3:19 PM, Jimmi Dyson <[email protected]> wrote: > On Wed, May 10, 2017 at 2:57 PM, James Strachan <[email protected]> > wrote: > >> changing "minikube service" to "minishift openshift service" doesn't seem >> to make any sense from a UX perspective to me at least. minishift commands >> always work with openshift as it is ;) >> >> looking up a service isn't openshift specific - its working with >> kubernetes resources (which may or may not have associated openshift >> resources). >> > > Totally agree. This should have remained `minishift service`, looking up > service URLs via route, ingress and node port. I would have expected that > to be contributed upstream whch would only look at ingress and node port. > > One of the defining goals of minishift was to make the transition from > minikube to minishift easy. Keeping commands consistent is key to that. I'm > not contributing to minishift any more, busy with other things..., but I > would hope that the minishift team is contributing to minikube too - guide > minikube in line with what for minishift would be a win for everyone IMO. > > >> >> On Wed, May 10, 2017 at 2:44 PM, Lalatendu Mohanty <[email protected]> >> 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. >>> >>> Even if we want to keep things similar to Minikube as we want to cater >>> folks coming from Minikube to Minishift but we need to do things which >>> make sense logically, otherwise Minishift will result in to a project >>> without a definite character. >>> >>> Thanks, >>> Lala >>> >>> >>> >>> >>>> On Wed, May 10, 2017 at 12:40 PM, James Strachan <[email protected]> >>>> wrote: >>>> >>>>> I thought it did - but didn't see it in "minishift help" - wonder why >>>>> we hid the "service" commend behind "openshift"? Its more typing for a >>>>> start? >>>>> >>>>> >>>>> On Wed, May 10, 2017 at 12:38 PM, Praveen Kumar <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, May 10, 2017 at 4:59 PM, James Strachan <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> FWIW gofabric8 has a 'gofabric8 service foo' which shows the URL to >>>>>>> access a service via its route / nodeport / ingress etc. Its pretty >>>>>>> simple >>>>>>> code; we use something similar in funktion (funktion url foo) >>>>>>> >>>>>>> Maybe we need to add the service command to minishift too? >>>>>>> >>>>>> >>>>>> minishift already have service command in place check `minishift >>>>>> openshift service -h` which will show the route url for a deployed app >>>>>> for >>>>>> a specific namespace. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 10, 2017 at 12:08 PM, Burr Sutter <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> What is the trick to always get a nodeport for every Service I >>>>>>>> create? >>>>>>>> Right now, I do need the oc binary INSIDE the VM because I like to >>>>>>>> show that Services are normally in-VM only and Routes make them >>>>>>>> visible to >>>>>>>> the outside world (my laptops OS) >>>>>>>> >>>>>>>> But I can likely make the same point with nodeport >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 10, 2017 at 4:52 AM Praveen Kumar <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> > Sure will do. With CDK 3 we do not have Kubernetes bits in the >>>>>>>>>> ISO/VM e.g. >>>>>>>>>> > kubectl binary. So we need to figure out if it is just the >>>>>>>>>> extra kubectl we >>>>>>>>>> > need or something else. >>>>>>>>>> >>>>>>>>>> `kubectl` should be treated like `oc`, and should therefore not be >>>>>>>>>> part of the ISO/VM for Minishift/CDK 3? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Adding `kubectl` binary to iso shouldn't be intention but it >>>>>>>>> should be treated like 'oc'. We are already advertising openshift as >>>>>>>>> enterprise ready kubernetes so kube related stuff should work as >>>>>>>>> expected >>>>>>>>> IMO. >>>>>>>>> >>>>>>>>> >>>>>>>>>> However, reading the instructions, this behaviour is also >>>>>>>>>> different for `oc` >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> rhel-ose$ vagrant ssh >>>>>>>>>> #Inside CDK shell - Create a Kubernetes context - We will use the >>>>>>>>>> OpenShift Client (oc) as as shortcut >>>>>>>>>> [vagrant@rhel-cdk ~]$ oc login -u openshift-dev -p devel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> which means that `oc` is on the path inside the VM. is this still >>>>>>>>>> the >>>>>>>>>> case for CDK 3.x? >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, we did this for CDK-2.x because it was required to provision >>>>>>>>> openshift inside the VM but right now we are using client binary >>>>>>>>> outside VM >>>>>>>>> to provision it. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> WDYT? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Gerard >>>>>>>>>> >>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Devtools mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://www.redhat.com/mailman/listinfo/devtools >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Praveen Kumar >>>>>>>>> https://fedoraproject.org/wiki/User:Kumarpraveen >>>>>>>>> _______________________________________________ >>>>>>>>> Devtools mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.redhat.com/mailman/listinfo/devtools >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Devtools mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/devtools >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Praveen Kumar >>>>>> https://fedoraproject.org/wiki/User:Kumarpraveen >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>> >> >> >> -- >> 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 >> >> > -- 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
