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