On Wed, May 10, 2017 at 8:13 PM, Jimmi Dyson <[email protected]> wrote:
> 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. > Agree. We definitely should find out a way to contribute to Minikube. But the current code base is grown different from each other e.g. the service sub-command as it does not depend on the Kubernetes code now. We need to address this issue from a long term point of view. Basically find a model where both us get benefited from each other. We had some discussion around it but nothing concrete at this point. One of the idea is to use minikube as a go library in Minishift . > 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
