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 > >
_______________________________________________ Devtools mailing list [email protected] https://www.redhat.com/mailman/listinfo/devtools
