[Devtools] minishift promotion

Wed May 10 15:20:32 UTC 2017

On Wed, May 10, 2017 at 8:13 PM, Jimmi Dyson <jdyson at redhat.com> wrote:

> On Wed, May 10, 2017 at 3:24 PM, James Strachan <jstracha at redhat.com>
> 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 <jdyson at redhat.com> wrote:
>>
>>> On Wed, May 10, 2017 at 2:57 PM, James Strachan <jstracha at redhat.com>
>>> 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 <lmohanty at redhat.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 10, 2017 at 5:11 PM, James Strachan <jstracha at redhat.com>
>>>>> 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 <jstracha at redhat.com
>>>>>> > 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 <prkumar at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 10, 2017 at 4:59 PM, James Strachan <
>>>>>>>> jstracha at redhat.com> 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 <bsutter at redhat.com>
>>>>>>>>> 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 <prkumar at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad <gbraad at redhat.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty <
>>>>>>>>>>>> lmohanty at redhat.com> 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 at 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
>>>>>>>>>>>> Devtools at redhat.com
>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/devtools
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Praveen Kumar
>>>>>>>>>>> https://fedoraproject.org/wiki/User:Kumarpraveen
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Devtools mailing list
>>>>>>>>>>> Devtools at redhat.com
>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/devtools
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Devtools mailing list
>>>>>>>>>> Devtools at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/devtools
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> James
>>>>>>>>> -------
>>>>>>>>> Red Hat
>>>>>>>>>
>>>>>>>>> Twitter: @jstrachan
>>>>>>>>> Email: james.strachan at gmail.com
>>>>>>>>> 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: james.strachan at gmail.com
>>>>>>> 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: james.strachan at gmail.com
>>>>>> 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
>>>>>> Devtools at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/devtools
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> James
>>>> -------
>>>> Red Hat
>>>>
>>>> Twitter: @jstrachan
>>>> Email: james.strachan at gmail.com
>>>> 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
>>>> Devtools at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/devtools
>>>>
>>>>
>>>
>>
>>
>> --
>> James
>> -------
>> Red Hat
>>
>> Twitter: @jstrachan
>> Email: james.strachan at gmail.com
>> Blog: https://medium.com/@jstrachan/
>>
>> fabric8: https://fabric8.io/
>> open source development platform
>>
>> funktion: https://funktion.fabric8.io/
>> open source event based lambda programming
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/devtools/attachments/20170510/55419464/attachment.htm>