On Wed, May 10, 2017 at 3:24 PM, James Strachan <[email protected]> wrote:
> 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?) > No that's my point: the fact that we learned from minishift that users would want to see routes in `minishift service` should IMO have translated into contributing similar functionality upstream first to add ingress to the current nodeport output. Minishift would then add routes to output, but still the command `minishift service` would have been almost consistent in behaviour to `minikube service`, with that one difference around routes. > > 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
