From hwindzio at redhat.com Mon May 8 17:36:03 2017 From: hwindzio at redhat.com (Heinz Windzio) Date: Mon, 8 May 2017 13:36:03 -0400 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: Burr, does it make sense to put this content on the RHDP site, as a Getting Started resource? We now have minishift (cdk 3) beta on the site for download. Heinz On Thu, Apr 27, 2017 at 10:29 PM, Burr Sutter wrote: > Besides bit.ly/msa-instructions (our primary demo/tutorial) we also have > bit.ly/kubernetes-lab > > and Rafael may be aware of some other "tutorials" that people might follow > and learn more about key technologies and leverage minishift. > > Can someone on the engineering/QA side scan bit.ly/kubernetes-lab and see > if it makes sense? > > also, we need to be pushing the Java S2I, this is how we documented it > when it launched in Feb 2017 > oc create -f https://gist.githubusercontent.com/tqvarnst/ > 3ca512b01b7b7c1a1da0532939350e23/raw/3869a54c7dd960965f0e66907cdc3e > ba6d160cad/openjdk-s2i-imagestream.json > > but I am not sure if that is the 'proper' way to get average end-users to > load it up. Any ideas about how we should promote the usage of the s2i and > getting people to try it on minishift? > > And is there is another email list for this sort of thing...let me > know...my brain is weary of trying to track all these different email lists. > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Mon May 8 17:42:49 2017 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 08 May 2017 17:42:49 +0000 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: Once it is QA'd :-) We could spend a LOT more on docs and tutorials for CDK/Minishift. On Mon, May 8, 2017 at 1:36 PM Heinz Windzio wrote: > Burr, does it make sense to put this content on the RHDP site, as a > Getting Started resource? > > We now have minishift (cdk 3) beta on the site for download. > > > Heinz > On Thu, Apr 27, 2017 at 10:29 PM, Burr Sutter wrote: > >> Besides bit.ly/msa-instructions (our primary demo/tutorial) we also have >> bit.ly/kubernetes-lab >> >> and Rafael may be aware of some other "tutorials" that people might >> follow and learn more about key technologies and leverage minishift. >> >> Can someone on the engineering/QA side scan bit.ly/kubernetes-lab and >> see if it makes sense? >> >> also, we need to be pushing the Java S2I, this is how we documented it >> when it launched in Feb 2017 >> oc create -f >> https://gist.githubusercontent.com/tqvarnst/3ca512b01b7b7c1a1da0532939350e23/raw/3869a54c7dd960965f0e66907cdc3eba6d160cad/openjdk-s2i-imagestream.json >> >> but I am not sure if that is the 'proper' way to get average end-users to >> load it up. Any ideas about how we should promote the usage of the s2i and >> getting people to try it on minishift? >> >> And is there is another email list for this sort of thing...let me >> know...my brain is weary of trying to track all these different email lists. >> >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Tue May 9 06:47:55 2017 From: bgurung at redhat.com (Budh Gurung) Date: Tue, 9 May 2017 12:17:55 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Mon, May 8, 2017 at 11:12 PM, Burr Sutter wrote: > Once it is QA'd :-) > > We could spend a LOT more on docs and tutorials for CDK/Minishift. > Nice! > > On Mon, May 8, 2017 at 1:36 PM Heinz Windzio wrote: > >> Burr, does it make sense to put this content on the RHDP site, as a >> Getting Started resource? >> >> We now have minishift (cdk 3) beta on the site for download. >> >> >> Heinz >> On Thu, Apr 27, 2017 at 10:29 PM, Burr Sutter wrote: >> >>> Besides bit.ly/msa-instructions (our primary demo/tutorial) we also >>> have >>> bit.ly/kubernetes-lab >>> >>> and Rafael may be aware of some other "tutorials" that people might >>> follow and learn more about key technologies and leverage minishift. >>> >>> Can someone on the engineering/QA side scan bit.ly/kubernetes-lab and >>> see if it makes sense? >>> >>> also, we need to be pushing the Java S2I, this is how we documented it >>> when it launched in Feb 2017 >>> oc create -f https://gist.githubusercontent.com/tqvarnst/ >>> 3ca512b01b7b7c1a1da0532939350e23/raw/3869a54c7dd960965f0e66907cdc3e >>> ba6d160cad/openjdk-s2i-imagestream.json >>> >>> but I am not sure if that is the 'proper' way to get average end-users >>> to load it up. Any ideas about how we should promote the usage of the s2i >>> and getting people to try it on minishift? >>> >>> And is there is another email list for this sort of thing...let me >>> know...my brain is weary of trying to track all these different email lists. >>> >>> >>> _______________________________________________ >>> 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 > > Regards, Budh Ram Gurung Software Engineer - Devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Tue May 9 12:42:23 2017 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 9 May 2017 08:42:23 -0400 Subject: [Devtools] opensource india event Message-ID: what do we know about this event? http://opensourceindia.in/osidays/videos-osi-2016/ is it as awesome as GIDS? If less awesome, how so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Tue May 9 12:52:22 2017 From: bgurung at redhat.com (Budh Gurung) Date: Tue, 9 May 2017 18:22:22 +0530 Subject: [Devtools] opensource india event In-Reply-To: References: Message-ID: Hi Burr, Most of the details can be found in the prospectus [1] which says they had Total registrations in 2 days: 7500+ which included Software Developers Key Senior Decision Makers ?C? Level IT Implementers Business Heads of various Open Source Companies Academia Researchers IMO worth to look at :) [1] http://osidays.com/osidays/wp-content/uploads/2016/02/OSI_brochure-2016_wo-rate_distri.pdf Regards, Budh Ram Gurung Software Engineer - Devtools On Tue, May 9, 2017 at 6:12 PM, Burr Sutter wrote: > what do we know about this event? > > http://opensourceindia.in/osidays/videos-osi-2016/ > > is it as awesome as GIDS? > > If less awesome, how so? > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Tue May 9 12:54:43 2017 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 9 May 2017 08:54:43 -0400 Subject: [Devtools] opensource india event In-Reply-To: References: Message-ID: Very good research...now, how do you FEEL about it? :-) Or has anyone ever gone to the event? On Tue, May 9, 2017 at 8:52 AM, Budh Gurung wrote: > Hi Burr, > > Most of the details can be found in the prospectus [1] > which says they had > Total registrations in 2 days: 7500+ which included > > Software Developers > Key Senior Decision Makers ?C? Level > IT Implementers > Business Heads of various Open Source Companies > Academia Researchers > > IMO worth to look at :) > > > [1] http://osidays.com/osidays/wp-content/uploads/ > 2016/02/OSI_brochure-2016_wo-rate_distri.pdf > > Regards, > Budh Ram Gurung > Software Engineer - Devtools > > On Tue, May 9, 2017 at 6:12 PM, Burr Sutter wrote: > >> what do we know about this event? >> >> http://opensourceindia.in/osidays/videos-osi-2016/ >> >> is it as awesome as GIDS? >> >> If less awesome, how so? >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Tue May 9 13:02:59 2017 From: bgurung at redhat.com (Budh Gurung) Date: Tue, 9 May 2017 18:32:59 +0530 Subject: [Devtools] opensource india event In-Reply-To: References: Message-ID: On Tue, May 9, 2017 at 6:24 PM, Burr Sutter wrote: > Very good research...now, how do you FEEL about it? :-) > I definitely miss the Red Hat logo in the sponsors list ;) when the event name start with Open Source. > > Or has anyone ever gone to the event? > No, I didn't get chance yet. Might be someone who has gone to the even can give more insights to it. It seems the online registration [1] is closed and have option to register at venue. [1] http://opensourceindia.in/osidays/osi_registration/osidays_register-new.php > > > On Tue, May 9, 2017 at 8:52 AM, Budh Gurung wrote: > >> Hi Burr, >> >> Most of the details can be found in the prospectus [1] >> which says they had >> Total registrations in 2 days: 7500+ which included >> >> Software Developers >> Key Senior Decision Makers ?C? Level >> IT Implementers >> Business Heads of various Open Source Companies >> Academia Researchers >> >> IMO worth to look at :) >> >> >> [1] http://osidays.com/osidays/wp-content/uploads/2016/02/ >> OSI_brochure-2016_wo-rate_distri.pdf >> >> Regards, >> Budh Ram Gurung >> Software Engineer - Devtools >> >> On Tue, May 9, 2017 at 6:12 PM, Burr Sutter wrote: >> >>> what do we know about this event? >>> >>> http://opensourceindia.in/osidays/videos-osi-2016/ >>> >>> is it as awesome as GIDS? >>> >>> If less awesome, how so? >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >>> >>> >> > Regards, Budh Ram Gurung Software Engineer - Devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From moahmed at redhat.com Tue May 9 18:41:07 2017 From: moahmed at redhat.com (Mohammed Ahmed) Date: Wed, 10 May 2017 00:11:07 +0530 Subject: [Devtools] opensource india event In-Reply-To: References: Message-ID: On 09-May-2017 6:33 PM, "Budh Gurung" wrote: On Tue, May 9, 2017 at 6:24 PM, Burr Sutter wrote: > Very good research...now, how do you FEEL about it? :-) > I definitely miss the Red Hat logo in the sponsors list ;) when the event name start with Open Source. > > Or has anyone ever gone to the event? > No, I didn't get chance yet. Might be someone who has gone to the even can give more insights to it. Yea I have been to one they do get suse and all as sponsors already sponsors and a decently large crowd. I can definitely second Budhrams research. It seems the online registration [1] is closed and have option to register at venue. [1] http://opensourceindia.in/osidays/osi_registration/ osidays_register-new.php > > > On Tue, May 9, 2017 at 8:52 AM, Budh Gurung wrote: > >> Hi Burr, >> >> Most of the details can be found in the prospectus [1] >> which says they had >> Total registrations in 2 days: 7500+ which included >> >> Software Developers >> Key Senior Decision Makers ?C? Level >> IT Implementers >> Business Heads of various Open Source Companies >> Academia Researchers >> >> IMO worth to look at :) >> >> >> [1] http://osidays.com/osidays/wp-content/uploads/2016/02/OS >> I_brochure-2016_wo-rate_distri.pdf >> >> Regards, >> Budh Ram Gurung >> Software Engineer - Devtools >> >> On Tue, May 9, 2017 at 6:12 PM, Burr Sutter wrote: >> >>> what do we know about this event? >>> >>> http://opensourceindia.in/osidays/videos-osi-2016/ >>> >>> is it as awesome as GIDS? >>> >>> If less awesome, how so? >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >>> >>> >> > Regards, Budh Ram Gurung Software Engineer - Devtools _______________________________________________ Devtools mailing list Devtools at redhat.com https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Tue May 9 18:58:43 2017 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 10 May 2017 00:28:43 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Fri, Apr 28, 2017 at 7:59 AM, Burr Sutter wrote: > Besides bit.ly/msa-instructions (our primary demo/tutorial) we also have > bit.ly/kubernetes-lab > > and Rafael may be aware of some other "tutorials" that people might follow > and learn more about key technologies and leverage minishift. > > Can someone on the engineering/QA side scan bit.ly/kubernetes-lab and see > if it makes sense? > > 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. > > also, we need to be pushing the Java S2I, this is how we documented it > when it launched in Feb 2017 > oc create -f https://gist.githubusercontent.com/tqvarnst/ > 3ca512b01b7b7c1a1da0532939350e23/raw/3869a54c7dd960965f0e66907cdc3e > ba6d160cad/openjdk-s2i-imagestream.json > Is this about the OpenJDK imagestream getting included in CDK/Minishift or something else? If it is just the image stream then we might be able to just do it. > but I am not sure if that is the 'proper' way to get average end-users to > load it up. Any ideas about how we should promote the usage of the s2i and > getting people to try it on minishift? > > I think when ever we build from source in OpenShift, S2I is getting used. Which is pretty cool as developers do not have to write the Dockerfile for that. Is there anything else we want to promote with S2I? We have upstream issue related to this. https://github.com/minishift/minishift/issues/780 > And is there is another email list for this sort of thing...let me > know...my brain is weary of trying to track all these different email lists. > > I think we are good wrt maling list . We could not just include the OpenJDK in CDK 3.0 as we need more time to understand the requirement. Hopefully next version of CDK will have it. Thanks, Lala > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Tue May 9 20:04:30 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 09 May 2017 22:04:30 +0200 Subject: [Devtools] why is Mac OSX called Darwin? In-Reply-To: (Burr Sutter's message of "Sat, 15 Apr 2017 21:38:13 -0400") References: <2211170267995818316@unknownmsgid> Message-ID: <87mvalkd9t.fsf@mid.deneb.enyo.de> * Burr Sutter: > Interesting...feels a little "inside baseball" but I guess our types of > users are the uber geeks who are into this kind of stuff. > > Mac OSX > Windows 64-bit > > would be more obvious to the average folks :-) There are more 64-bit versions of Windows, some of them are even still under extended support. The x86-64 variant is just the last incarnation, so just calling it ?64-bit? is misleading because there are (incompatible) other versions. From gbraad at redhat.com Wed May 10 03:45:17 2017 From: gbraad at redhat.com (Gerard Braad) Date: Wed, 10 May 2017 11:45:17 +0800 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: Hi, On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty 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? 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? WDYT? Gerard From prkumar at redhat.com Wed May 10 03:52:17 2017 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 10 May 2017 09:22:17 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: > Hi, > > On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Wed May 10 04:04:54 2017 From: gbraad at redhat.com (Gerard Braad) Date: Wed, 10 May 2017 12:04:54 +0800 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: Hi, On Wed, May 10, 2017 at 11:52 AM, Praveen Kumar wrote: > On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >> `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. >> 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. So this answer what I needed. The ISO is OK for use, but should we implement a way to have CDK download the kubectl binary? Gerard From ccoleman at redhat.com Wed May 10 04:06:32 2017 From: ccoleman at redhat.com (Clayton Coleman) Date: Tue, 9 May 2017 21:06:32 -0700 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: <-2827614466146235625@unknownmsgid> Symlink oc to kubectl and it acts like kubectl - no need for a second download > On May 9, 2017, at 9:05 PM, Gerard Braad wrote: > > Hi, > > >> On Wed, May 10, 2017 at 11:52 AM, Praveen Kumar wrote: >>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >>> `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. >>> 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. > > So this answer what I needed. The ISO is OK for use, but should we > implement a way to have CDK download the kubectl binary? > > > Gerard > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Wed May 10 11:05:42 2017 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 10 May 2017 11:05:42 +0000 Subject: [Devtools] minishift promotion In-Reply-To: <-2827614466146235625@unknownmsgid> References: <-2827614466146235625@unknownmsgid> Message-ID: Oh I like that idea And it totally helps make the point On Wed, May 10, 2017 at 5:06 AM Clayton Coleman wrote: > Symlink oc to kubectl and it acts like kubectl - no need for a second > download > > > On May 9, 2017, at 9:05 PM, Gerard Braad wrote: > > > > Hi, > > > > > >> On Wed, May 10, 2017 at 11:52 AM, Praveen Kumar > wrote: > >>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad > wrote: > >>> `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. > >>> 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. > > > > So this answer what I needed. The ISO is OK for use, but should we > > implement a way to have CDK download the kubectl binary? > > > > > > Gerard > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Wed May 10 11:08:39 2017 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 10 May 2017 11:08:39 +0000 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: 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 wrote: > On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: > >> Hi, >> >> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Wed May 10 11:11:52 2017 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 10 May 2017 16:41:52 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 4:38 PM, Burr Sutter 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) > I think you need `oc` to list out the port detail of the service `oc get service` which you can also do outside the VM and tell user that you can't use it from your host because it's a internal then ssh to VM and curl that service url with specific service port to make your point for nodeport. > > But I can likely make the same point with nodeport > > > On Wed, May 10, 2017 at 4:52 AM Praveen Kumar wrote: > >> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >> >>> Hi, >>> >>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty >>> 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 >> > -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Wed May 10 11:13:37 2017 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 10 May 2017 11:13:37 +0000 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 12:11 PM Praveen Kumar wrote: > On Wed, May 10, 2017 at 4:38 PM, Burr Sutter 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) >> > > I think you need `oc` to list out the port detail of the service `oc get > service` which you can also do outside the VM and tell user that you can't > use it from your host because it's a internal then ssh to VM and curl that > service url with specific service port to make your point for nodeport. > > I normally like to script that :-) >> But I can likely make the same point with nodeport >> >> >> On Wed, May 10, 2017 at 4:52 AM Praveen Kumar wrote: >> >>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >>> >>>> Hi, >>>> >>>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty >>>> 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 >>> >> > > > -- > Praveen Kumar > https://fedoraproject.org/wiki/User:Kumarpraveen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Wed May 10 11:29:54 2017 From: jstracha at redhat.com (James Strachan) Date: Wed, 10 May 2017 12:29:54 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: 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? On Wed, May 10, 2017 at 12:08 PM, Burr Sutter 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 wrote: > >> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >> >>> Hi, >>> >>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Wed May 10 11:34:27 2017 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 10 May 2017 11:34:27 +0000 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: That sounds interesting, how does minikube deal with this scenario? Perhaps my thinking is warped but by default, Services are inside the cluster, therefore you need to be inside the VM in order to curl them On Wed, May 10, 2017 at 12:29 PM James Strachan 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? > > > On Wed, May 10, 2017 at 12:08 PM, Burr Sutter 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 wrote: >> >>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >>> >>>> Hi, >>>> >>>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty >>>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Wed May 10 11:38:26 2017 From: prkumar at redhat.com (Praveen Kumar) Date: Wed, 10 May 2017 17:08:26 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 4:59 PM, James Strachan 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 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 wrote: >> >>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad wrote: >>> >>>> Hi, >>>> >>>> On Wed, May 10, 2017 at 2:58 AM, Lalatendu Mohanty >>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Wed May 10 11:39:05 2017 From: jstracha at redhat.com (James Strachan) Date: Wed, 10 May 2017 12:39:05 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: minikube has support for the command too "minikube service" though it only understands nodeports AFAIK. On openshift we need to detect & support Routes and/or nodeports depending on if there's a Route or service of type NodePort On Wed, May 10, 2017 at 12:34 PM, Burr Sutter wrote: > That sounds interesting, how does minikube deal with this scenario? > > Perhaps my thinking is warped but by default, Services are inside the > cluster, therefore you need to be inside the VM in order to curl them > > On Wed, May 10, 2017 at 12:29 PM James Strachan > 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? >> >> >> On Wed, May 10, 2017 at 12:08 PM, Burr Sutter 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 >>> wrote: >>> >>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>> 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 >> > -- 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: From jstracha at redhat.com Wed May 10 11:40:07 2017 From: jstracha at redhat.com (James Strachan) Date: Wed, 10 May 2017 12:40:07 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: 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 wrote: > > > On Wed, May 10, 2017 at 4:59 PM, James Strachan > 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 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 >>> wrote: >>> >>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Wed May 10 11:41:17 2017 From: jstracha at redhat.com (James Strachan) Date: Wed, 10 May 2017 12:41:17 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: or let me say that differently - lets try be as similar to minikube as we can? On Wed, May 10, 2017 at 12:40 PM, James Strachan 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 > wrote: > >> >> >> On Wed, May 10, 2017 at 4:59 PM, James Strachan >> 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 >>> 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 >>>> wrote: >>>> >>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From luebken at redhat.com Wed May 10 11:46:23 2017 From: luebken at redhat.com (Matthias Luebken) Date: Wed, 10 May 2017 13:46:23 +0200 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: or let me say that differently - lets try be as similar to minikube as we > can? > +1 I think the story should be similar to kubernetes / openshift. > On Wed, May 10, 2017 at 12:40 PM, James Strachan > 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 >> wrote: >> >>> >>> >>> On Wed, May 10, 2017 at 4:59 PM, James Strachan >>> 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 >>>> 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 >>>>> wrote: >>>>> >>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>> 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 > > -- Matthias Luebken Technical Product Owner for Bayesian Systems Design & Engineering ________________________________________________________________________ Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Wed May 10 13:44:34 2017 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 10 May 2017 19:14:34 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 5:11 PM, James Strachan 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 > 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 >> wrote: >> >>> >>> >>> On Wed, May 10, 2017 at 4:59 PM, James Strachan >>> 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 >>>> 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 >>>>> wrote: >>>>> >>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Wed May 10 13:57:35 2017 From: jstracha at redhat.com (James Strachan) Date: Wed, 10 May 2017 14:57:35 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: 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). On Wed, May 10, 2017 at 2:44 PM, Lalatendu Mohanty wrote: > > > On Wed, May 10, 2017 at 5:11 PM, James Strachan > 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 >> 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 >>> wrote: >>> >>>> >>>> >>>> On Wed, May 10, 2017 at 4:59 PM, James Strachan >>>> 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 >>>>> 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 >>>>>> wrote: >>>>>> >>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdyson at redhat.com Wed May 10 14:19:08 2017 From: jdyson at redhat.com (Jimmi Dyson) Date: Wed, 10 May 2017 15:19:08 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 2:57 PM, James Strachan 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 > wrote: > >> >> >> On Wed, May 10, 2017 at 5:11 PM, James Strachan >> 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 >>> 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 >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, May 10, 2017 at 4:59 PM, James Strachan >>>>> 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 >>>>>> 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 >>>>>>> wrote: >>>>>>> >>>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>>>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Wed May 10 14:24:34 2017 From: jstracha at redhat.com (James Strachan) Date: Wed, 10 May 2017 15:24:34 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: 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?) On Wed, May 10, 2017 at 3:19 PM, Jimmi Dyson wrote: > On Wed, May 10, 2017 at 2:57 PM, James Strachan > 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 >> wrote: >> >>> >>> >>> On Wed, May 10, 2017 at 5:11 PM, James Strachan >>> 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 >>>> 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 >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, May 10, 2017 at 4:59 PM, James Strachan >>>>>> 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 >>>>>>> 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 >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>>>>> 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: From jdyson at redhat.com Wed May 10 14:43:45 2017 From: jdyson at redhat.com (Jimmi Dyson) Date: Wed, 10 May 2017 15:43:45 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 3:24 PM, James Strachan 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 wrote: > >> On Wed, May 10, 2017 at 2:57 PM, James Strachan >> 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 >>> wrote: >>> >>>> >>>> >>>> On Wed, May 10, 2017 at 5:11 PM, James Strachan >>>> 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 >>>>> 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 >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 10, 2017 at 4:59 PM, James Strachan >>>>>> > 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 >>>>>>>> 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 >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>>>>>> 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: From gbraad at redhat.com Wed May 10 15:06:47 2017 From: gbraad at redhat.com (Gerard Braad) Date: Wed, 10 May 2017 23:06:47 +0800 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 10:43 PM, Jimmi Dyson wrote: > On Wed, May 10, 2017 at 3:24 PM, James Strachan > 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. > OK, so let's see if we can fix this targeting the next point release. Jimmy, would you suggest to create an issue at minikube to track/propose this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdyson at redhat.com Wed May 10 15:08:00 2017 From: jdyson at redhat.com (Jimmi Dyson) Date: Wed, 10 May 2017 16:08:00 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 4:06 PM, Gerard Braad wrote: > On Wed, May 10, 2017 at 10:43 PM, Jimmi Dyson wrote: > >> On Wed, May 10, 2017 at 3:24 PM, James Strachan >> 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. >> > > OK, so let's see if we can fix this targeting the next point release. > > Jimmy, would you suggest to create an issue at minikube to track/propose > this? > Yeah that would make sense. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Wed May 10 15:20:32 2017 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 10 May 2017 20:50:32 +0530 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 8:13 PM, Jimmi Dyson wrote: > On Wed, May 10, 2017 at 3:24 PM, James Strachan > 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 wrote: >> >>> On Wed, May 10, 2017 at 2:57 PM, James Strachan >>> 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 >>> > wrote: >>>> >>>>> >>>>> >>>>> On Wed, May 10, 2017 at 5:11 PM, James Strachan >>>>> 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 >>>>> > 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 >>>>>>> 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 >>>>>>>>> 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 >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, May 10, 2017 at 9:15 AM, Gerard Braad >>>>>>>>>> > 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: From hferents at redhat.com Thu May 11 13:08:28 2017 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 11 May 2017 15:08:28 +0200 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: <20170511130828.GA13477@nineveh.local> Hi, On Wed, 10-May-2017 19:14, Lalatendu Mohanty wrote: > On Wed, May 10, 2017 at 5:11 PM, James Strachan 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. +1, I second this. We try to align as much as possible with Minikube, but in some cases it also makes sense to take a different approach. We introduced the openshift sub-command to group together some functionality which deal with OpenShift specifics. Given that we changed the implementation of the service command and the fact that in OpenShift you are dealing with routes, it felt natural to move the 'service' command. > 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. +1 --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From hferents at redhat.com Thu May 11 13:12:08 2017 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 11 May 2017 15:12:08 +0200 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: <20170511131208.GB13477@nineveh.local> Hi, On Wed, 10-May-2017 14:57, James Strachan 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 ;) That is not true. You can actually categorize commands. Most commands at the top level are much more about managing the VM, than anything around Kubernetes or OpenShift. The 'openshift' command creates a namespace for commands which directly effect OpenShift. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From jstracha at redhat.com Thu May 11 13:13:56 2017 From: jstracha at redhat.com (James Strachan) Date: Thu, 11 May 2017 14:13:56 +0100 Subject: [Devtools] minishift promotion In-Reply-To: <20170511130828.GA13477@nineveh.local> References: <20170511130828.GA13477@nineveh.local> Message-ID: On Thu, May 11, 2017 at 2:08 PM, Hardy Ferentschik wrote: > Hi, > > On Wed, 10-May-2017 19:14, Lalatendu Mohanty wrote: > > On Wed, May 10, 2017 at 5:11 PM, James Strachan > 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. > > +1, I second this. We try to align as much as possible with Minikube, but > in some cases it also makes sense to take a different approach. > > We introduced the openshift sub-command to group together some > functionality > which deal with OpenShift specifics. Given that we changed the > implementation > of the service command and the fact that in OpenShift you are dealing with > routes, it felt natural to move the 'service' command. > As a user it doesn't feel natural at all as kubernetes services are a core part of kubernetes; they are not openshift specifics. Also OpenShift resources are being refactored to use API groups; so minikube could even detect the Route resource along with Ingress/NodePort and use it in the "minikube service" command. So it seems to make lesse sense hiding "service" in an openshift specific menu. Where possible OpenShift should look and feel like Kubernetes. -- 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: From jdyson at redhat.com Thu May 11 13:18:39 2017 From: jdyson at redhat.com (Jimmi Dyson) Date: Thu, 11 May 2017 14:18:39 +0100 Subject: [Devtools] minishift promotion In-Reply-To: <20170511131208.GB13477@nineveh.local> References: <20170511131208.GB13477@nineveh.local> Message-ID: On Thu, May 11, 2017 at 2:12 PM, Hardy Ferentschik wrote: > Hi, > > On Wed, 10-May-2017 14:57, James Strachan 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 ;) > > That is not true. You can actually categorize commands. Most commands at > the > top level are much more about managing the VM, than anything around > Kubernetes > or OpenShift. The 'openshift' command creates a namespace for commands > which > directly effect OpenShift. > Categorization like this makes sense, but in this case it is just an extension of the command from minikube. Categorization must also take into account UX: typing `minishift openshift ....` should be minimized IMO, it's just too much to type.... Laziness rulez. > > --Hardy > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Thu May 11 13:19:06 2017 From: jstracha at redhat.com (James Strachan) Date: Thu, 11 May 2017 14:19:06 +0100 Subject: [Devtools] minishift promotion In-Reply-To: <20170511131208.GB13477@nineveh.local> References: <20170511131208.GB13477@nineveh.local> Message-ID: On Thu, May 11, 2017 at 2:12 PM, Hardy Ferentschik wrote: > Hi, > > On Wed, 10-May-2017 14:57, James Strachan 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 ;) > > That is not true. You can actually categorize commands. Most commands at > the > top level are much more about managing the VM, than anything around > Kubernetes > or OpenShift. The 'openshift' command creates a namespace for commands > which > directly effect OpenShift. > so are you gonna also rename "minishift start" which is like "minikube start" to be "minishift openshift start" too? Thats 'openshift speciifc' too right? -- 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: From hferents at redhat.com Thu May 11 13:26:29 2017 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 11 May 2017 15:26:29 +0200 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: <20170511132629.GC13477@nineveh.local> Hi, > > 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. Be are basing our implementation on the use of _oc_ which is not available in Minikube. So in this particular case we don't have much to backport. > One of the defining goals of minishift was to make the transition from > minikube to minishift easy. Keeping commands consistent is key to that Sure, but consistency with Minikube cannot be the only goal. There are other considerations as well. On other names we for example aligned with Minikube. We called the extension mechanism also 'addons', even though they work differently. Minikube implemented now the ability to create multiple instances. Something we followed and had input to. The plan is to align as much as possible there as well. So we are for sure interested to keep consistency. However, in some cases it also makes sense to do things differently. > 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. We follow issues which are relevant to us, however, have not contributed enough to Minikube. Moving forward it would be nice to see some more collaboration on code level as well. However, all the work up to Minishift 1.0.0 barely touched Minikube inherited code. There are only a few things we could have contributed back so far. Two come to mind: * Driver initialisation (together with the ability to pass through driver specific options) * Host folder framework Both things would be good fits for Minikube as well. Up to know we were really hands on to just get Minishift 1.0.0 and CDK 3.0.0 ready. Moving forward we can have a discussion now whether we should try to get for example the things mentioned above into Minikube. However, this will take quite some doing and will slow us down with feature development for Minishift. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From hferents at redhat.com Thu May 11 13:28:37 2017 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 11 May 2017 15:28:37 +0200 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: <20170511132837.GD13477@nineveh.local> Hi, > >> 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. > > > > OK, so let's see if we can fix this targeting the next point release. Well, we start with an issue and take it from there. Personally I believe in this particular case we did the right thing. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From hferents at redhat.com Thu May 11 13:32:01 2017 From: hferents at redhat.com (Hardy Ferentschik) Date: Thu, 11 May 2017 15:32:01 +0200 Subject: [Devtools] minishift promotion In-Reply-To: References: Message-ID: <20170511133201.GE13477@nineveh.local> Hi, > 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. +1 > 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 . I think this is the thing we should be focusing on. Right now there is no easy way to contribute back. If we could make the core of Minikube more of a library/ dependency we could indeed fix bugs directly upstream. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: From jdyson at redhat.com Thu May 11 13:32:34 2017 From: jdyson at redhat.com (Jimmi Dyson) Date: Thu, 11 May 2017 14:32:34 +0100 Subject: [Devtools] minishift promotion In-Reply-To: <20170511132837.GD13477@nineveh.local> References: <20170511132837.GD13477@nineveh.local> Message-ID: On Thu, May 11, 2017 at 2:28 PM, Hardy Ferentschik wrote: > Hi, > > > >> 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. > > > > > > > OK, so let's see if we can fix this targeting the next point release. > > Well, we start with an issue and take it from there. Personally I believe > in > this particular case we did the right thing. > Take this as feedback from us as users rather than engineers... as a user that moves between minikube and minishift (a user group I believe we were targeting with minishift) the lack of consistency is annoying. Regardless of what shared code there is, I, as a user, prefer the command and ux to be consistent. > > --Hardy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhuss at redhat.com Thu May 11 16:56:08 2017 From: rhuss at redhat.com (Roland Huss) Date: Thu, 11 May 2017 16:56:08 +0000 Subject: [Devtools] minishift promotion In-Reply-To: <20170511131208.GB13477@nineveh.local> References: <20170511131208.GB13477@nineveh.local> Message-ID: > > That is not true. You can actually categorize commands. Most commands at > the > top level are much more about managing the VM, than anything around > Kubernetes > or OpenShift. The 'openshift' command creates a namespace for commands > which > directly effect OpenShift. > But isn't it all about "Service" as central element, a concept which is common to both Kubernetes and OpenShift ? That this is implemented differently in minikube and minishift is, well, an implementation detail which imo must not leak into the UX. If it would be 'minishift openshift route' then I might agree. But not for "service". In fact, I did a demo today with both minikube and minishift and stumbled about this very UX difference hardly. You can't explain this to someone without apologizing. .... roland > --Hardy > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu May 11 19:44:29 2017 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 11 May 2017 20:44:29 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: <20170511131208.GB13477@nineveh.local> Message-ID: On Thu, May 11, 2017 at 5:56 PM, Roland Huss wrote: > That is not true. You can actually categorize commands. Most commands at >> the >> top level are much more about managing the VM, than anything around >> Kubernetes >> or OpenShift. The 'openshift' command creates a namespace for commands >> which >> directly effect OpenShift. >> > > But isn't it all about "Service" as central element, a concept which is > common to both Kubernetes and OpenShift ? That this is implemented > differently in minikube and minishift is, well, an implementation detail > which imo must not leak into the UX. > > If it would be 'minishift openshift route' then I might agree. But not for > "service". > > In fact, I did a demo today with both minikube and minishift and stumbled > about this very UX difference hardly. You can't explain this to someone > without apologizing. > > I agree anything Service related belongs on the Kube side of the equation. Unless OpenShift has something special extensions to the Service object that I am not aware of (which is very possible, I am highly ignorant of many things). > .... roland > > > > > >> --Hardy >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoleman at redhat.com Thu May 11 19:58:35 2017 From: ccoleman at redhat.com (Clayton Coleman) Date: Thu, 11 May 2017 15:58:35 -0400 Subject: [Devtools] minishift promotion In-Reply-To: References: <20170511131208.GB13477@nineveh.local> Message-ID: <7680010055818473969@unknownmsgid> Nothing that should block using the command here On May 11, 2017, at 3:47 PM, Burr Sutter wrote: On Thu, May 11, 2017 at 5:56 PM, Roland Huss wrote: > That is not true. You can actually categorize commands. Most commands at >> the >> top level are much more about managing the VM, than anything around >> Kubernetes >> or OpenShift. The 'openshift' command creates a namespace for commands >> which >> directly effect OpenShift. >> > > But isn't it all about "Service" as central element, a concept which is > common to both Kubernetes and OpenShift ? That this is implemented > differently in minikube and minishift is, well, an implementation detail > which imo must not leak into the UX. > > If it would be 'minishift openshift route' then I might agree. But not for > "service". > > In fact, I did a demo today with both minikube and minishift and stumbled > about this very UX difference hardly. You can't explain this to someone > without apologizing. > > I agree anything Service related belongs on the Kube side of the equation. Unless OpenShift has something special extensions to the Service object that I am not aware of (which is very possible, I am highly ignorant of many things). > .... roland > > > > > >> --Hardy >> >> _______________________________________________ >> 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 > > _______________________________________________ Devtools mailing list Devtools at redhat.com https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Fri May 12 03:16:53 2017 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 12 May 2017 04:16:53 +0100 Subject: [Devtools] Recordings from Summit Message-ID: Here is a great example of a recorded session from Summit https://www.youtube.com/watch?v=1fqSMpRK28I Andy does a super slick demo and Lala provides a nice overview of minishift though he should have demo'd too :-) Are there other good recordings of "developers talking to developers"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Fri May 12 09:30:32 2017 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Fri, 12 May 2017 15:00:32 +0530 Subject: [Devtools] Recordings from Summit In-Reply-To: References: Message-ID: On Fri, May 12, 2017 at 8:46 AM, Burr Sutter wrote: > Here is a great example of a recorded session from Summit > https://www.youtube.com/watch?v=1fqSMpRK28I > > Andy does a super slick demo and Lala provides a nice overview of > minishift though he should have demo'd too :-) > We actually had submitted Minishift/CDK specific talks so that we can do proper demos of just Minishift/CDK but the talks did not get selected. Are there other good recordings of "developers talking to developers"? > > Not exactly a developer to developer, but Hardy had given a talk in OpenShift commons [1] about Minishift. You might find it useful. [1] https://www.youtube.com/watch?v=WTYe-ntTf-s Thanks, Lala > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhuss at redhat.com Fri May 12 11:50:05 2017 From: rhuss at redhat.com (Roland Huss) Date: Fri, 12 May 2017 11:50:05 +0000 Subject: [Devtools] minishift promotion In-Reply-To: <7680010055818473969@unknownmsgid> References: <20170511131208.GB13477@nineveh.local> <7680010055818473969@unknownmsgid> Message-ID: while we are at it, I would even suggest to make 'minishift dashboard' an alias for 'minishift console' (so that both commands will lead to the OpenShift console) ... roland On Thu, May 11, 2017 at 9:58 PM Clayton Coleman wrote: > Nothing that should block using the command here > > On May 11, 2017, at 3:47 PM, Burr Sutter wrote: > > > > On Thu, May 11, 2017 at 5:56 PM, Roland Huss wrote: > >> That is not true. You can actually categorize commands. Most commands at >>> the >>> top level are much more about managing the VM, than anything around >>> Kubernetes >>> or OpenShift. The 'openshift' command creates a namespace for commands >>> which >>> directly effect OpenShift. >>> >> >> But isn't it all about "Service" as central element, a concept which is >> common to both Kubernetes and OpenShift ? That this is implemented >> differently in minikube and minishift is, well, an implementation detail >> which imo must not leak into the UX. >> >> If it would be 'minishift openshift route' then I might agree. But not >> for "service". >> >> In fact, I did a demo today with both minikube and minishift and stumbled >> about this very UX difference hardly. You can't explain this to someone >> without apologizing. >> >> > > I agree anything Service related belongs on the Kube side of the > equation. Unless OpenShift has something special extensions to the Service > object that I am not aware of (which is very possible, I am highly ignorant > of many things). > > > >> .... roland >> >> >> >> >> >>> --Hardy >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstracha at redhat.com Fri May 12 12:30:53 2017 From: jstracha at redhat.com (James Strachan) Date: Fri, 12 May 2017 13:30:53 +0100 Subject: [Devtools] minishift promotion In-Reply-To: References: <20170511131208.GB13477@nineveh.local> <7680010055818473969@unknownmsgid> Message-ID: +1 thats tripped me up a few times now you come to mention it On Fri, May 12, 2017 at 12:50 PM, Roland Huss wrote: > while we are at it, I would even suggest to make 'minishift dashboard' an > alias for 'minishift console' (so that both commands will lead to the > OpenShift console) > > ... roland > > On Thu, May 11, 2017 at 9:58 PM Clayton Coleman > wrote: > >> Nothing that should block using the command here >> >> On May 11, 2017, at 3:47 PM, Burr Sutter wrote: >> >> >> >> On Thu, May 11, 2017 at 5:56 PM, Roland Huss wrote: >> >>> That is not true. You can actually categorize commands. Most commands at >>>> the >>>> top level are much more about managing the VM, than anything around >>>> Kubernetes >>>> or OpenShift. The 'openshift' command creates a namespace for commands >>>> which >>>> directly effect OpenShift. >>>> >>> >>> But isn't it all about "Service" as central element, a concept which is >>> common to both Kubernetes and OpenShift ? That this is implemented >>> differently in minikube and minishift is, well, an implementation detail >>> which imo must not leak into the UX. >>> >>> If it would be 'minishift openshift route' then I might agree. But not >>> for "service". >>> >>> In fact, I did a demo today with both minikube and minishift and >>> stumbled about this very UX difference hardly. You can't explain this to >>> someone without apologizing. >>> >>> >> >> I agree anything Service related belongs on the Kube side of the >> equation. Unless OpenShift has something special extensions to the Service >> object that I am not aware of (which is very possible, I am highly ignorant >> of many things). >> >> >> >>> .... roland >>> >>> >>> >>> >>> >>>> --Hardy >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jporter at redhat.com Wed May 17 16:15:14 2017 From: jporter at redhat.com (Jason Porter) Date: Wed, 17 May 2017 10:15:14 -0600 Subject: [Devtools] Who would like to do a short interview about their work on OpenShift.io? Message-ID: I'm looking for some people across the board (engineers, designers, UX, UI, marketing, managers, etc) to do some quick interviews about OpenShift.io. The list of questions is small. We'll do them over BlueJeans, Skype, Hangouts, etc. Initially, I need five volunteers, but if it goes well I'll be doing more of them. The idea is to get a behind the scenes look at what went into (is going into) making OpenShift.io. We'll be putting it up on the developers site, probably on the blog. Ideally, I'd like to start doing the interviews next week, probably mid to late week and start getting them up on the site the week after. I'll probably be doing some simple editing and post processing, but nothing major. The list of questions: Name What you worked on One difficulty you overcame One success you recall What excites you about io Who would like to help me out? I've already spoken to Todd about this and he likes the idea. -- Jason Porter Senior Software Engineer developers.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuir at redhat.com Fri May 19 14:48:03 2017 From: pmuir at redhat.com (Pete Muir) Date: Fri, 19 May 2017 10:48:03 -0400 Subject: [Devtools] Fwd: Debugging RxJS code In-Reply-To: References: Message-ID: Excellent writeup :-) ---------- Forwarded message ---------- From: Soumya Deb Date: 19 May 2017 at 10:11 Subject: Debugging RxJS code To: devtools-planner Team, Was having a chat with Michael and it came up that we need better ways to debug our application, and as we're relying heavily on async approach, debugging is significantly harder for us as the procedural debuggers are limited in that aspect. So I looked into possible solutions which can help us debug our application better, while using all the goodness of RxJS Observables etc. Some of these may already be known to many of you, but I'm just putting them together, just in case you may find it helpful and consolidated in one place (email isn't the best place for that, but I'll start here and have the discussion, before moving it somewhere better). Ordered by the ascending level of rigorousness and descending popularity of usage. Strategy 1: using `do` in the data/process chains =================================== Observable .from([source]) .do(x => f(x)) // f(x) is a function that can be anything // including, but not limited to, `console.log` // *wink* *wink* *deadpan* .subscribe(x => g(x)) // N.B: very same can be achieved with .debug(), but that implies you can't process the argument the way you like, it'll be posted on the console output as is. Strategy 2: allow long stack traces ========================= var Rx = require('rx'); Rx.config.longStackSupport = true; // This will make RxJS spew less utter bullshit // and more relevant stack trace with better formatting // which is actually less "long" than it usually is otherwise Strategy 3: using more formidable Observable methods ======================================== There are several flow control operators, some of which make excellent use for debugging. For example: filter, debounce, lift, audit (and many more). Strategy 4: use 3rd party tools ====================== Experimental Debugger: https://github.com/jhoguet/rxjs-debugger Visualizer for RxJS streams: http://jaredforsyth.com/rxvision/ This is pretty much what I've gathered. Strategy 1 and 2 should be useful to all of us and should be used project-wide IMO; whereas 3 and 4 are for the enthusiasts who want to go the extra mile. I'll keep a lookout for any update on this topic, as after RxJS 5 release more debugging tools are to be expected, as this rewrite has opened up some new avenues for it (which wasn't as viable in v4). If you have suggestion, or something that I've missed to list, please do let me know. Thanks and hope it helps us. -- Pete Muir Technical Director, Red Hat Developer From ctrielof at redhat.com Tue May 30 19:06:02 2017 From: ctrielof at redhat.com (Carl Trieloff) Date: Tue, 30 May 2017 15:06:02 -0400 Subject: [Devtools] Who would like to do a short interview about their work on OpenShift.io? In-Reply-To: References: Message-ID: On Wed, May 17, 2017 at 12:15 PM, Jason Porter wrote: > I'm looking for some people across the board (engineers, designers, UX, > UI, marketing, managers, etc) to do some quick interviews about > OpenShift.io. The list of questions is small. We'll do them over BlueJeans, > Skype, Hangouts, etc. Initially, I need five volunteers, but if it goes > well I'll be doing more of them. The idea is to get a behind the scenes > look at what went into (is going into) making OpenShift.io. We'll be > putting it up on the developers site, probably on the blog. Ideally, I'd > like to start doing the interviews next week, probably mid to late week and > start getting them up on the site the week after. I'll probably be doing > some simple editing and post processing, but nothing major. > > The list of questions: > > Name > What you worked on > One difficulty you overcame > One success you recall > What excites you about io > > Who would like to help me out? I've already spoken to Todd about this and > he likes the idea. > > -- > Jason Porter > Senior Software Engineer > developers.redhat.com > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jporter at redhat.com Tue May 30 21:44:19 2017 From: jporter at redhat.com (Jason Porter) Date: Tue, 30 May 2017 15:44:19 -0600 Subject: [Devtools] [devtools-team] Who would like to do a short interview about their work on OpenShift.io? In-Reply-To: References: Message-ID: Great! Thanks, Konrad. I'm interviewing Max next Wednesday. Feel free to find a time in my calendar and let's get something going! On Tue, May 30, 2017 at 3:17 PM, Konrad Kleine wrote: > I volunteer as well. > -- Jason Porter Senior Software Engineer developers.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: