From bsutter at redhat.com Mon Jul 2 02:02:55 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sun, 1 Jul 2018 22:02:55 -0400 Subject: [Devtools] minishift "offline" Message-ID: I am trying to figure out the trick to help my minishift work better offline - as in jumping from conference room to conference room, building to airport to building jumping on different networks, plus with image caching. I have either Istio (bit.ly/istio-tutorial) or OpenWhisk ( bit.ly/faas-tutorial) which are painful to "reload" if minishift gets wonky about the changing of networks (especially over slow conference networks) So, I have added minishift ip --set-static perhaps that will help but I am not sure how to test the theory. Also, in the event that the ip address does change and the VM need recreation (create steps seen in the two tutorial docs), I need to figure out how to "export" my images and then re-import. minishift image cache-config add docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 minishift image cache-config add docker.io/istio/citadel:0.8.0 minishift image cache-config add docker.io/istio/grafana:0.8.0 minishift image cache-config add docker.io/istio/mixer:0.8.0 minishift image cache-config add docker.io/istio/pilot:0.8.0 minishift image cache-config add docker.io/istio/proxy_init:0.8.0 minishift image cache-config add docker.io/istio/proxyv2:0.8.0 minishift image cache-config add docker.io/istio/servicegraph:0.8.0 minishift image cache-config add docker.io/istio/sidecar_injector:0.8.0 minishift image cache-config add docker.io/jaegertracing/all-in-one:1.5 minishift image cache-config add docker.io/jaegertracing/all-in-one:latest minishift image cache-config add docker.io/openshift/origin-deployer:v3.9.0 minishift image cache-config add docker.io/openshift/origin-docker-registry:v3.9.0 minishift image cache-config add docker.io/openshift/origin-haproxy-router:v3.9.0 minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 minishift image cache-config add docker.io/openshift/origin-web-console:v3.9.0 minishift image cache-config add docker.io/openshift/origin:v3.9.0 minishift image cache-config add docker.io/prom/prometheus:latest minishift image cache-config add docker.io/prom/statsd-exporter:latest minishift image cache-config add example/customer:latest minishift image cache-config add example/preference:v1 minishift image cache-config add example/recommendation:v1 minishift image cache-config add example/recommendation:v2 minishift image cache-config view this looks pretty good BUT export --all fails minishift image export --all [: docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 docker.io/istio/citadel:0.8.0 docker.io/istio/grafana:0.8.0 docker.io/istio/mixer:0.8.0 docker.io/istio/pilot:0.8.0 docker.io/istio/proxy_init:0.8.0 docker.io/istio/proxyv2:0.8.0 docker.io/istio/servicegraph:0.8.0 docker.io/istio/sidecar_injector:0.8.0 docker.io/jaegertracing/all-in-one:1.5 docker.io/jaegertracing/all-in-one:latest docker.io/openshift/origin-deployer:v3.9.0 docker.io/openshift/origin-docker-registry:v3.9.0 docker.io/openshift/origin-haproxy-router:v3.9.0 docker.io/openshift/origin-pod:v3.9.0 docker.io/openshift/origin-web-console:v3.9.0 docker.io/openshift/origin:v3.9.0 docker.io/prom/prometheus:latest docker.io/prom/statsd-exporter:latest example/customer:latest example/preference:v1 example/recommendation:v1 example/recommendation:v2 quay.io/coreos/hyperkube:v1.7.6_coreos.0] contains an invalid image names: Error parsing image name ':': invalid reference format minishift version minishift v1.20.0+53c500a -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Mon Jul 2 05:08:59 2018 From: prkumar at redhat.com (Praveen Kumar) Date: Mon, 2 Jul 2018 05:08:59 +0000 Subject: [Devtools] minishift "offline" In-Reply-To: References: Message-ID: On Mon, Jul 2, 2018 at 2:02 AM, Burr Sutter wrote: > I am trying to figure out the trick to help my minishift work better offline > - as in jumping from conference room to conference room, building to airport > to building jumping on different networks, plus with image caching. > > I have either Istio (bit.ly/istio-tutorial) or OpenWhisk > (bit.ly/faas-tutorial) which are painful to "reload" if minishift gets wonky > about the changing of networks (especially over slow conference networks) > > So, I have added > minishift ip --set-static > perhaps that will help but I am not sure how to test the theory. To test this out once you set the static IP you can try to stop the minishift and then change the network, finally start the minishfit again which should have same IP instead getting another one. > > Also, in the event that the ip address does change and the VM need > recreation (create steps seen in the two tutorial docs), I need to figure > out how to "export" my images and then re-import. > > minishift image cache-config add > docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 > minishift image cache-config add docker.io/istio/citadel:0.8.0 > minishift image cache-config add docker.io/istio/grafana:0.8.0 > minishift image cache-config add docker.io/istio/mixer:0.8.0 > minishift image cache-config add docker.io/istio/pilot:0.8.0 > minishift image cache-config add docker.io/istio/proxy_init:0.8.0 > minishift image cache-config add docker.io/istio/proxyv2:0.8.0 > minishift image cache-config add docker.io/istio/servicegraph:0.8.0 > minishift image cache-config add docker.io/istio/sidecar_injector:0.8.0 > minishift image cache-config add docker.io/jaegertracing/all-in-one:1.5 > minishift image cache-config add docker.io/jaegertracing/all-in-one:latest > minishift image cache-config add docker.io/openshift/origin-deployer:v3.9.0 > minishift image cache-config add > docker.io/openshift/origin-docker-registry:v3.9.0 > minishift image cache-config add > docker.io/openshift/origin-haproxy-router:v3.9.0 > minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 > minishift image cache-config add > docker.io/openshift/origin-web-console:v3.9.0 > minishift image cache-config add docker.io/openshift/origin:v3.9.0 > minishift image cache-config add docker.io/prom/prometheus:latest > minishift image cache-config add docker.io/prom/statsd-exporter:latest > minishift image cache-config add example/customer:latest > minishift image cache-config add example/preference:v1 > minishift image cache-config add example/recommendation:v1 > minishift image cache-config add example/recommendation:v2 > > minishift image cache-config view > this looks pretty good > > BUT export --all fails As per logs, looks like you have an updated image tag and when it happen docker put : to older image tag which can't be parsed by minishift hence this error. Workaround: manually remove that : image hash and then do export --all ``` $ eval $(minishift docker-env) $ docker images | grep none $ docker rmi $ minishift import export --all ``` > minishift image export --all > [: docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 > docker.io/istio/citadel:0.8.0 docker.io/istio/grafana:0.8.0 > docker.io/istio/mixer:0.8.0 docker.io/istio/pilot:0.8.0 > docker.io/istio/proxy_init:0.8.0 docker.io/istio/proxyv2:0.8.0 > docker.io/istio/servicegraph:0.8.0 docker.io/istio/sidecar_injector:0.8.0 > docker.io/jaegertracing/all-in-one:1.5 > docker.io/jaegertracing/all-in-one:latest > docker.io/openshift/origin-deployer:v3.9.0 > docker.io/openshift/origin-docker-registry:v3.9.0 > docker.io/openshift/origin-haproxy-router:v3.9.0 > docker.io/openshift/origin-pod:v3.9.0 > docker.io/openshift/origin-web-console:v3.9.0 > docker.io/openshift/origin:v3.9.0 docker.io/prom/prometheus:latest > docker.io/prom/statsd-exporter:latest example/customer:latest > example/preference:v1 example/recommendation:v1 example/recommendation:v2 > quay.io/coreos/hyperkube:v1.7.6_coreos.0] contains an invalid image names: > Error parsing image name ':': invalid reference format > > > minishift version > minishift v1.20.0+53c500a > > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From bsutter at redhat.com Sat Jul 14 18:51:41 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 14 Jul 2018 14:51:41 -0400 Subject: [Devtools] 10 pods per core Message-ID: Can we relax that setting to allow 15 or 20 pods per code on minishift? In order to run "hello world" with Istio, you need at least 19 pods (not including build/deploy pods) and using 3 cores (on a 4 core machine) for the VM running minishift makes everything else (slides, chrome, etc) often much too slow. If you have not run our primary Istio tutorial via minishift, it would be a good experience for you :-) bit.ly/istio-tutorial -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoleman at redhat.com Sat Jul 14 19:27:25 2018 From: ccoleman at redhat.com (Clayton Coleman) Date: Sun, 15 Jul 2018 00:57:25 +0530 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: In 3.9 we removed this default (or maybe 3.10). If minishift isn?t explicitly setting it should already be relaxed. On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: Can we relax that setting to allow 15 or 20 pods per code on minishift? In order to run "hello world" with Istio, you need at least 19 pods (not including build/deploy pods) and using 3 cores (on a 4 core machine) for the VM running minishift makes everything else (slides, chrome, etc) often much too slow. If you have not run our primary Istio tutorial via minishift, it would be a good experience for you :-) bit.ly/istio-tutorial _______________________________________________ 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 Sat Jul 14 19:47:57 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 14 Jul 2018 15:47:57 -0400 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: Awesome, I will be trying that now :-) On Sat, Jul 14, 2018 at 3:27 PM Clayton Coleman wrote: > In 3.9 we removed this default (or maybe 3.10). If minishift isn?t > explicitly setting it should already be relaxed. > > On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: > > Can we relax that setting to allow 15 or 20 pods per code on minishift? > > In order to run "hello world" with Istio, you need at least 19 pods (not > including build/deploy pods) and using 3 cores (on a 4 core machine) for > the VM running minishift makes everything else (slides, chrome, etc) often > much too slow. > > If you have not run our primary Istio tutorial via minishift, it would be > a good experience for you :-) > bit.ly/istio-tutorial > > > > > _______________________________________________ > 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 Sat Jul 14 21:03:17 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 14 Jul 2018 17:03:17 -0400 Subject: [Devtools] An answer I should have known a long time ago Message-ID: What is public support forum for minishift? Is it: https://stackoverflow.com/questions/tagged/minishift and for Openshift users? https://stackoverflow.com/questions/tagged/openshift?sort=newest&pageSize=50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Mon Jul 16 04:27:23 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 16 Jul 2018 09:57:23 +0530 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman wrote: > In 3.9 we removed this default (or maybe 3.10). If minishift isn?t > explicitly setting it should already be relaxed. > > +1, we had similar observation on 3.9. On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: > > Can we relax that setting to allow 15 or 20 pods per code on minishift? > > In order to run "hello world" with Istio, you need at least 19 pods (not > including build/deploy pods) and using 3 cores (on a 4 core machine) for > the VM running minishift makes everything else (slides, chrome, etc) often > much too slow. > > If you have not run our primary Istio tutorial via minishift, it would be > a good experience for you :-) > bit.ly/istio-tutorial > > > > > _______________________________________________ > 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 bodavis at redhat.com Mon Jul 16 15:45:41 2018 From: bodavis at redhat.com (Bob Davis) Date: Mon, 16 Jul 2018 11:45:41 -0400 Subject: [Devtools] An answer I should have known a long time ago In-Reply-To: References: Message-ID: I believe the answer is that it depends on the user's subscription. If they have an OpenShift support sub, they may be able to get answers through that, but if it's a dev sub, then yes, StackOverflow would the place to go. Heinz may be able to provide some more definitive statements on this, or be able to loop in the correct individuals. Bob On Sat, Jul 14, 2018 at 5:03 PM Burr Sutter wrote: > What is public support forum for minishift? > > Is it: > https://stackoverflow.com/questions/tagged/minishift > > and for Openshift users? > > https://stackoverflow.com/questions/tagged/openshift?sort=newest&pageSize=50 > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Bob Davis Senior Product Manager, Red Hat Developers bobdavis at redhat.com | 210-452-8945 developers.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharpur at redhat.com Tue Jul 17 05:53:32 2018 From: mharpur at redhat.com (Mitchell Harpur) Date: Tue, 17 Jul 2018 01:53:32 -0400 Subject: [Devtools] Hey ... I really need your input for just a couple of minutes ... please !!! Message-ID: All Please take a quick look at this google document ... it wont take long *https://docs.google.com/document/d/1h-MDYNfJBbg4RvMaYXxowWkMBx1IEFdk_Vz0El5zJUc/edit?usp=sharing * In the context of the OpenShift developer experience, I am doing a brain storm to come up with a list of tools that we all *use to develop OpenShift applications of all shapes types and sizes.* Please add to the list any tools that you use, develop or like (if it is not there already). I am ideally trying to *map Red Hat's tools*, but I am also interested in the *gaps of the capabilities of our tools/workflows* ... so add 3rd party/competitor tools (open source or closed source/commercial) if you think they *add value to the conversation* ... but only if you actually use them or know that we use them for container based apps. If you see a missing category or developer workflow... do me a favor and add it in too. This is not meant to be an exhaustive list all tools that anyone uses ... but the tools that YOU use and also if its a Red Hat tool or not. If you have a link that explains the capabilities of the tool, as well as the person who maintains the tool (assuming that it is open source)... please add it as well. Much appreciated and thanks a ton . Sincerely, Mitch Harpur Principle Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak at redhat.com Tue Jul 17 07:41:40 2018 From: aslak at redhat.com (Aslak Knutsen) Date: Tue, 17 Jul 2018 09:41:40 +0200 Subject: [Devtools] Hey ... I really need your input for just a couple of minutes ... please !!! In-Reply-To: References: Message-ID: We started a similar doc a few days ago to capture flows we have on the outside of osio that we could bring into osio. https://docs.google.com/document/d/1QUbWabt-NQRFLHOVczRVqgwFAMA1P4R76dqC97KkpHw/edit?ts=5b4d97e0 -aslak- On Tue, Jul 17, 2018 at 7:54 AM Mitchell Harpur wrote: > All > > Please take a quick look at this google document ... it wont take long > > *https://docs.google.com/document/d/1h-MDYNfJBbg4RvMaYXxowWkMBx1IEFdk_Vz0El5zJUc/edit?usp=sharing > * > > > > In the context of the OpenShift developer experience, I am doing a brain > storm to come up with a list of tools that we all *use to develop > OpenShift applications of all shapes types and sizes.* Please add to the > list any tools that you use, develop or like (if it is not there already). > I am ideally trying to *map Red Hat's tools*, but I am also interested in > the *gaps of the capabilities of our tools/workflows* ... so add 3rd > party/competitor tools (open source or closed source/commercial) if you > think they *add value to the conversation* ... but only if you actually > use them or know that we use them for container based apps. If you see a > missing category or developer workflow... do me a favor and add it in too. > This is not meant to be an exhaustive list all tools that anyone uses ... > but the tools that YOU use and also if its a Red Hat tool or not. If you > have a link that explains the capabilities of the tool, as well as the > person who maintains the tool (assuming that it is open source)... please > add it as well. Much appreciated and thanks a ton . > > Sincerely, > Mitch Harpur > Principle Software Engineer > > _______________________________________________ > 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 Jul 19 00:29:28 2018 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 Jul 2018 18:29:28 -0600 Subject: [Devtools] damn! Message-ID: Checking if requested OpenShift version 'v3.9.0' is valid ... Hit github rate limit: GET https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 API rate limit exceeded for 50.207.133.82. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 13m35s] -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Thu Jul 19 04:13:12 2018 From: prkumar at redhat.com (Praveen Kumar) Date: Thu, 19 Jul 2018 04:13:12 +0000 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: > > Checking if requested OpenShift version 'v3.9.0' is valid ... > > Hit github rate limit: GET https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 API rate limit exceeded for 50.207.133.82. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 13m35s] I hope this is coming from minishift side, for rate limit we have doc in troubleshooting guide[0], I think it good to tell user this doc link or says check the troubleshooting document section. [0] https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From bsutter at redhat.com Thu Jul 19 04:31:51 2018 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 18 Jul 2018 22:31:51 -0600 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: On Wed, Jul 18, 2018 at 10:13 PM Praveen Kumar wrote: > On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: > > > > Checking if requested OpenShift version 'v3.9.0' is valid ... > > > > Hit github rate limit: GET > https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 > API rate limit exceeded for 50.207.133.82. (But here's the good news: > Authenticated requests get a higher rate limit. Check out the documentation > for more details.) [rate reset in 13m35s] > > I hope this is coming from minishift side, for rate limit we have doc > in troubleshooting guide[0], I think it good to tell user this doc > link or says check the troubleshooting document section. > > [0] > https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded > > I was unaware of this and I had just 5 minutes before the presentation! Luckily I had been working harder on "being offline" and it actually worked in this case. I turned off wifi on the laptop and ran for 1 hour with most of the bit.ly/istio-tutorial demos completely disconnected. I will try to send out my "script" for going offline (plus you have to do any maven builds to cache those downloads as well). > > _______________________________________________ > > 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 prkumar at redhat.com Thu Jul 19 04:35:44 2018 From: prkumar at redhat.com (Praveen Kumar) Date: Thu, 19 Jul 2018 04:35:44 +0000 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 4:32 AM Burr Sutter wrote: > > > > On Wed, Jul 18, 2018 at 10:13 PM Praveen Kumar wrote: >> >> On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: >> > >> > Checking if requested OpenShift version 'v3.9.0' is valid ... >> > >> > Hit github rate limit: GET https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 API rate limit exceeded for 50.207.133.82. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 13m35s] >> >> I hope this is coming from minishift side, for rate limit we have doc >> in troubleshooting guide[0], I think it good to tell user this doc >> link or says check the troubleshooting document section. >> >> [0] https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded >> > > I was unaware of this and I had just 5 minutes before the presentation! Luckily I had been working harder on "being offline" and it actually worked in this case. I turned off wifi on the laptop and ran for 1 hour with most of the bit.ly/istio-tutorial demos completely disconnected. Good to know it all worked out, please do share the "scripts". > > I will try to send out my "script" for going offline (plus you have to do any maven builds to cache those downloads as well). >> >> > _______________________________________________ >> > Devtools mailing list >> > Devtools at redhat.com >> > https://www.redhat.com/mailman/listinfo/devtools >> >> >> >> -- >> Praveen Kumar >> https://fedoraproject.org/wiki/User:Kumarpraveen -- Praveen Kumar https://fedoraproject.org/wiki/User:Kumarpraveen From lmohanty at redhat.com Thu Jul 19 06:22:41 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 19 Jul 2018 11:52:41 +0530 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 9:43 AM, Praveen Kumar wrote: > On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: > > > > Checking if requested OpenShift version 'v3.9.0' is valid ... > > > > Hit github rate limit: GET https://api.github.com/repos/ > openshift/origin/releases/tags/v3.9.0: 403 API rate limit exceeded for > 50.207.133.82. (But here's the good news: Authenticated requests get a > higher rate limit. Check out the documentation for more details.) [rate > reset in 13m35s] > > I hope this is coming from minishift side, for rate limit we have doc > in troubleshooting guide[0], I think it good to tell user this doc > link or says check the troubleshooting document section. > > [0] https://docs.openshift.org/latest/minishift/troubleshooting/ > troubleshooting-getting-started.html#github-api-rate-limit-exceeded > > Also you skip these startup checks [1] . However these checks are there to warn you or fail the minishift start if certain conditions are not met. You can skip the individual checks too. For example if you want to skip the version check then you need to skip the check i.e. "minishift config set skip-check-openshift-version true" . There are some other checks you can see in "minishift config --help | grep -i openshift" * skip-check-openshift-version * warn-check-openshift-version * skip-check-openshift-release * warn-check-openshift-release [1] https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#minshift-startup-check-failed -Lala -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Thu Jul 19 07:35:42 2018 From: bgurung at redhat.com (Budh Ram Gurung) Date: Thu, 19 Jul 2018 13:05:42 +0530 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: Hi Burr, On Thu, Jul 19, 2018 at 11:53 AM Lalatendu Mohanty wrote: > > > On Thu, Jul 19, 2018 at 9:43 AM, Praveen Kumar wrote: > >> On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: >> > >> > Checking if requested OpenShift version 'v3.9.0' is valid ... >> > >> > Hit github rate limit: GET >> https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 >> API rate limit exceeded for 50.207.133.82. (But here's the good news: >> Authenticated requests get a higher rate limit. Check out the documentation >> for more details.) [rate reset in 13m35s] >> >> I hope this is coming from minishift side, for rate limit we have doc >> in troubleshooting guide[0], I think it good to tell user this doc >> link or says check the troubleshooting document section. >> >> [0] >> https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded >> >> > Also you skip these startup checks [1] . However these checks are there to > warn you or fail the minishift start if certain conditions are not met. > You can skip the individual checks too. > > For example if you want to skip the version check then you need to skip > the check i.e. "minishift config set skip-check-openshift-version true" . > > There are some other checks you can see in "minishift config --help | grep > -i openshift" > > * skip-check-openshift-version > This is the best solution in this case for you :) > * warn-check-openshift-version > * skip-check-openshift-release > * warn-check-openshift-release > > [1] > https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#minshift-startup-check-failed > > -Lala > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools Regards, Budh Ram Gurung -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Thu Jul 19 08:49:47 2018 From: gbraad at redhat.com (Gerard Braad) Date: Thu, 19 Jul 2018 16:49:47 +0800 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: Burr > I turned off wifi on the laptop and ran for 1 hour with most of the bit.ly/istio-tutorial demos completely disconnected. Curious what else you have done to make this work ... as we have a way to intercept DNS requests, but it is not foolproof yet (manual config) On Thu, Jul 19, 2018 at 3:36 PM Budh Ram Gurung wrote: > > Hi Burr, > > On Thu, Jul 19, 2018 at 11:53 AM Lalatendu Mohanty wrote: >> >> >> >> On Thu, Jul 19, 2018 at 9:43 AM, Praveen Kumar wrote: >>> >>> On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: >>> > >>> > Checking if requested OpenShift version 'v3.9.0' is valid ... >>> > >>> > Hit github rate limit: GET https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 API rate limit exceeded for 50.207.133.82. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 13m35s] >>> >>> I hope this is coming from minishift side, for rate limit we have doc >>> in troubleshooting guide[0], I think it good to tell user this doc >>> link or says check the troubleshooting document section. >>> >>> [0] https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded >>> >> >> Also you skip these startup checks [1] . However these checks are there to warn you or fail the minishift start if certain conditions are not met. You can skip the individual checks too. >> >> For example if you want to skip the version check then you need to skip the check i.e. "minishift config set skip-check-openshift-version true" . >> >> There are some other checks you can see in "minishift config --help | grep -i openshift" >> >> * skip-check-openshift-version > > > This is the best solution in this case for you :) > >> >> * warn-check-openshift-version >> * skip-check-openshift-release >> * warn-check-openshift-release >> >> [1] https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#minshift-startup-check-failed >> >> -Lala >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > Regards, > Budh Ram Gurung > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Thu Jul 19 12:48:36 2018 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 19 Jul 2018 06:48:36 -0600 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: There must still be some limit - and it seems about 10 pods per core (just counting the Running, not Completed/Pending/Error). Failed Scheduling 0/1 nodes are available: 1 Insufficient pods. 26 times in the last On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty wrote: > > > On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman > wrote: > >> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >> explicitly setting it should already be relaxed. >> >> > +1, we had similar observation on 3.9. > > On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >> >> Can we relax that setting to allow 15 or 20 pods per code on minishift? >> >> In order to run "hello world" with Istio, you need at least 19 pods (not >> including build/deploy pods) and using 3 cores (on a 4 core machine) for >> the VM running minishift makes everything else (slides, chrome, etc) often >> much too slow. >> >> If you have not run our primary Istio tutorial via minishift, it would be >> a good experience for you :-) >> bit.ly/istio-tutorial >> >> >> >> >> _______________________________________________ >> 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 Thu Jul 19 12:50:54 2018 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 19 Jul 2018 06:50:54 -0600 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 1:36 AM Budh Ram Gurung wrote: > Hi Burr, > > On Thu, Jul 19, 2018 at 11:53 AM Lalatendu Mohanty > wrote: > >> >> >> On Thu, Jul 19, 2018 at 9:43 AM, Praveen Kumar >> wrote: >> >>> On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter wrote: >>> > >>> > Checking if requested OpenShift version 'v3.9.0' is valid ... >>> > >>> > Hit github rate limit: GET >>> https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 >>> API rate limit exceeded for 50.207.133.82. (But here's the good news: >>> Authenticated requests get a higher rate limit. Check out the documentation >>> for more details.) [rate reset in 13m35s] >>> >>> I hope this is coming from minishift side, for rate limit we have doc >>> in troubleshooting guide[0], I think it good to tell user this doc >>> link or says check the troubleshooting document section. >>> >>> [0] >>> https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded >>> >>> >> Also you skip these startup checks [1] . However these checks are there >> to warn you or fail the minishift start if certain conditions are not met. >> You can skip the individual checks too. >> >> For example if you want to skip the version check then you need to skip >> the check i.e. "minishift config set skip-check-openshift-version true" >> . >> >> There are some other checks you can see in "minishift config --help | >> grep -i openshift" >> >> * skip-check-openshift-version >> > > This is the best solution in this case for you :) > Is there a reason why this check is "fatal", not allowing minishift to start? It seems like it should not be a fatal error (GitHub rate limiting therefore die) > > >> * warn-check-openshift-version >> * skip-check-openshift-release >> * warn-check-openshift-release >> >> [1] >> https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#minshift-startup-check-failed >> >> -Lala >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > Regards, > Budh Ram Gurung > > > _______________________________________________ > 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 Jul 19 12:53:14 2018 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 19 Jul 2018 06:53:14 -0600 Subject: [Devtools] damn! In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 2:50 AM Gerard Braad wrote: > Burr > > > I turned off wifi on the laptop and ran for 1 hour with most of the > bit.ly/istio-tutorial demos completely disconnected. > > Curious what else you have done to make this work ... as we have a way > to intercept DNS requests, but it is not foolproof yet (manual config) > I have Gasmask on the Mac. It allows you to easily edit and make new /etc/hosts files "on-the-fly". So, I can easily just add/edit/activate different hosts files and since I had been working on the plane (literally on-the-fly) I have experimented with it a few times and it worked in this instance when minishift could not see any network, it would start (I guess the ping 8.8.8.8 is its test to see if it should try GitHub) 192.168.99.104 customer-tutorial.192.168.99.104.nip.io 192.168.99.104 grafana-istio-system.192.168.99.104.nip.io 192.168.99.104 tracing-istio-system.192.168.99.104.nip.io 192.168.99.104 prometheus-istio-system.192.168.99.104.nip.io 192.168.99.104 servicegraph-istio-system.192.168.99.104.nip.io 192.168.99.104 istio-ingressgateway-istio-system.192.168.99.104.nip.io > On Thu, Jul 19, 2018 at 3:36 PM Budh Ram Gurung > wrote: > > > > Hi Burr, > > > > On Thu, Jul 19, 2018 at 11:53 AM Lalatendu Mohanty > wrote: > >> > >> > >> > >> On Thu, Jul 19, 2018 at 9:43 AM, Praveen Kumar > wrote: > >>> > >>> On Thu, Jul 19, 2018 at 12:31 AM Burr Sutter > wrote: > >>> > > >>> > Checking if requested OpenShift version 'v3.9.0' is valid ... > >>> > > >>> > Hit github rate limit: GET > https://api.github.com/repos/openshift/origin/releases/tags/v3.9.0: 403 > API rate limit exceeded for 50.207.133.82. (But here's the good news: > Authenticated requests get a higher rate limit. Check out the documentation > for more details.) [rate reset in 13m35s] > >>> > >>> I hope this is coming from minishift side, for rate limit we have doc > >>> in troubleshooting guide[0], I think it good to tell user this doc > >>> link or says check the troubleshooting document section. > >>> > >>> [0] > https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#github-api-rate-limit-exceeded > >>> > >> > >> Also you skip these startup checks [1] . However these checks are there > to warn you or fail the minishift start if certain conditions are not met. > You can skip the individual checks too. > >> > >> For example if you want to skip the version check then you need to > skip the check i.e. "minishift config set skip-check-openshift-version > true" . > >> > >> There are some other checks you can see in "minishift config --help | > grep -i openshift" > >> > >> * skip-check-openshift-version > > > > > > This is the best solution in this case for you :) > > > >> > >> * warn-check-openshift-version > >> * skip-check-openshift-release > >> * warn-check-openshift-release > >> > >> [1] > https://docs.openshift.org/latest/minishift/troubleshooting/troubleshooting-getting-started.html#minshift-startup-check-failed > >> > >> -Lala > >> _______________________________________________ > >> Devtools mailing list > >> Devtools at redhat.com > >> https://www.redhat.com/mailman/listinfo/devtools > > > > > > Regards, > > Budh Ram Gurung > > > > > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaury at redhat.com Thu Jul 19 13:10:44 2018 From: jmaury at redhat.com (Jean-Francois Maury) Date: Thu, 19 Jul 2018 15:10:44 +0200 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: oc get nodes against cdk 3.5 (minishift ?) will show you the node is limited to 20 pods On Thu, Jul 19, 2018 at 2:49 PM Burr Sutter wrote: > There must still be some limit - and it seems about 10 pods per core (just > counting the Running, not Completed/Pending/Error). > > Failed Scheduling > 0/1 nodes are available: 1 Insufficient pods. > 26 times in the last > > On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty > wrote: > >> >> >> On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman >> wrote: >> >>> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >>> explicitly setting it should already be relaxed. >>> >>> >> +1, we had similar observation on 3.9. >> >> On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >>> >>> Can we relax that setting to allow 15 or 20 pods per code on minishift? >>> >>> In order to run "hello world" with Istio, you need at least 19 pods (not >>> including build/deploy pods) and using 3 cores (on a 4 core machine) for >>> the VM running minishift makes everything else (slides, chrome, etc) often >>> much too slow. >>> >>> If you have not run our primary Istio tutorial via minishift, it would >>> be a good experience for you :-) >>> bit.ly/istio-tutorial >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > -- JEFF MAURY Red Hat jmaury at redhat.com @redhatjobs redhatjobs @redhatjobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu Jul 19 13:21:37 2018 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 19 Jul 2018 07:21:37 -0600 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 7:10 AM Jean-Francois Maury wrote: > oc get nodes against cdk 3.5 (minishift ?) will show you the node is > limited to 20 pods > I do not see "20" in that output oc get nodes NAME STATUS ROLES AGE VERSION localhost Ready 8h v1.9.1+a0ce1bc657 > > On Thu, Jul 19, 2018 at 2:49 PM Burr Sutter wrote: > >> There must still be some limit - and it seems about 10 pods per core >> (just counting the Running, not Completed/Pending/Error). >> >> Failed Scheduling >> 0/1 nodes are available: 1 Insufficient pods. >> 26 times in the last >> >> On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty >> wrote: >> >>> >>> >>> On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman >>> wrote: >>> >>>> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >>>> explicitly setting it should already be relaxed. >>>> >>>> >>> +1, we had similar observation on 3.9. >>> >>> On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >>>> >>>> Can we relax that setting to allow 15 or 20 pods per code on minishift? >>>> >>>> In order to run "hello world" with Istio, you need at least 19 pods >>>> (not including build/deploy pods) and using 3 cores (on a 4 core machine) >>>> for the VM running minishift makes everything else (slides, chrome, etc) >>>> often much too slow. >>>> >>>> If you have not run our primary Istio tutorial via minishift, it would >>>> be a good experience for you :-) >>>> bit.ly/istio-tutorial >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > -- > > JEFF MAURY > > Red Hat > > > > jmaury at redhat.com > > > @redhatjobs redhatjobs > @redhatjobs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaury at redhat.com Thu Jul 19 13:26:03 2018 From: jmaury at redhat.com (Jean-Francois Maury) Date: Thu, 19 Jul 2018 15:26:03 +0200 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: Sorry oc get nodes -o yaml On Thu, Jul 19, 2018 at 3:21 PM Burr Sutter wrote: > > > On Thu, Jul 19, 2018 at 7:10 AM Jean-Francois Maury > wrote: > >> oc get nodes against cdk 3.5 (minishift ?) will show you the node is >> limited to 20 pods >> > > I do not see "20" in that output > > oc get nodes > > NAME STATUS ROLES AGE VERSION > > localhost Ready 8h v1.9.1+a0ce1bc657 > >> >> On Thu, Jul 19, 2018 at 2:49 PM Burr Sutter wrote: >> >>> There must still be some limit - and it seems about 10 pods per core >>> (just counting the Running, not Completed/Pending/Error). >>> >>> Failed Scheduling >>> 0/1 nodes are available: 1 Insufficient pods. >>> 26 times in the last >>> >>> On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty >>> wrote: >>> >>>> >>>> >>>> On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman >>>> wrote: >>>> >>>>> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >>>>> explicitly setting it should already be relaxed. >>>>> >>>>> >>>> +1, we had similar observation on 3.9. >>>> >>>> On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >>>>> >>>>> Can we relax that setting to allow 15 or 20 pods per code on minishift? >>>>> >>>>> In order to run "hello world" with Istio, you need at least 19 pods >>>>> (not including build/deploy pods) and using 3 cores (on a 4 core machine) >>>>> for the VM running minishift makes everything else (slides, chrome, etc) >>>>> often much too slow. >>>>> >>>>> If you have not run our primary Istio tutorial via minishift, it would >>>>> be a good experience for you :-) >>>>> bit.ly/istio-tutorial >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> -- >> >> JEFF MAURY >> >> Red Hat >> >> >> >> jmaury at redhat.com >> >> >> @redhatjobs redhatjobs >> @redhatjobs >> >> > -- JEFF MAURY Red Hat jmaury at redhat.com @redhatjobs redhatjobs @redhatjobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu Jul 19 13:47:48 2018 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 19 Jul 2018 07:47:48 -0600 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: On Thu, Jul 19, 2018 at 7:26 AM Jean-Francois Maury wrote: > Sorry oc get nodes -o yaml > since I am mostly trying to be a Java & JavaScript developer, I am a poor OpenShift and Linux sys admin/operator so, I am pretty literal :-) > On Thu, Jul 19, 2018 at 3:21 PM Burr Sutter wrote: > >> >> >> On Thu, Jul 19, 2018 at 7:10 AM Jean-Francois Maury >> wrote: >> >>> oc get nodes against cdk 3.5 (minishift ?) will show you the node is >>> limited to 20 pods >>> >> >> I do not see "20" in that output >> >> oc get nodes >> >> NAME STATUS ROLES AGE VERSION >> >> localhost Ready 8h v1.9.1+a0ce1bc657 >> >>> >>> On Thu, Jul 19, 2018 at 2:49 PM Burr Sutter wrote: >>> >>>> There must still be some limit - and it seems about 10 pods per core >>>> (just counting the Running, not Completed/Pending/Error). >>>> >>>> Failed Scheduling >>>> 0/1 nodes are available: 1 Insufficient pods. >>>> 26 times in the last >>>> >>>> On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman >>>> > wrote: >>>>> >>>>>> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >>>>>> explicitly setting it should already be relaxed. >>>>>> >>>>>> >>>>> +1, we had similar observation on 3.9. >>>>> >>>>> On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >>>>>> >>>>>> Can we relax that setting to allow 15 or 20 pods per code on >>>>>> minishift? >>>>>> >>>>>> In order to run "hello world" with Istio, you need at least 19 pods >>>>>> (not including build/deploy pods) and using 3 cores (on a 4 core machine) >>>>>> for the VM running minishift makes everything else (slides, chrome, etc) >>>>>> often much too slow. >>>>>> >>>>>> If you have not run our primary Istio tutorial via minishift, it >>>>>> would be a good experience for you :-) >>>>>> bit.ly/istio-tutorial >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> -- >>> >>> JEFF MAURY >>> >>> Red Hat >>> >>> >>> >>> jmaury at redhat.com >>> >>> >>> @redhatjobs redhatjobs >>> @redhatjobs >>> >>> >> > > -- > > JEFF MAURY > > Red Hat > > > > jmaury at redhat.com > > > @redhatjobs redhatjobs > @redhatjobs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bodavis at redhat.com Thu Jul 19 17:02:27 2018 From: bodavis at redhat.com (Bob Davis) Date: Thu, 19 Jul 2018 13:02:27 -0400 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: This is a good point though - as I gather that a lot of the administrative workload is being shifted over to the team that owns the app vs. the traditional IT/admin teams we have traditionally built for. This means we're going to have more and more developer-admins who know Linux and/or OpenShift poorly and for whom achieving wizard-like admin chops is not a goal. Bob On Thu, Jul 19, 2018 at 9:49 AM Burr Sutter wrote: > > > On Thu, Jul 19, 2018 at 7:26 AM Jean-Francois Maury > wrote: > >> Sorry oc get nodes -o yaml >> > > since I am mostly trying to be a Java & JavaScript developer, I am a poor > OpenShift and Linux sys admin/operator > > so, I am pretty literal :-) > > >> > > On Thu, Jul 19, 2018 at 3:21 PM Burr Sutter wrote: >> >>> >>> >>> On Thu, Jul 19, 2018 at 7:10 AM Jean-Francois Maury >>> wrote: >>> >>>> oc get nodes against cdk 3.5 (minishift ?) will show you the node is >>>> limited to 20 pods >>>> >>> >>> I do not see "20" in that output >>> >>> oc get nodes >>> >>> NAME STATUS ROLES AGE VERSION >>> >>> localhost Ready 8h v1.9.1+a0ce1bc657 >>> >>>> >>>> On Thu, Jul 19, 2018 at 2:49 PM Burr Sutter wrote: >>>> >>>>> There must still be some limit - and it seems about 10 pods per core >>>>> (just counting the Running, not Completed/Pending/Error). >>>>> >>>>> Failed Scheduling >>>>> 0/1 nodes are available: 1 Insufficient pods. >>>>> 26 times in the last >>>>> >>>>> On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty < >>>>> lmohanty at redhat.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman < >>>>>> ccoleman at redhat.com> wrote: >>>>>> >>>>>>> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >>>>>>> explicitly setting it should already be relaxed. >>>>>>> >>>>>>> >>>>>> +1, we had similar observation on 3.9. >>>>>> >>>>>> On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >>>>>>> >>>>>>> Can we relax that setting to allow 15 or 20 pods per code on >>>>>>> minishift? >>>>>>> >>>>>>> In order to run "hello world" with Istio, you need at least 19 pods >>>>>>> (not including build/deploy pods) and using 3 cores (on a 4 core machine) >>>>>>> for the VM running minishift makes everything else (slides, chrome, etc) >>>>>>> often much too slow. >>>>>>> >>>>>>> If you have not run our primary Istio tutorial via minishift, it >>>>>>> would be a good experience for you :-) >>>>>>> bit.ly/istio-tutorial >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> >>>> JEFF MAURY >>>> >>>> Red Hat >>>> >>>> >>>> >>>> jmaury at redhat.com >>>> >>>> >>>> @redhatjobs redhatjobs >>>> @redhatjobs >>>> >>>> >>> >> >> -- >> >> JEFF MAURY >> >> Red Hat >> >> >> >> jmaury at redhat.com >> >> >> @redhatjobs redhatjobs >> @redhatjobs >> >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Bob Davis Senior Product Manager, Red Hat Developers bobdavis at redhat.com | 210-452-8945 developers.redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Fri Jul 20 17:20:26 2018 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 20 Jul 2018 12:20:26 -0500 Subject: [Devtools] 10 pods per core In-Reply-To: References: Message-ID: I just need this 10 pods per core thing to go away. It makes demo'ing off a laptop a lot harder. :-) On Thu, Jul 19, 2018 at 12:02 PM Bob Davis wrote: > This is a good point though - as I gather that a lot of the administrative > workload is being shifted over to the team that owns the app vs. the > traditional IT/admin teams we have traditionally built for. This means > we're going to have more and more developer-admins who know Linux and/or > OpenShift poorly and for whom achieving wizard-like admin chops is not a > goal. > > Bob > > > On Thu, Jul 19, 2018 at 9:49 AM Burr Sutter wrote: > >> >> >> On Thu, Jul 19, 2018 at 7:26 AM Jean-Francois Maury >> wrote: >> >>> Sorry oc get nodes -o yaml >>> >> >> since I am mostly trying to be a Java & JavaScript developer, I am a poor >> OpenShift and Linux sys admin/operator >> >> so, I am pretty literal :-) >> >> >>> >> >> On Thu, Jul 19, 2018 at 3:21 PM Burr Sutter wrote: >>> >>>> >>>> >>>> On Thu, Jul 19, 2018 at 7:10 AM Jean-Francois Maury >>>> wrote: >>>> >>>>> oc get nodes against cdk 3.5 (minishift ?) will show you the node is >>>>> limited to 20 pods >>>>> >>>> >>>> I do not see "20" in that output >>>> >>>> oc get nodes >>>> >>>> NAME STATUS ROLES AGE VERSION >>>> >>>> localhost Ready 8h v1.9.1+a0ce1bc657 >>>> >>>>> >>>>> On Thu, Jul 19, 2018 at 2:49 PM Burr Sutter >>>>> wrote: >>>>> >>>>>> There must still be some limit - and it seems about 10 pods per core >>>>>> (just counting the Running, not Completed/Pending/Error). >>>>>> >>>>>> Failed Scheduling >>>>>> 0/1 nodes are available: 1 Insufficient pods. >>>>>> 26 times in the last >>>>>> >>>>>> On Sun, Jul 15, 2018 at 10:27 PM Lalatendu Mohanty < >>>>>> lmohanty at redhat.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Jul 15, 2018 at 12:57 AM, Clayton Coleman < >>>>>>> ccoleman at redhat.com> wrote: >>>>>>> >>>>>>>> In 3.9 we removed this default (or maybe 3.10). If minishift isn?t >>>>>>>> explicitly setting it should already be relaxed. >>>>>>>> >>>>>>>> >>>>>>> +1, we had similar observation on 3.9. >>>>>>> >>>>>>> On Jul 14, 2018, at 2:51 PM, Burr Sutter wrote: >>>>>>>> >>>>>>>> Can we relax that setting to allow 15 or 20 pods per code on >>>>>>>> minishift? >>>>>>>> >>>>>>>> In order to run "hello world" with Istio, you need at least 19 pods >>>>>>>> (not including build/deploy pods) and using 3 cores (on a 4 core machine) >>>>>>>> for the VM running minishift makes everything else (slides, chrome, etc) >>>>>>>> often much too slow. >>>>>>>> >>>>>>>> If you have not run our primary Istio tutorial via minishift, it >>>>>>>> would be a good experience for you :-) >>>>>>>> bit.ly/istio-tutorial >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> JEFF MAURY >>>>> >>>>> Red Hat >>>>> >>>>> >>>>> >>>>> jmaury at redhat.com >>>>> >>>>> >>>>> @redhatjobs redhatjobs >>>>> @redhatjobs >>>>> >>>>> >>>> >>> >>> -- >>> >>> JEFF MAURY >>> >>> Red Hat >>> >>> >>> >>> jmaury at redhat.com >>> >>> >>> @redhatjobs redhatjobs >>> @redhatjobs >>> >>> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > > > -- > > Bob Davis > Senior Product Manager, Red Hat Developers > bobdavis at redhat.com | 210-452-8945 > developers.redhat.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Sat Jul 21 15:07:23 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 21 Jul 2018 11:07:23 -0400 Subject: [Devtools] minishift offline Message-ID: I do not know if we have the "how to go offline with minishift" but here is my basic process. 1. minishift start minishift profile set 9StepsAwesome minishift config set memory 12GB minishift config set cpus 3 minishift config set vm-driver virtualbox minishift config set disk-size 30g minishift config set image-caching true minishift addon enable admin-user minishift addon enable anyuid minishift ip --set-static minishift start 2. load up everything you normally need like the Istio Tutorial, Helloworld MSA, doing whatever "docker build" that needs to happen, etc. 3. echo 'Current Cache' minishift image cache-config view 4. echo 'Docker images inside of VM' minishift image list --vm 5. echo 'Export those' minishift image export --all 6. echo 'Configure the cache of those images' minishift image cache-config add docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 minishift image cache-config add docker.io/istio/citadel:0.8.0 minishift image cache-config add docker.io/istio/grafana:0.8.0 minishift image cache-config add docker.io/istio/mixer:0.8.0 minishift image cache-config add docker.io/istio/pilot:0.8.0 minishift image cache-config add docker.io/istio/proxy_init:0.8.0 minishift image cache-config add docker.io/istio/proxyv2:0.8.0 minishift image cache-config add docker.io/istio/servicegraph:0.8.0 minishift image cache-config add docker.io/istio/sidecar_injector:0.8.0 minishift image cache-config add docker.io/jaegertracing/all-in-one:1.5 minishift image cache-config add docker.io/jaegertracing/all-in-one:latest minishift image cache-config add docker.io/openshift/origin-deployer:v3.9.0 minishift image cache-config add docker.io/openshift/origin-docker-registry:v3.9.0 minishift image cache-config add docker.io/openshift/origin-haproxy-router:v3.9.0 minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 minishift image cache-config add docker.io/openshift/origin-web-console:v3.9.0 minishift image cache-config add docker.io/openshift/origin:v3.9.0 minishift image cache-config add docker.io/prom/prometheus:latest minishift image cache-config add docker.io/prom/statsd-exporter:latest minishift image cache-config add quay.io/coreos/hyperkube:v1.7.6_coreos.0 7. minishift stop 8. minishift delete 9. repeat step #1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Sun Jul 22 21:40:41 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sun, 22 Jul 2018 17:40:41 -0400 Subject: [Devtools] minishift ip --set-static Message-ID: I might have an misunderstanding of "minishift ip --set-static" I am trying to have many profiles for the various demo arrangements that I run. I thought I would always use "set-static" to address 509 cert error that tends to pop-up between "start", "stop" and "start" [1] But, it seems that if you use "minishift ip --set-static" with more than one profile, it attempts to reuse the same IP address with other profiles. I really do need too be able to switch profiles "on-the-fly" during presentations minishift profile set istiodemo minishift start minishift stop minishift profile set openwhiskdemo minishift start minishift profile set microservices minishift start [1] Caused By: Error: Get https://192.168.99.102:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.104, not 192.168.99.102 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Sun Jul 22 21:46:58 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sun, 22 Jul 2018 17:46:58 -0400 Subject: [Devtools] minishift offline In-Reply-To: References: Message-ID: The last time I tried, Che required minishift. Is there a non-minishift-based Che now? On Sat, Jul 21, 2018 at 6:44 PM Brad Micklea wrote: > I think Che is actually easier to take offline than this... Ironic. > > > On Sat, Jul 21, 2018 at 11:08 Burr Sutter wrote: > >> I do not know if we have the "how to go offline with minishift" but here >> is my basic process. >> >> 1. minishift start >> minishift profile set 9StepsAwesome >> minishift config set memory 12GB >> minishift config set cpus 3 >> minishift config set vm-driver virtualbox >> minishift config set disk-size 30g >> minishift config set image-caching true >> minishift addon enable admin-user >> minishift addon enable anyuid >> minishift ip --set-static >> minishift start >> 2. load up everything you normally need like the Istio Tutorial, >> Helloworld MSA, doing whatever "docker build" that needs to happen, etc. >> 3. echo 'Current Cache' >> minishift image cache-config view >> 4. echo 'Docker images inside of VM' >> minishift image list --vm >> 5. echo 'Export those' >> minishift image export --all >> 6. echo 'Configure the cache of those images' >> minishift image cache-config add >> docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 >> minishift image cache-config add docker.io/istio/citadel:0.8.0 >> minishift image cache-config add docker.io/istio/grafana:0.8.0 >> minishift image cache-config add docker.io/istio/mixer:0.8.0 >> minishift image cache-config add docker.io/istio/pilot:0.8.0 >> minishift image cache-config add docker.io/istio/proxy_init:0.8.0 >> minishift image cache-config add docker.io/istio/proxyv2:0.8.0 >> minishift image cache-config add docker.io/istio/servicegraph:0.8.0 >> minishift image cache-config add docker.io/istio/sidecar_injector:0.8.0 >> minishift image cache-config add docker.io/jaegertracing/all-in-one:1.5 >> minishift image cache-config add >> docker.io/jaegertracing/all-in-one:latest >> minishift image cache-config add >> docker.io/openshift/origin-deployer:v3.9.0 >> minishift image cache-config add >> docker.io/openshift/origin-docker-registry:v3.9.0 >> minishift image cache-config add >> docker.io/openshift/origin-haproxy-router:v3.9.0 >> minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 >> minishift image cache-config add >> docker.io/openshift/origin-web-console:v3.9.0 >> minishift image cache-config add docker.io/openshift/origin:v3.9.0 >> minishift image cache-config add docker.io/prom/prometheus:latest >> minishift image cache-config add docker.io/prom/statsd-exporter:latest >> minishift image cache-config add quay.io/coreos/hyperkube:v1.7.6_coreos.0 >> >> 7. minishift stop >> 8. minishift delete >> 9. repeat step #1 >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > -- > > Brad Micklea // BU Lead // Developer Tools & Program // 416.707.0792 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Mon Jul 23 03:04:02 2018 From: gbraad at redhat.com (Gerard Braad) Date: Mon, 23 Jul 2018 11:04:02 +0800 Subject: [Devtools] minishift ip --set-static In-Reply-To: References: Message-ID: It would be very unlikely the same IP address is used, as the address is collected from the actual VM and stored inside. But let's see what happened... Can you try to dump the contents of the config file with: minishift ssh -- cat /var/lib/minishift/networking-* On Mon, Jul 23, 2018 at 5:41 AM Burr Sutter wrote: > > I might have an misunderstanding of "minishift ip --set-static" > > I am trying to have many profiles for the various demo arrangements that I run. > > I thought I would always use "set-static" to address 509 cert error that tends to pop-up between "start", "stop" and "start" [1] > > But, it seems that if you use "minishift ip --set-static" with more than one profile, it attempts to reuse the same IP address with other profiles. > > I really do need too be able to switch profiles "on-the-fly" during presentations > minishift profile set istiodemo > minishift start > minishift stop > minishift profile set openwhiskdemo > minishift start > minishift profile set microservices > minishift start > > > > > [1] Caused By: > > Error: Get https://192.168.99.102:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.104, not 192.168.99.102 > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From jmaury at redhat.com Mon Jul 23 06:37:08 2018 From: jmaury at redhat.com (Jean-Francois Maury) Date: Mon, 23 Jul 2018 08:37:08 +0200 Subject: [Devtools] minishift ip --set-static In-Reply-To: References: Message-ID: According to the off line thread Minishift ip set status must be run after the vm is started Le lun. 23 juil. 2018 ? 05:04, Gerard Braad a ?crit : > It would be very unlikely the same IP address is used, as the address > is collected from the actual VM and stored inside. > But let's see what happened... Can you try to dump the contents of the > config file with: > > minishift ssh -- cat /var/lib/minishift/networking-* > > > On Mon, Jul 23, 2018 at 5:41 AM Burr Sutter wrote: > > > > I might have an misunderstanding of "minishift ip --set-static" > > > > I am trying to have many profiles for the various demo arrangements that > I run. > > > > I thought I would always use "set-static" to address 509 cert error that > tends to pop-up between "start", "stop" and "start" [1] > > > > But, it seems that if you use "minishift ip --set-static" with more than > one profile, it attempts to reuse the same IP address with other profiles. > > > > I really do need too be able to switch profiles "on-the-fly" during > presentations > > minishift profile set istiodemo > > minishift start > > minishift stop > > minishift profile set openwhiskdemo > > minishift start > > minishift profile set microservices > > minishift start > > > > > > > > > > [1] Caused By: > > > > Error: Get https://192.168.99.102:8443/healthz/ready: x509: > certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, > 192.168.99.104, not 192.168.99.102 > > _______________________________________________ > > 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 gbraad at redhat.com Mon Jul 23 07:37:39 2018 From: gbraad at redhat.com (Gerard Braad) Date: Mon, 23 Jul 2018 15:37:39 +0800 Subject: [Devtools] minishift ip --set-static In-Reply-To: References: Message-ID: Right, it is not applied automatically to the VM as the current implementation is not very fast. It would be possible to make this a standard option to be performed after the VM has been started, but so far no request or demand for this came up. ... until now? On Mon, Jul 23, 2018 at 2:40 PM Jean-Francois Maury wrote: > > According to the off line thread > Minishift ip set status must be run after the vm is started > > Le lun. 23 juil. 2018 ? 05:04, Gerard Braad a ?crit : >> >> It would be very unlikely the same IP address is used, as the address >> is collected from the actual VM and stored inside. >> But let's see what happened... Can you try to dump the contents of the >> config file with: >> >> minishift ssh -- cat /var/lib/minishift/networking-* >> >> >> On Mon, Jul 23, 2018 at 5:41 AM Burr Sutter wrote: >> > >> > I might have an misunderstanding of "minishift ip --set-static" >> > >> > I am trying to have many profiles for the various demo arrangements that I run. >> > >> > I thought I would always use "set-static" to address 509 cert error that tends to pop-up between "start", "stop" and "start" [1] >> > >> > But, it seems that if you use "minishift ip --set-static" with more than one profile, it attempts to reuse the same IP address with other profiles. >> > >> > I really do need too be able to switch profiles "on-the-fly" during presentations >> > minishift profile set istiodemo >> > minishift start >> > minishift stop >> > minishift profile set openwhiskdemo >> > minishift start >> > minishift profile set microservices >> > minishift start >> > >> > >> > >> > >> > [1] Caused By: >> > >> > Error: Get https://192.168.99.102:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.104, not 192.168.99.102 >> > _______________________________________________ >> > 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 From gbraad at redhat.com Mon Jul 23 07:40:21 2018 From: gbraad at redhat.com (Gerard Braad) Date: Mon, 23 Jul 2018 15:40:21 +0800 Subject: [Devtools] minishift offline In-Reply-To: References: Message-ID: Che does not require minishift. Che requires to run on a container runtime... https://www.eclipse.org/che/docs/quick-start.html Been a while since I tried to deploy it this way ... ... So, the deployment for an OpenShift-like deployment is easiest when using the Che add-on for minishift. On Mon, Jul 23, 2018 at 5:47 AM Burr Sutter wrote: > > The last time I tried, Che required minishift. Is there a non-minishift-based Che now? > > On Sat, Jul 21, 2018 at 6:44 PM Brad Micklea wrote: >> >> I think Che is actually easier to take offline than this... Ironic. >> >> >> On Sat, Jul 21, 2018 at 11:08 Burr Sutter wrote: >>> >>> I do not know if we have the "how to go offline with minishift" but here is my basic process. >>> >>> 1. minishift start >>> minishift profile set 9StepsAwesome >>> minishift config set memory 12GB >>> minishift config set cpus 3 >>> minishift config set vm-driver virtualbox >>> minishift config set disk-size 30g >>> minishift config set image-caching true >>> minishift addon enable admin-user >>> minishift addon enable anyuid >>> minishift ip --set-static >>> minishift start >>> 2. load up everything you normally need like the Istio Tutorial, Helloworld MSA, doing whatever "docker build" that needs to happen, etc. >>> 3. echo 'Current Cache' >>> minishift image cache-config view >>> 4. echo 'Docker images inside of VM' >>> minishift image list --vm >>> 5. echo 'Export those' >>> minishift image export --all >>> 6. echo 'Configure the cache of those images' >>> minishift image cache-config add docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 >>> minishift image cache-config add docker.io/istio/citadel:0.8.0 >>> minishift image cache-config add docker.io/istio/grafana:0.8.0 >>> minishift image cache-config add docker.io/istio/mixer:0.8.0 >>> minishift image cache-config add docker.io/istio/pilot:0.8.0 >>> minishift image cache-config add docker.io/istio/proxy_init:0.8.0 >>> minishift image cache-config add docker.io/istio/proxyv2:0.8.0 >>> minishift image cache-config add docker.io/istio/servicegraph:0.8.0 >>> minishift image cache-config add docker.io/istio/sidecar_injector:0.8.0 >>> minishift image cache-config add docker.io/jaegertracing/all-in-one:1.5 >>> minishift image cache-config add docker.io/jaegertracing/all-in-one:latest >>> minishift image cache-config add docker.io/openshift/origin-deployer:v3.9.0 >>> minishift image cache-config add docker.io/openshift/origin-docker-registry:v3.9.0 >>> minishift image cache-config add docker.io/openshift/origin-haproxy-router:v3.9.0 >>> minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 >>> minishift image cache-config add docker.io/openshift/origin-web-console:v3.9.0 >>> minishift image cache-config add docker.io/openshift/origin:v3.9.0 >>> minishift image cache-config add docker.io/prom/prometheus:latest >>> minishift image cache-config add docker.io/prom/statsd-exporter:latest >>> minishift image cache-config add quay.io/coreos/hyperkube:v1.7.6_coreos.0 >>> >>> 7. minishift stop >>> 8. minishift delete >>> 9. repeat step #1 >>> >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >> >> -- >> >> Brad Micklea // BU Lead // Developer Tools & Program // 416.707.0792 > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Mon Jul 23 15:25:33 2018 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 23 Jul 2018 11:25:33 -0400 Subject: [Devtools] minishift offline In-Reply-To: References: Message-ID: On Mon, Jul 23, 2018 at 3:40 AM Gerard Braad wrote: > Che does not require minishift. > Che requires to run on a container runtime... > > https://www.eclipse.org/che/docs/quick-start.html I was unaware of the Che + Docker for Mac/Windows option. The Docker tools are more pervasive and easier to install for the "average developer". That should help with adoption. > > > Been a while since I tried to deploy it this way ... > > ... So, the deployment for an OpenShift-like deployment is easiest > when using the Che add-on for minishift. > > On Mon, Jul 23, 2018 at 5:47 AM Burr Sutter wrote: > > > > The last time I tried, Che required minishift. Is there a > non-minishift-based Che now? > > > > On Sat, Jul 21, 2018 at 6:44 PM Brad Micklea > wrote: > >> > >> I think Che is actually easier to take offline than this... Ironic. > >> > >> > >> On Sat, Jul 21, 2018 at 11:08 Burr Sutter wrote: > >>> > >>> I do not know if we have the "how to go offline with minishift" but > here is my basic process. > >>> > >>> 1. minishift start > >>> minishift profile set 9StepsAwesome > >>> minishift config set memory 12GB > >>> minishift config set cpus 3 > >>> minishift config set vm-driver virtualbox > >>> minishift config set disk-size 30g > >>> minishift config set image-caching true > >>> minishift addon enable admin-user > >>> minishift addon enable anyuid > >>> minishift ip --set-static > >>> minishift start > >>> 2. load up everything you normally need like the Istio Tutorial, > Helloworld MSA, doing whatever "docker build" that needs to happen, etc. > >>> 3. echo 'Current Cache' > >>> minishift image cache-config view > >>> 4. echo 'Docker images inside of VM' > >>> minishift image list --vm > >>> 5. echo 'Export those' > >>> minishift image export --all > >>> 6. echo 'Configure the cache of those images' > >>> minishift image cache-config add > docker.io/fabric8/java-jboss-openjdk8-jdk:1.3.1 > >>> minishift image cache-config add docker.io/istio/citadel:0.8.0 > >>> minishift image cache-config add docker.io/istio/grafana:0.8.0 > >>> minishift image cache-config add docker.io/istio/mixer:0.8.0 > >>> minishift image cache-config add docker.io/istio/pilot:0.8.0 > >>> minishift image cache-config add docker.io/istio/proxy_init:0.8.0 > >>> minishift image cache-config add docker.io/istio/proxyv2:0.8.0 > >>> minishift image cache-config add docker.io/istio/servicegraph:0.8.0 > >>> minishift image cache-config add > docker.io/istio/sidecar_injector:0.8.0 > >>> minishift image cache-config add > docker.io/jaegertracing/all-in-one:1.5 > >>> minishift image cache-config add > docker.io/jaegertracing/all-in-one:latest > >>> minishift image cache-config add > docker.io/openshift/origin-deployer:v3.9.0 > >>> minishift image cache-config add > docker.io/openshift/origin-docker-registry:v3.9.0 > >>> minishift image cache-config add > docker.io/openshift/origin-haproxy-router:v3.9.0 > >>> minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 > >>> minishift image cache-config add > docker.io/openshift/origin-web-console:v3.9.0 > >>> minishift image cache-config add docker.io/openshift/origin:v3.9.0 > >>> minishift image cache-config add docker.io/prom/prometheus:latest > >>> minishift image cache-config add docker.io/prom/statsd-exporter:latest > >>> minishift image cache-config add > quay.io/coreos/hyperkube:v1.7.6_coreos.0 > >>> > >>> 7. minishift stop > >>> 8. minishift delete > >>> 9. repeat step #1 > >>> > >>> _______________________________________________ > >>> Devtools mailing list > >>> Devtools at redhat.com > >>> https://www.redhat.com/mailman/listinfo/devtools > >> > >> -- > >> > >> Brad Micklea // BU Lead // Developer Tools & Program // 416.707.0792 > > > > _______________________________________________ > > 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 Jul 23 20:57:33 2018 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 23 Jul 2018 16:57:33 -0400 Subject: [Devtools] minishift ip --set-static In-Reply-To: References: Message-ID: Flying to next round of demos so blew those VMs away (minishift delete) and rebuilt. Hopefully the new IP addresses will ?stick? while I am hopping from meeting to meeting this week. But I have scripted the VM rebuild and I think I have offline cached the images I need. On Sun, Jul 22, 2018 at 11:04 PM Gerard Braad wrote: > It would be very unlikely the same IP address is used, as the address > is collected from the actual VM and stored inside. > But let's see what happened... Can you try to dump the contents of the > config file with: > > minishift ssh -- cat /var/lib/minishift/networking-* > > > On Mon, Jul 23, 2018 at 5:41 AM Burr Sutter wrote: > > > > I might have an misunderstanding of "minishift ip --set-static" > > > > I am trying to have many profiles for the various demo arrangements that > I run. > > > > I thought I would always use "set-static" to address 509 cert error that > tends to pop-up between "start", "stop" and "start" [1] > > > > But, it seems that if you use "minishift ip --set-static" with more than > one profile, it attempts to reuse the same IP address with other profiles. > > > > I really do need too be able to switch profiles "on-the-fly" during > presentations > > minishift profile set istiodemo > > minishift start > > minishift stop > > minishift profile set openwhiskdemo > > minishift start > > minishift profile set microservices > > minishift start > > > > > > > > > > [1] Caused By: > > > > Error: Get https://192.168.99.102:8443/healthz/ready: x509: > certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, > 192.168.99.104, not 192.168.99.102 > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Tue Jul 24 10:00:26 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 18:00:26 +0800 Subject: [Devtools] minishift ip --set-static In-Reply-To: References: Message-ID: So, be sure to do: ``` m start m ip --set-static m start --profile newthing m ip --set-static m profile set lastestthing m start m ip --set-static ``` Note: no matter how you set the profile, after start, you need to do the --set-static. On Tue, Jul 24, 2018 at 4:57 AM Burr Sutter wrote: > > Flying to next round of demos so blew those VMs away (minishift delete) and rebuilt. > > Hopefully the new IP addresses will ?stick? while I am hopping from meeting to meeting this week. > > But I have scripted the VM rebuild and I think I have offline cached the images I need. > > > > On Sun, Jul 22, 2018 at 11:04 PM Gerard Braad wrote: >> >> It would be very unlikely the same IP address is used, as the address >> is collected from the actual VM and stored inside. >> But let's see what happened... Can you try to dump the contents of the >> config file with: >> >> minishift ssh -- cat /var/lib/minishift/networking-* >> >> >> On Mon, Jul 23, 2018 at 5:41 AM Burr Sutter wrote: >> > >> > I might have an misunderstanding of "minishift ip --set-static" >> > >> > I am trying to have many profiles for the various demo arrangements that I run. >> > >> > I thought I would always use "set-static" to address 509 cert error that tends to pop-up between "start", "stop" and "start" [1] >> > >> > But, it seems that if you use "minishift ip --set-static" with more than one profile, it attempts to reuse the same IP address with other profiles. >> > >> > I really do need too be able to switch profiles "on-the-fly" during presentations >> > minishift profile set istiodemo >> > minishift start >> > minishift stop >> > minishift profile set openwhiskdemo >> > minishift start >> > minishift profile set microservices >> > minishift start >> > >> > >> > >> > >> > [1] Caused By: >> > >> > Error: Get https://192.168.99.102:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.104, not 192.168.99.102 >> > _______________________________________________ >> > Devtools mailing list >> > Devtools at redhat.com >> > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Tue Jul 24 13:16:01 2018 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 24 Jul 2018 08:16:01 -0500 Subject: [Devtools] must solve this minishift IP problem Message-ID: Here is the seriousness of the situation. I use profiles - like so minishift profile set demo1 minishift start # do some demo minishift stop minishift profile set demo2 minishift start # do some other demo minishift stop minishift profile set demo3 minishift start # yet other demo minishift stop # close laptop, drive/fly to next location, repeat the whole process Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. Caused By: Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 the demos are basically: bit.ly/msa-instructions bit.ly/istio-tutorial bit.ly/faas-tutorial and you can not really run 2 of these in the same VM due to the 10 pods per core limit. minishift ip --set-static does not seem to make the IP "sticky". It really wants to go back to 100. It seems the IP address is not "stored" in the profile. So, this makes profiles essentially unusable. creation script: minishift profile set istio-tutorial minishift config set memory 8GB minishift config set cpus 3 minishift config set vm-driver virtualbox minishift config set image-caching true minishift addon enable admin-user minishift addon enable anyuid # minishift ip --set-static minishift start -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Tue Jul 24 13:32:41 2018 From: bgurung at redhat.com (Budh Ram Gurung) Date: Tue, 24 Jul 2018 19:02:41 +0530 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Hi Burr, On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: > Here is the seriousness of the situation. I use profiles - like so > minishift profile set demo1 > minishift start > # do some demo > minishift stop > minishift profile set demo2 > minishift start > # do some other demo > minishift stop > minishift profile set demo3 > minishift start > # yet other demo > minishift stop > # close laptop, drive/fly to next location, repeat the whole process > > Yet, at the next location, I get a new IP address and the following > error. This particular VM's IP was 106, yet it reverted back to 101. > > Caused By: > Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate > is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, > not 192.168.99.101 > Thanks for taking time and reporting the issue. We will definitely look into it and creating an upstream issue to track it. > the demos are basically: > bit.ly/msa-instructions > bit.ly/istio-tutorial > bit.ly/faas-tutorial > and you can not really run 2 of these in the same VM due to the 10 pods > per core limit. > > minishift ip --set-static does not seem to make the IP "sticky". > It really wants to go back to 100. It seems the IP address is not > "stored" in the profile. > So, this makes profiles essentially unusable. > > creation script: > minishift profile set istio-tutorial > minishift config set memory 8GB > minishift config set cpus 3 > minishift config set vm-driver virtualbox > minishift config set image-caching true > minishift addon enable admin-user > minishift addon enable anyuid > # minishift ip --set-static > > minishift start > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools Regards, Budh Ram Gurung -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Tue Jul 24 13:38:11 2018 From: bgurung at redhat.com (Budh Ram Gurung) Date: Tue, 24 Jul 2018 19:08:11 +0530 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. Regards, Budh Ram Gurung On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: > Hi Burr, > > On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: > >> Here is the seriousness of the situation. I use profiles - like so >> minishift profile set demo1 >> minishift start >> # do some demo >> minishift stop >> minishift profile set demo2 >> minishift start >> # do some other demo >> minishift stop >> minishift profile set demo3 >> minishift start >> # yet other demo >> minishift stop >> # close laptop, drive/fly to next location, repeat the whole process >> >> Yet, at the next location, I get a new IP address and the following >> error. This particular VM's IP was 106, yet it reverted back to 101. >> >> Caused By: >> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate >> is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, >> not 192.168.99.101 >> > > Thanks for taking time and reporting the issue. > We will definitely look into it and creating an upstream issue to track it. > > >> the demos are basically: >> bit.ly/msa-instructions >> bit.ly/istio-tutorial >> bit.ly/faas-tutorial >> and you can not really run 2 of these in the same VM due to the 10 pods >> per core limit. >> >> minishift ip --set-static does not seem to make the IP "sticky". >> It really wants to go back to 100. It seems the IP address is not >> "stored" in the profile. >> So, this makes profiles essentially unusable. >> >> creation script: >> minishift profile set istio-tutorial >> minishift config set memory 8GB >> minishift config set cpus 3 >> minishift config set vm-driver virtualbox >> minishift config set image-caching true >> minishift addon enable admin-user >> minishift addon enable anyuid >> # minishift ip --set-static >> >> minishift start >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > > Regards, > Budh Ram Gurung > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Tue Jul 24 13:53:07 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 21:53:07 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: At what point in the instructions do you actually use the `m ip --set-static` option? I do not see them in the instructions / steps to reproduce. As in the previous email mentioned. Be sure to do: ``` m start m ip --set-static m start --profile newthing m ip --set-static m profile set lastestthing m start m ip --set-static ``` This means you can ONLY make the IP sticky after it has been provisioned to the VM on start once. Note: Only for Hyper-V you can provide it on startup. On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung wrote: > > Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. > > Regards, > Budh Ram Gurung > > > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: >> >> Hi Burr, >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: >>> >>> Here is the seriousness of the situation. I use profiles - like so >>> minishift profile set demo1 >>> minishift start >>> # do some demo >>> minishift stop >>> minishift profile set demo2 >>> minishift start >>> # do some other demo >>> minishift stop >>> minishift profile set demo3 >>> minishift start >>> # yet other demo >>> minishift stop >>> # close laptop, drive/fly to next location, repeat the whole process >>> >>> Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. >>> >>> Caused By: >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 >> >> >> Thanks for taking time and reporting the issue. >> We will definitely look into it and creating an upstream issue to track it. >> >>> >>> the demos are basically: >>> bit.ly/msa-instructions >>> bit.ly/istio-tutorial >>> bit.ly/faas-tutorial >>> and you can not really run 2 of these in the same VM due to the 10 pods per core limit. >>> >>> minishift ip --set-static does not seem to make the IP "sticky". >>> It really wants to go back to 100. It seems the IP address is not "stored" in the profile. >>> So, this makes profiles essentially unusable. >>> >>> creation script: >>> minishift profile set istio-tutorial >>> minishift config set memory 8GB >>> minishift config set cpus 3 >>> minishift config set vm-driver virtualbox >>> minishift config set image-caching true >>> minishift addon enable admin-user >>> minishift addon enable anyuid >>> # minishift ip --set-static >>> >>> minishift start >>> _______________________________________________ >>> Devtools mailing list >>> Devtools at redhat.com >>> https://www.redhat.com/mailman/listinfo/devtools >> >> >> Regards, >> Budh Ram Gurung > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From gbraad at redhat.com Tue Jul 24 13:55:21 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 21:55:21 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: This is a duplicate of the email with subject: "[Devtools] minishift ip --set-static" On Tue, Jul 24, 2018 at 9:53 PM Gerard Braad wrote: > > At what point in the instructions do you actually use the `m ip > --set-static` option? > I do not see them in the instructions / steps to reproduce. > > As in the previous email mentioned. Be sure to do: > > ``` > m start > m ip --set-static > m start --profile newthing > m ip --set-static > m profile set lastestthing > m start > m ip --set-static > ``` > > This means you can ONLY make the IP sticky after it has been > provisioned to the VM on start once. > Note: Only for Hyper-V you can provide it on startup. > > On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung wrote: > > > > Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. > > > > Regards, > > Budh Ram Gurung > > > > > > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: > >> > >> Hi Burr, > >> > >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: > >>> > >>> Here is the seriousness of the situation. I use profiles - like so > >>> minishift profile set demo1 > >>> minishift start > >>> # do some demo > >>> minishift stop > >>> minishift profile set demo2 > >>> minishift start > >>> # do some other demo > >>> minishift stop > >>> minishift profile set demo3 > >>> minishift start > >>> # yet other demo > >>> minishift stop > >>> # close laptop, drive/fly to next location, repeat the whole process > >>> > >>> Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. > >>> > >>> Caused By: > >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 > >> > >> > >> Thanks for taking time and reporting the issue. > >> We will definitely look into it and creating an upstream issue to track it. > >> > >>> > >>> the demos are basically: > >>> bit.ly/msa-instructions > >>> bit.ly/istio-tutorial > >>> bit.ly/faas-tutorial > >>> and you can not really run 2 of these in the same VM due to the 10 pods per core limit. > >>> > >>> minishift ip --set-static does not seem to make the IP "sticky". > >>> It really wants to go back to 100. It seems the IP address is not "stored" in the profile. > >>> So, this makes profiles essentially unusable. > >>> > >>> creation script: > >>> minishift profile set istio-tutorial > >>> minishift config set memory 8GB > >>> minishift config set cpus 3 > >>> minishift config set vm-driver virtualbox > >>> minishift config set image-caching true > >>> minishift addon enable admin-user > >>> minishift addon enable anyuid > >>> # minishift ip --set-static > >>> > >>> minishift start > >>> _______________________________________________ > >>> Devtools mailing list > >>> Devtools at redhat.com > >>> https://www.redhat.com/mailman/listinfo/devtools > >> > >> > >> Regards, > >> Budh Ram Gurung > > > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Tue Jul 24 14:00:48 2018 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 24 Jul 2018 09:00:48 -0500 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad wrote: > At what point in the instructions do you actually use the `m ip > --set-static` option? > Normally I use the command like so minishift profile set istio-tutorial minishift config set memory 8GB minishift config set cpus 3 minishift config set vm-driver virtualbox minishift config set image-caching true minishift addon enable admin-user minishift addon enable anyuid minishift ip --set-static minishift start and I think you are telling me to move the --set-static below the start command I do not see them in the instructions / steps to reproduce. > > As in the previous email mentioned. Be sure to do: > > ``` > m start > m ip --set-static > m start --profile newthing > m ip --set-static > m profile set lastestthing > m start > m ip --set-static > ``` > > This means you can ONLY make the IP sticky after it has been > provisioned to the VM on start once. > Note: Only for Hyper-V you can provide it on startup. > > On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung > wrote: > > > > Here is the upstream ticket > https://github.com/minishift/minishift/issues/2629. > > > > Regards, > > Budh Ram Gurung > > > > > > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung > wrote: > >> > >> Hi Burr, > >> > >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: > >>> > >>> Here is the seriousness of the situation. I use profiles - like so > >>> minishift profile set demo1 > >>> minishift start > >>> # do some demo > >>> minishift stop > >>> minishift profile set demo2 > >>> minishift start > >>> # do some other demo > >>> minishift stop > >>> minishift profile set demo3 > >>> minishift start > >>> # yet other demo > >>> minishift stop > >>> # close laptop, drive/fly to next location, repeat the whole process > >>> > >>> Yet, at the next location, I get a new IP address and the following > error. This particular VM's IP was 106, yet it reverted back to 101. > >>> > >>> Caused By: > >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: > certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, > 192.168.99.106, not 192.168.99.101 > >> > >> > >> Thanks for taking time and reporting the issue. > >> We will definitely look into it and creating an upstream issue to track > it. > >> > >>> > >>> the demos are basically: > >>> bit.ly/msa-instructions > >>> bit.ly/istio-tutorial > >>> bit.ly/faas-tutorial > >>> and you can not really run 2 of these in the same VM due to the 10 > pods per core limit. > >>> > >>> minishift ip --set-static does not seem to make the IP "sticky". > >>> It really wants to go back to 100. It seems the IP address is not > "stored" in the profile. > >>> So, this makes profiles essentially unusable. > >>> > >>> creation script: > >>> minishift profile set istio-tutorial > >>> minishift config set memory 8GB > >>> minishift config set cpus 3 > >>> minishift config set vm-driver virtualbox > >>> minishift config set image-caching true > >>> minishift addon enable admin-user > >>> minishift addon enable anyuid > >>> # minishift ip --set-static > >>> > >>> minishift start > >>> _______________________________________________ > >>> Devtools mailing list > >>> Devtools at redhat.com > >>> https://www.redhat.com/mailman/listinfo/devtools > >> > >> > >> Regards, > >> Budh Ram Gurung > > > > _______________________________________________ > > Devtools mailing list > > Devtools at redhat.com > > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Tue Jul 24 14:04:54 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 22:04:54 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Yes On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter wrote: > > > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad wrote: >> >> At what point in the instructions do you actually use the `m ip >> --set-static` option? > > > Normally I use the command like so > minishift profile set istio-tutorial > minishift config set memory 8GB > minishift config set cpus 3 > minishift config set vm-driver virtualbox > minishift config set image-caching true > minishift addon enable admin-user > minishift addon enable anyuid > minishift ip --set-static > > minishift start > > and I think you are telling me to move the --set-static below the start command > >> I do not see them in the instructions / steps to reproduce. >> >> As in the previous email mentioned. Be sure to do: >> >> ``` >> m start >> m ip --set-static >> m start --profile newthing >> m ip --set-static >> m profile set lastestthing >> m start >> m ip --set-static >> ``` >> >> This means you can ONLY make the IP sticky after it has been >> provisioned to the VM on start once. >> Note: Only for Hyper-V you can provide it on startup. >> >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung wrote: >> > >> > Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. >> > >> > Regards, >> > Budh Ram Gurung >> > >> > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: >> >> >> >> Hi Burr, >> >> >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: >> >>> >> >>> Here is the seriousness of the situation. I use profiles - like so >> >>> minishift profile set demo1 >> >>> minishift start >> >>> # do some demo >> >>> minishift stop >> >>> minishift profile set demo2 >> >>> minishift start >> >>> # do some other demo >> >>> minishift stop >> >>> minishift profile set demo3 >> >>> minishift start >> >>> # yet other demo >> >>> minishift stop >> >>> # close laptop, drive/fly to next location, repeat the whole process >> >>> >> >>> Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. >> >>> >> >>> Caused By: >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 >> >> >> >> >> >> Thanks for taking time and reporting the issue. >> >> We will definitely look into it and creating an upstream issue to track it. >> >> >> >>> >> >>> the demos are basically: >> >>> bit.ly/msa-instructions >> >>> bit.ly/istio-tutorial >> >>> bit.ly/faas-tutorial >> >>> and you can not really run 2 of these in the same VM due to the 10 pods per core limit. >> >>> >> >>> minishift ip --set-static does not seem to make the IP "sticky". >> >>> It really wants to go back to 100. It seems the IP address is not "stored" in the profile. >> >>> So, this makes profiles essentially unusable. >> >>> >> >>> creation script: >> >>> minishift profile set istio-tutorial >> >>> minishift config set memory 8GB >> >>> minishift config set cpus 3 >> >>> minishift config set vm-driver virtualbox >> >>> minishift config set image-caching true >> >>> minishift addon enable admin-user >> >>> minishift addon enable anyuid >> >>> # minishift ip --set-static >> >>> >> >>> minishift start >> >>> _______________________________________________ >> >>> Devtools mailing list >> >>> Devtools at redhat.com >> >>> https://www.redhat.com/mailman/listinfo/devtools >> >> >> >> >> >> Regards, >> >> Budh Ram Gurung >> > >> > _______________________________________________ >> > Devtools mailing list >> > Devtools at redhat.com >> > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Tue Jul 24 14:06:46 2018 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 24 Jul 2018 09:06:46 -0500 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 9:05 AM Gerard Braad wrote: > Yes > Do I need to re-run that command after every "start" or just the initial start (creation of the VM)? > On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter wrote: > > > > > > > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad wrote: > >> > >> At what point in the instructions do you actually use the `m ip > >> --set-static` option? > > > > > > Normally I use the command like so > > minishift profile set istio-tutorial > > minishift config set memory 8GB > > minishift config set cpus 3 > > minishift config set vm-driver virtualbox > > minishift config set image-caching true > > minishift addon enable admin-user > > minishift addon enable anyuid > > minishift ip --set-static > > > > minishift start > > > > and I think you are telling me to move the --set-static below the start > command > > > >> I do not see them in the instructions / steps to reproduce. > >> > >> As in the previous email mentioned. Be sure to do: > >> > >> ``` > >> m start > >> m ip --set-static > >> m start --profile newthing > >> m ip --set-static > >> m profile set lastestthing > >> m start > >> m ip --set-static > >> ``` > >> > >> This means you can ONLY make the IP sticky after it has been > >> provisioned to the VM on start once. > >> Note: Only for Hyper-V you can provide it on startup. > >> > >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung > wrote: > >> > > >> > Here is the upstream ticket > https://github.com/minishift/minishift/issues/2629. > >> > > >> > Regards, > >> > Budh Ram Gurung > >> > > >> > > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung > wrote: > >> >> > >> >> Hi Burr, > >> >> > >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter > wrote: > >> >>> > >> >>> Here is the seriousness of the situation. I use profiles - like so > >> >>> minishift profile set demo1 > >> >>> minishift start > >> >>> # do some demo > >> >>> minishift stop > >> >>> minishift profile set demo2 > >> >>> minishift start > >> >>> # do some other demo > >> >>> minishift stop > >> >>> minishift profile set demo3 > >> >>> minishift start > >> >>> # yet other demo > >> >>> minishift stop > >> >>> # close laptop, drive/fly to next location, repeat the whole process > >> >>> > >> >>> Yet, at the next location, I get a new IP address and the following > error. This particular VM's IP was 106, yet it reverted back to 101. > >> >>> > >> >>> Caused By: > >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: > certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, > 192.168.99.106, not 192.168.99.101 > >> >> > >> >> > >> >> Thanks for taking time and reporting the issue. > >> >> We will definitely look into it and creating an upstream issue to > track it. > >> >> > >> >>> > >> >>> the demos are basically: > >> >>> bit.ly/msa-instructions > >> >>> bit.ly/istio-tutorial > >> >>> bit.ly/faas-tutorial > >> >>> and you can not really run 2 of these in the same VM due to the 10 > pods per core limit. > >> >>> > >> >>> minishift ip --set-static does not seem to make the IP "sticky". > >> >>> It really wants to go back to 100. It seems the IP address is not > "stored" in the profile. > >> >>> So, this makes profiles essentially unusable. > >> >>> > >> >>> creation script: > >> >>> minishift profile set istio-tutorial > >> >>> minishift config set memory 8GB > >> >>> minishift config set cpus 3 > >> >>> minishift config set vm-driver virtualbox > >> >>> minishift config set image-caching true > >> >>> minishift addon enable admin-user > >> >>> minishift addon enable anyuid > >> >>> # minishift ip --set-static > >> >>> > >> >>> minishift start > >> >>> _______________________________________________ > >> >>> Devtools mailing list > >> >>> Devtools at redhat.com > >> >>> https://www.redhat.com/mailman/listinfo/devtools > >> >> > >> >> > >> >> Regards, > >> >> Budh Ram Gurung > >> > > >> > _______________________________________________ > >> > Devtools mailing list > >> > Devtools at redhat.com > >> > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Tue Jul 24 14:07:48 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 22:07:48 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: The option to --set-static is not applied automatically to the VM as the current implementation is not very fast. You are probably looking for a: minishift config set auto-fixed-ipaddress true option which will take affect after startup. But so far no request or demand for this came up. ... until now? On Tue, Jul 24, 2018 at 10:04 PM Gerard Braad wrote: > > Yes > On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter wrote: > > > > > > > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad wrote: > >> > >> At what point in the instructions do you actually use the `m ip > >> --set-static` option? > > > > > > Normally I use the command like so > > minishift profile set istio-tutorial > > minishift config set memory 8GB > > minishift config set cpus 3 > > minishift config set vm-driver virtualbox > > minishift config set image-caching true > > minishift addon enable admin-user > > minishift addon enable anyuid > > minishift ip --set-static > > > > minishift start > > > > and I think you are telling me to move the --set-static below the start command > > > >> I do not see them in the instructions / steps to reproduce. > >> > >> As in the previous email mentioned. Be sure to do: > >> > >> ``` > >> m start > >> m ip --set-static > >> m start --profile newthing > >> m ip --set-static > >> m profile set lastestthing > >> m start > >> m ip --set-static > >> ``` > >> > >> This means you can ONLY make the IP sticky after it has been > >> provisioned to the VM on start once. > >> Note: Only for Hyper-V you can provide it on startup. > >> > >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung wrote: > >> > > >> > Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. > >> > > >> > Regards, > >> > Budh Ram Gurung > >> > > >> > > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: > >> >> > >> >> Hi Burr, > >> >> > >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: > >> >>> > >> >>> Here is the seriousness of the situation. I use profiles - like so > >> >>> minishift profile set demo1 > >> >>> minishift start > >> >>> # do some demo > >> >>> minishift stop > >> >>> minishift profile set demo2 > >> >>> minishift start > >> >>> # do some other demo > >> >>> minishift stop > >> >>> minishift profile set demo3 > >> >>> minishift start > >> >>> # yet other demo > >> >>> minishift stop > >> >>> # close laptop, drive/fly to next location, repeat the whole process > >> >>> > >> >>> Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. > >> >>> > >> >>> Caused By: > >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 > >> >> > >> >> > >> >> Thanks for taking time and reporting the issue. > >> >> We will definitely look into it and creating an upstream issue to track it. > >> >> > >> >>> > >> >>> the demos are basically: > >> >>> bit.ly/msa-instructions > >> >>> bit.ly/istio-tutorial > >> >>> bit.ly/faas-tutorial > >> >>> and you can not really run 2 of these in the same VM due to the 10 pods per core limit. > >> >>> > >> >>> minishift ip --set-static does not seem to make the IP "sticky". > >> >>> It really wants to go back to 100. It seems the IP address is not "stored" in the profile. > >> >>> So, this makes profiles essentially unusable. > >> >>> > >> >>> creation script: > >> >>> minishift profile set istio-tutorial > >> >>> minishift config set memory 8GB > >> >>> minishift config set cpus 3 > >> >>> minishift config set vm-driver virtualbox > >> >>> minishift config set image-caching true > >> >>> minishift addon enable admin-user > >> >>> minishift addon enable anyuid > >> >>> # minishift ip --set-static > >> >>> > >> >>> minishift start > >> >>> _______________________________________________ > >> >>> Devtools mailing list > >> >>> Devtools at redhat.com > >> >>> https://www.redhat.com/mailman/listinfo/devtools > >> >> > >> >> > >> >> Regards, > >> >> Budh Ram Gurung > >> > > >> > _______________________________________________ > >> > Devtools mailing list > >> > Devtools at redhat.com > >> > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Tue Jul 24 14:15:13 2018 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 24 Jul 2018 09:15:13 -0500 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 9:08 AM Gerard Braad wrote: > The option to --set-static is not applied automatically to the VM as > the current implementation is not very fast. > > You are probably looking for a: > > minishift config set auto-fixed-ipaddress true > > option which will take affect after startup. But so far no request or > demand for this came up. > > ... until now? > Well, the key question is...do I need to re-run the command after the 2nd, 3rd, 4th "minishift start" or just the 1st minishift start? I would rather this be a "one and done" kind of command that is similar to other profile/config settings like these following 2 commands > minishift profile set faas-tutorial > minishift config set memory 10GB > I do not have to re-set those items between stop/start, they persist. > > > On Tue, Jul 24, 2018 at 10:04 PM Gerard Braad > wrote: > > > > Yes > > On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter wrote: > > > > > > > > > > > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad > wrote: > > >> > > >> At what point in the instructions do you actually use the `m ip > > >> --set-static` option? > > > > > > > > > Normally I use the command like so > > > minishift profile set istio-tutorial > > > minishift config set memory 8GB > > > minishift config set cpus 3 > > > minishift config set vm-driver virtualbox > > > minishift config set image-caching true > > > minishift addon enable admin-user > > > minishift addon enable anyuid > > > minishift ip --set-static > > > > > > minishift start > > > > > > and I think you are telling me to move the --set-static below the > start command > > > > > >> I do not see them in the instructions / steps to reproduce. > > >> > > >> As in the previous email mentioned. Be sure to do: > > >> > > >> ``` > > >> m start > > >> m ip --set-static > > >> m start --profile newthing > > >> m ip --set-static > > >> m profile set lastestthing > > >> m start > > >> m ip --set-static > > >> ``` > > >> > > >> This means you can ONLY make the IP sticky after it has been > > >> provisioned to the VM on start once. > > >> Note: Only for Hyper-V you can provide it on startup. > > >> > > >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung > wrote: > > >> > > > >> > Here is the upstream ticket > https://github.com/minishift/minishift/issues/2629. > > >> > > > >> > Regards, > > >> > Budh Ram Gurung > > >> > > > >> > > > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung > wrote: > > >> >> > > >> >> Hi Burr, > > >> >> > > >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter > wrote: > > >> >>> > > >> >>> Here is the seriousness of the situation. I use profiles - like > so > > >> >>> minishift profile set demo1 > > >> >>> minishift start > > >> >>> # do some demo > > >> >>> minishift stop > > >> >>> minishift profile set demo2 > > >> >>> minishift start > > >> >>> # do some other demo > > >> >>> minishift stop > > >> >>> minishift profile set demo3 > > >> >>> minishift start > > >> >>> # yet other demo > > >> >>> minishift stop > > >> >>> # close laptop, drive/fly to next location, repeat the whole > process > > >> >>> > > >> >>> Yet, at the next location, I get a new IP address and the > following error. This particular VM's IP was 106, yet it reverted back to > 101. > > >> >>> > > >> >>> Caused By: > > >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: > certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, > 192.168.99.106, not 192.168.99.101 > > >> >> > > >> >> > > >> >> Thanks for taking time and reporting the issue. > > >> >> We will definitely look into it and creating an upstream issue to > track it. > > >> >> > > >> >>> > > >> >>> the demos are basically: > > >> >>> bit.ly/msa-instructions > > >> >>> bit.ly/istio-tutorial > > >> >>> bit.ly/faas-tutorial > > >> >>> and you can not really run 2 of these in the same VM due to the > 10 pods per core limit. > > >> >>> > > >> >>> minishift ip --set-static does not seem to make the IP "sticky". > > >> >>> It really wants to go back to 100. It seems the IP address is > not "stored" in the profile. > > >> >>> So, this makes profiles essentially unusable. > > >> >>> > > >> >>> creation script: > > >> >>> minishift profile set istio-tutorial > > >> >>> minishift config set memory 8GB > > >> >>> minishift config set cpus 3 > > >> >>> minishift config set vm-driver virtualbox > > >> >>> minishift config set image-caching true > > >> >>> minishift addon enable admin-user > > >> >>> minishift addon enable anyuid > > >> >>> # minishift ip --set-static > > >> >>> > > >> >>> minishift start > > >> >>> _______________________________________________ > > >> >>> Devtools mailing list > > >> >>> Devtools at redhat.com > > >> >>> https://www.redhat.com/mailman/listinfo/devtools > > >> >> > > >> >> > > >> >> Regards, > > >> >> Budh Ram Gurung > > >> > > > >> > _______________________________________________ > > >> > Devtools mailing list > > >> > Devtools at redhat.com > > >> > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Tue Jul 24 14:33:57 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 22:33:57 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Only after the first/initial start After this the address is fixed and will be applied to the VM on start. It writes a configuration file into the persistent storage of the VM and this is read on start every time. On Tue, Jul 24, 2018 at 10:15 PM Burr Sutter wrote: > > > > On Tue, Jul 24, 2018 at 9:08 AM Gerard Braad wrote: >> >> The option to --set-static is not applied automatically to the VM as >> the current implementation is not very fast. >> >> You are probably looking for a: >> >> minishift config set auto-fixed-ipaddress true >> >> option which will take affect after startup. But so far no request or >> demand for this came up. >> >> ... until now? > > > Well, the key question is...do I need to re-run the command after the 2nd, 3rd, 4th "minishift start" > or just the 1st minishift start? > I would rather this be a "one and done" kind of command that is similar to other profile/config settings like these following 2 commands >> >> minishift profile set faas-tutorial >> minishift config set memory 10GB > > > I do not have to re-set those items between stop/start, they persist. > >> > >> > On Tue, Jul 24, 2018 at 10:04 PM Gerard Braad wrote: >> > >> > Yes >> > On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter wrote: >> > > >> > > >> > > >> > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad wrote: >> > >> >> > >> At what point in the instructions do you actually use the `m ip >> > >> --set-static` option? >> > > >> > > >> > > Normally I use the command like so >> > > minishift profile set istio-tutorial >> > > minishift config set memory 8GB >> > > minishift config set cpus 3 >> > > minishift config set vm-driver virtualbox >> > > minishift config set image-caching true >> > > minishift addon enable admin-user >> > > minishift addon enable anyuid >> > > minishift ip --set-static >> > > >> > > minishift start >> > > >> > > and I think you are telling me to move the --set-static below the start command >> > > >> > >> I do not see them in the instructions / steps to reproduce. >> > >> >> > >> As in the previous email mentioned. Be sure to do: >> > >> >> > >> ``` >> > >> m start >> > >> m ip --set-static >> > >> m start --profile newthing >> > >> m ip --set-static >> > >> m profile set lastestthing >> > >> m start >> > >> m ip --set-static >> > >> ``` >> > >> >> > >> This means you can ONLY make the IP sticky after it has been >> > >> provisioned to the VM on start once. >> > >> Note: Only for Hyper-V you can provide it on startup. >> > >> >> > >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung wrote: >> > >> > >> > >> > Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. >> > >> > >> > >> > Regards, >> > >> > Budh Ram Gurung >> > >> > >> > >> > >> > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: >> > >> >> >> > >> >> Hi Burr, >> > >> >> >> > >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: >> > >> >>> >> > >> >>> Here is the seriousness of the situation. I use profiles - like so >> > >> >>> minishift profile set demo1 >> > >> >>> minishift start >> > >> >>> # do some demo >> > >> >>> minishift stop >> > >> >>> minishift profile set demo2 >> > >> >>> minishift start >> > >> >>> # do some other demo >> > >> >>> minishift stop >> > >> >>> minishift profile set demo3 >> > >> >>> minishift start >> > >> >>> # yet other demo >> > >> >>> minishift stop >> > >> >>> # close laptop, drive/fly to next location, repeat the whole process >> > >> >>> >> > >> >>> Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. >> > >> >>> >> > >> >>> Caused By: >> > >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 >> > >> >> >> > >> >> >> > >> >> Thanks for taking time and reporting the issue. >> > >> >> We will definitely look into it and creating an upstream issue to track it. >> > >> >> >> > >> >>> >> > >> >>> the demos are basically: >> > >> >>> bit.ly/msa-instructions >> > >> >>> bit.ly/istio-tutorial >> > >> >>> bit.ly/faas-tutorial >> > >> >>> and you can not really run 2 of these in the same VM due to the 10 pods per core limit. >> > >> >>> >> > >> >>> minishift ip --set-static does not seem to make the IP "sticky". >> > >> >>> It really wants to go back to 100. It seems the IP address is not "stored" in the profile. >> > >> >>> So, this makes profiles essentially unusable. >> > >> >>> >> > >> >>> creation script: >> > >> >>> minishift profile set istio-tutorial >> > >> >>> minishift config set memory 8GB >> > >> >>> minishift config set cpus 3 >> > >> >>> minishift config set vm-driver virtualbox >> > >> >>> minishift config set image-caching true >> > >> >>> minishift addon enable admin-user >> > >> >>> minishift addon enable anyuid >> > >> >>> # minishift ip --set-static >> > >> >>> >> > >> >>> minishift start >> > >> >>> _______________________________________________ >> > >> >>> Devtools mailing list >> > >> >>> Devtools at redhat.com >> > >> >>> https://www.redhat.com/mailman/listinfo/devtools >> > >> >> >> > >> >> >> > >> >> Regards, >> > >> >> Budh Ram Gurung >> > >> > >> > >> > _______________________________________________ >> > >> > Devtools mailing list >> > >> > Devtools at redhat.com >> > >> > https://www.redhat.com/mailman/listinfo/devtools From gbraad at redhat.com Tue Jul 24 14:35:42 2018 From: gbraad at redhat.com (Gerard Braad) Date: Tue, 24 Jul 2018 22:35:42 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: > > minishift profile set faas-tutorial > > minishift config set memory 10GB > I do not have to re-set those items between stop/start, they persist. These configuraions are different as they determine how the VM is setup. Note: these can not all be changed after start (like dfisk-size). As mentioned, only on Hyper-V we can set the IP address before the VM starts On Tue, Jul 24, 2018 at 10:33 PM Gerard Braad wrote: > > Only after the first/initial start After this the address is fixed and > will be applied to the VM on start. > It writes a configuration file into the persistent storage of the VM > and this is read on start every time. > > On Tue, Jul 24, 2018 at 10:15 PM Burr Sutter wrote: > > > > > > > > On Tue, Jul 24, 2018 at 9:08 AM Gerard Braad wrote: > >> > >> The option to --set-static is not applied automatically to the VM as > >> the current implementation is not very fast. > >> > >> You are probably looking for a: > >> > >> minishift config set auto-fixed-ipaddress true > >> > >> option which will take affect after startup. But so far no request or > >> demand for this came up. > >> > >> ... until now? > > > > > > Well, the key question is...do I need to re-run the command after the 2nd, 3rd, 4th "minishift start" > > or just the 1st minishift start? > > I would rather this be a "one and done" kind of command that is similar to other profile/config settings like these following 2 commands > >> > >> minishift profile set faas-tutorial > >> minishift config set memory 10GB > > > > > > I do not have to re-set those items between stop/start, they persist. > > > >> > > >> > On Tue, Jul 24, 2018 at 10:04 PM Gerard Braad wrote: > >> > > >> > Yes > >> > On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter wrote: > >> > > > >> > > > >> > > > >> > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad wrote: > >> > >> > >> > >> At what point in the instructions do you actually use the `m ip > >> > >> --set-static` option? > >> > > > >> > > > >> > > Normally I use the command like so > >> > > minishift profile set istio-tutorial > >> > > minishift config set memory 8GB > >> > > minishift config set cpus 3 > >> > > minishift config set vm-driver virtualbox > >> > > minishift config set image-caching true > >> > > minishift addon enable admin-user > >> > > minishift addon enable anyuid > >> > > minishift ip --set-static > >> > > > >> > > minishift start > >> > > > >> > > and I think you are telling me to move the --set-static below the start command > >> > > > >> > >> I do not see them in the instructions / steps to reproduce. > >> > >> > >> > >> As in the previous email mentioned. Be sure to do: > >> > >> > >> > >> ``` > >> > >> m start > >> > >> m ip --set-static > >> > >> m start --profile newthing > >> > >> m ip --set-static > >> > >> m profile set lastestthing > >> > >> m start > >> > >> m ip --set-static > >> > >> ``` > >> > >> > >> > >> This means you can ONLY make the IP sticky after it has been > >> > >> provisioned to the VM on start once. > >> > >> Note: Only for Hyper-V you can provide it on startup. > >> > >> > >> > >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung wrote: > >> > >> > > >> > >> > Here is the upstream ticket https://github.com/minishift/minishift/issues/2629. > >> > >> > > >> > >> > Regards, > >> > >> > Budh Ram Gurung > >> > >> > > >> > >> > > >> > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung wrote: > >> > >> >> > >> > >> >> Hi Burr, > >> > >> >> > >> > >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter wrote: > >> > >> >>> > >> > >> >>> Here is the seriousness of the situation. I use profiles - like so > >> > >> >>> minishift profile set demo1 > >> > >> >>> minishift start > >> > >> >>> # do some demo > >> > >> >>> minishift stop > >> > >> >>> minishift profile set demo2 > >> > >> >>> minishift start > >> > >> >>> # do some other demo > >> > >> >>> minishift stop > >> > >> >>> minishift profile set demo3 > >> > >> >>> minishift start > >> > >> >>> # yet other demo > >> > >> >>> minishift stop > >> > >> >>> # close laptop, drive/fly to next location, repeat the whole process > >> > >> >>> > >> > >> >>> Yet, at the next location, I get a new IP address and the following error. This particular VM's IP was 106, yet it reverted back to 101. > >> > >> >>> > >> > >> >>> Caused By: > >> > >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, 192.168.99.106, not 192.168.99.101 > >> > >> >> > >> > >> >> > >> > >> >> Thanks for taking time and reporting the issue. > >> > >> >> We will definitely look into it and creating an upstream issue to track it. > >> > >> >> > >> > >> >>> > >> > >> >>> the demos are basically: > >> > >> >>> bit.ly/msa-instructions > >> > >> >>> bit.ly/istio-tutorial > >> > >> >>> bit.ly/faas-tutorial > >> > >> >>> and you can not really run 2 of these in the same VM due to the 10 pods per core limit. > >> > >> >>> > >> > >> >>> minishift ip --set-static does not seem to make the IP "sticky". > >> > >> >>> It really wants to go back to 100. It seems the IP address is not "stored" in the profile. > >> > >> >>> So, this makes profiles essentially unusable. > >> > >> >>> > >> > >> >>> creation script: > >> > >> >>> minishift profile set istio-tutorial > >> > >> >>> minishift config set memory 8GB > >> > >> >>> minishift config set cpus 3 > >> > >> >>> minishift config set vm-driver virtualbox > >> > >> >>> minishift config set image-caching true > >> > >> >>> minishift addon enable admin-user > >> > >> >>> minishift addon enable anyuid > >> > >> >>> # minishift ip --set-static > >> > >> >>> > >> > >> >>> minishift start > >> > >> >>> _______________________________________________ > >> > >> >>> Devtools mailing list > >> > >> >>> Devtools at redhat.com > >> > >> >>> https://www.redhat.com/mailman/listinfo/devtools > >> > >> >> > >> > >> >> > >> > >> >> Regards, > >> > >> >> Budh Ram Gurung > >> > >> > > >> > >> > _______________________________________________ > >> > >> > Devtools mailing list > >> > >> > Devtools at redhat.com > >> > >> > https://www.redhat.com/mailman/listinfo/devtools From jmaury at redhat.com Tue Jul 24 16:19:56 2018 From: jmaury at redhat.com (Jean-Francois Maury) Date: Tue, 24 Jul 2018 18:19:56 +0200 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Found a way to get rid of the pods-per-core limit: after the VM has been created and static ip assigned, do the following: minishift ssh vi /var/lib/minishift/openshift.local.config/node-localhost/node-config.yaml under the kubeletArguments node, add the following: pods-per-core: - "100" Save and restart the VM. The node will now have a 200 pods limit Using this setting, I was able to create a 40 pods nodejs deployment where I could not exceed 17 pods with the default settings. On Tue, Jul 24, 2018 at 4:56 PM Gerard Braad wrote: > > > minishift profile set faas-tutorial > > > minishift config set memory 10GB > > I do not have to re-set those items between stop/start, they persist. > > These configuraions are different as they determine how the VM is > setup. Note: these can not all be changed after start (like > dfisk-size). > > As mentioned, only on Hyper-V we can set the IP address before the VM > starts > On Tue, Jul 24, 2018 at 10:33 PM Gerard Braad wrote: > > > > Only after the first/initial start After this the address is fixed and > > will be applied to the VM on start. > > It writes a configuration file into the persistent storage of the VM > > and this is read on start every time. > > > > On Tue, Jul 24, 2018 at 10:15 PM Burr Sutter wrote: > > > > > > > > > > > > On Tue, Jul 24, 2018 at 9:08 AM Gerard Braad > wrote: > > >> > > >> The option to --set-static is not applied automatically to the VM as > > >> the current implementation is not very fast. > > >> > > >> You are probably looking for a: > > >> > > >> minishift config set auto-fixed-ipaddress true > > >> > > >> option which will take affect after startup. But so far no request or > > >> demand for this came up. > > >> > > >> ... until now? > > > > > > > > > Well, the key question is...do I need to re-run the command after the > 2nd, 3rd, 4th "minishift start" > > > or just the 1st minishift start? > > > I would rather this be a "one and done" kind of command that is > similar to other profile/config settings like these following 2 commands > > >> > > >> minishift profile set faas-tutorial > > >> minishift config set memory 10GB > > > > > > > > > I do not have to re-set those items between stop/start, they persist. > > > > > >> > > > >> > On Tue, Jul 24, 2018 at 10:04 PM Gerard Braad > wrote: > > >> > > > >> > Yes > > >> > On Tue, Jul 24, 2018 at 10:01 PM Burr Sutter > wrote: > > >> > > > > >> > > > > >> > > > > >> > > On Tue, Jul 24, 2018 at 8:53 AM Gerard Braad > wrote: > > >> > >> > > >> > >> At what point in the instructions do you actually use the `m ip > > >> > >> --set-static` option? > > >> > > > > >> > > > > >> > > Normally I use the command like so > > >> > > minishift profile set istio-tutorial > > >> > > minishift config set memory 8GB > > >> > > minishift config set cpus 3 > > >> > > minishift config set vm-driver virtualbox > > >> > > minishift config set image-caching true > > >> > > minishift addon enable admin-user > > >> > > minishift addon enable anyuid > > >> > > minishift ip --set-static > > >> > > > > >> > > minishift start > > >> > > > > >> > > and I think you are telling me to move the --set-static below the > start command > > >> > > > > >> > >> I do not see them in the instructions / steps to reproduce. > > >> > >> > > >> > >> As in the previous email mentioned. Be sure to do: > > >> > >> > > >> > >> ``` > > >> > >> m start > > >> > >> m ip --set-static > > >> > >> m start --profile newthing > > >> > >> m ip --set-static > > >> > >> m profile set lastestthing > > >> > >> m start > > >> > >> m ip --set-static > > >> > >> ``` > > >> > >> > > >> > >> This means you can ONLY make the IP sticky after it has been > > >> > >> provisioned to the VM on start once. > > >> > >> Note: Only for Hyper-V you can provide it on startup. > > >> > >> > > >> > >> On Tue, Jul 24, 2018 at 9:47 PM Budh Ram Gurung < > bgurung at redhat.com> wrote: > > >> > >> > > > >> > >> > Here is the upstream ticket > https://github.com/minishift/minishift/issues/2629. > > >> > >> > > > >> > >> > Regards, > > >> > >> > Budh Ram Gurung > > >> > >> > > > >> > >> > > > >> > >> > On Tue, Jul 24, 2018 at 7:02 PM Budh Ram Gurung < > bgurung at redhat.com> wrote: > > >> > >> >> > > >> > >> >> Hi Burr, > > >> > >> >> > > >> > >> >> On Tue, Jul 24, 2018 at 6:50 PM Burr Sutter < > bsutter at redhat.com> wrote: > > >> > >> >>> > > >> > >> >>> Here is the seriousness of the situation. I use profiles - > like so > > >> > >> >>> minishift profile set demo1 > > >> > >> >>> minishift start > > >> > >> >>> # do some demo > > >> > >> >>> minishift stop > > >> > >> >>> minishift profile set demo2 > > >> > >> >>> minishift start > > >> > >> >>> # do some other demo > > >> > >> >>> minishift stop > > >> > >> >>> minishift profile set demo3 > > >> > >> >>> minishift start > > >> > >> >>> # yet other demo > > >> > >> >>> minishift stop > > >> > >> >>> # close laptop, drive/fly to next location, repeat the whole > process > > >> > >> >>> > > >> > >> >>> Yet, at the next location, I get a new IP address and the > following error. This particular VM's IP was 106, yet it reverted back to > 101. > > >> > >> >>> > > >> > >> >>> Caused By: > > >> > >> >>> Error: Get https://192.168.99.101:8443/healthz/ready: x509: > certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.0.1, 172.30.0.1, > 192.168.99.106, not 192.168.99.101 > > >> > >> >> > > >> > >> >> > > >> > >> >> Thanks for taking time and reporting the issue. > > >> > >> >> We will definitely look into it and creating an upstream > issue to track it. > > >> > >> >> > > >> > >> >>> > > >> > >> >>> the demos are basically: > > >> > >> >>> bit.ly/msa-instructions > > >> > >> >>> bit.ly/istio-tutorial > > >> > >> >>> bit.ly/faas-tutorial > > >> > >> >>> and you can not really run 2 of these in the same VM due to > the 10 pods per core limit. > > >> > >> >>> > > >> > >> >>> minishift ip --set-static does not seem to make the IP > "sticky". > > >> > >> >>> It really wants to go back to 100. It seems the IP address > is not "stored" in the profile. > > >> > >> >>> So, this makes profiles essentially unusable. > > >> > >> >>> > > >> > >> >>> creation script: > > >> > >> >>> minishift profile set istio-tutorial > > >> > >> >>> minishift config set memory 8GB > > >> > >> >>> minishift config set cpus 3 > > >> > >> >>> minishift config set vm-driver virtualbox > > >> > >> >>> minishift config set image-caching true > > >> > >> >>> minishift addon enable admin-user > > >> > >> >>> minishift addon enable anyuid > > >> > >> >>> # minishift ip --set-static > > >> > >> >>> > > >> > >> >>> minishift start > > >> > >> >>> _______________________________________________ > > >> > >> >>> Devtools mailing list > > >> > >> >>> Devtools at redhat.com > > >> > >> >>> https://www.redhat.com/mailman/listinfo/devtools > > >> > >> >> > > >> > >> >> > > >> > >> >> Regards, > > >> > >> >> Budh Ram Gurung > > >> > >> > > > >> > >> > _______________________________________________ > > >> > >> > 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 > -- JEFF MAURY Red Hat jmaury at redhat.com @redhatjobs redhatjobs @redhatjobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Tue Jul 24 17:59:55 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 24 Jul 2018 23:29:55 +0530 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad wrote: > Only after the first/initial start After this the address is fixed and > will be applied to the VM on start. > It writes a configuration file into the persistent storage of the VM > and this is read on start every time. > > Hi Burr, I have a question for you. When we implemented "--set-static" feature we had the question around whether --set-static should be part of "minishift start" or "minishift ip". There were arguments for both the sides. This was one of the reason we kept this feature as experimental. When a feature is experimental we look for user feedback and then we can make changes without keeping backward compatibility. As Gerard mentioned we need existing Minishift instance to run minishift ip --set-static and you just need to run it once during the first start. If you run it without the instance then you will get below error $ minishift ip --set-static Error getting IP: Docker machine "minishift" does not exist. Use "docker-machine ls" to list machines. Use "docker-machine create" to add a new one. We have an issue [1] to improve the error message, but it is clear that it needs a running instance. Now my question is, what you think would be a better user experience "minishift start --set-static" or "minishift ip --set-static" or something else. Also upstream Minishift has a mailing list [2]. I would request you to use that as we do not consider devtools at redhat.com as our upstream mailing list. [1] https://github.com/minishift/minishift/issues/2163 [2] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ Thanks, Lala -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Tue Jul 24 19:10:01 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 25 Jul 2018 00:40:01 +0530 Subject: [Devtools] minishift offline In-Reply-To: References: Message-ID: On Sat, Jul 21, 2018 at 8:37 PM, Burr Sutter wrote: > I do not know if we have the "how to go offline with minishift" but here > is my basic process. > > 1. minishift start > minishift profile set 9StepsAwesome > minishift config set memory 12GB > minishift config set cpus 3 > minishift config set vm-driver virtualbox > minishift config set disk-size 30g > minishift config set image-caching true > minishift addon enable admin-user > minishift addon enable anyuid > minishift ip --set-static > minishift start > minishift ip --set-static needs to be run after "minishift start" 2. load up everything you normally need like the Istio Tutorial, Helloworld > MSA, doing whatever "docker build" that needs to happen, etc. > 3. echo 'Current Cache' > minishift image cache-config view > 4. echo 'Docker images inside of VM' > minishift image list --vm > 5. echo 'Export those' > minishift image export --all > 6. echo 'Configure the cache of those images' > minishift image cache-config add docker.io/fabric8/java-jboss- > openjdk8-jdk:1.3.1 > minishift image cache-config add docker.io/istio/citadel:0.8.0 > minishift image cache-config add docker.io/istio/grafana:0.8.0 > minishift image cache-config add docker.io/istio/mixer:0.8.0 > minishift image cache-config add docker.io/istio/pilot:0.8.0 > minishift image cache-config add docker.io/istio/proxy_init:0.8.0 > minishift image cache-config add docker.io/istio/proxyv2:0.8.0 > minishift image cache-config add docker.io/istio/servicegraph:0.8.0 > minishift image cache-config add docker.io/istio/sidecar_injector:0.8.0 > minishift image cache-config add docker.io/jaegertracing/all-in-one:1.5 > minishift image cache-config add docker.io/jaegertracing/all-in-one:latest > minishift image cache-config add docker.io/openshift/origin- > deployer:v3.9.0 > minishift image cache-config add docker.io/openshift/origin- > docker-registry:v3.9.0 > minishift image cache-config add docker.io/openshift/origin- > haproxy-router:v3.9.0 > minishift image cache-config add docker.io/openshift/origin-pod:v3.9.0 > minishift image cache-config add docker.io/openshift/origin- > web-console:v3.9.0 > minishift image cache-config add docker.io/openshift/origin:v3.9.0 > minishift image cache-config add docker.io/prom/prometheus:latest > minishift image cache-config add docker.io/prom/statsd-exporter:latest > minishift image cache-config add quay.io/coreos/hyperkube:v1.7.6_coreos.0 > > You do not need to run cache-config add for docker.io/openshift/origin * containers as Minishift takes care of it implicitly. What you want is to pin a particular OpenShift version in the config e.g. minishift config set openshift-version . You can get the version from "minishift openshift version list". FYI, upstream Minishift has a mailing list [1]. I would request you to use that as we do not consider devtools at redhat.com as our upstream mailing list. [1] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ > 7. minishift stop > 8. minishift delete > 9. repeat step #1 > 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 bsutter at redhat.com Wed Jul 25 16:07:45 2018 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 25 Jul 2018 11:07:45 -0500 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty wrote: > On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad wrote: > >> Only after the first/initial start After this the address is fixed and >> will be applied to the VM on start. >> It writes a configuration file into the persistent storage of the VM >> and this is read on start every time. >> >> > Hi Burr, > > I have a question for you. When we implemented "--set-static" feature we > had the question around whether --set-static should be part of "minishift > start" or "minishift ip". There were arguments for both the sides. This > was one of the reason we kept this feature as experimental. When a feature > is experimental we look for user feedback and then we can make changes > without keeping backward compatibility. > > As Gerard mentioned we need existing Minishift instance to run minishift > ip --set-static and you just need to run it once during the first start. > > If you run it without the instance then you will get below error > > $ minishift ip --set-static > Error getting IP: Docker machine "minishift" does not exist. Use > "docker-machine ls" to list machines. Use "docker-machine create" to add a > new one. > > We have an issue [1] to improve the error message, but it is clear that it > needs a running instance. > > Now my question is, what you think would be a better user experience > "minishift start --set-static" or "minishift ip --set-static" or something > else. > I like the proposal of using the config ?setstaticip? that gets applied after start. Also, one big gotcha is that subsequent minishift starts on NEW VMs will go able to .100, which might ?overlay? a previously created VM. This gives you an error in the new Vm and the old one. This just happened to me as I am scrambling to get the demo up for customers today. > > Also upstream Minishift has a mailing list [2]. I would request you to use > that as we do not consider devtools at redhat.com as our upstream mailing > list. > > [1] https://github.com/minishift/minishift/issues/2163 > > [2] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ > > Thanks, > Lala > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmohanty at redhat.com Wed Jul 25 16:44:44 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Wed, 25 Jul 2018 22:14:44 +0530 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Wed, Jul 25, 2018 at 9:37 PM, Burr Sutter wrote: > > > On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty > wrote: > >> On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad wrote: >> >>> Only after the first/initial start After this the address is fixed and >>> will be applied to the VM on start. >>> It writes a configuration file into the persistent storage of the VM >>> and this is read on start every time. >>> >>> >> Hi Burr, >> >> I have a question for you. When we implemented "--set-static" feature >> we had the question around whether --set-static should be part of >> "minishift start" or "minishift ip". There were arguments for both the >> sides. This was one of the reason we kept this feature as experimental. >> When a feature is experimental we look for user feedback and then we can >> make changes without keeping backward compatibility. >> >> As Gerard mentioned we need existing Minishift instance to run minishift >> ip --set-static and you just need to run it once during the first start. >> >> If you run it without the instance then you will get below error >> >> $ minishift ip --set-static >> Error getting IP: Docker machine "minishift" does not exist. Use >> "docker-machine ls" to list machines. Use "docker-machine create" to add a >> new one. >> >> We have an issue [1] to improve the error message, but it is clear that >> it needs a running instance. >> >> Now my question is, what you think would be a better user experience >> "minishift start --set-static" or "minishift ip --set-static" or something >> else. >> > > > I like the proposal of using the config ?setstaticip? that gets applied > after start. > > Also, one big gotcha is that subsequent minishift starts on NEW VMs will > go able to .100, which might ?overlay? a previously created VM. This gives > you an error in the new Vm and the old one. This just happened to me as I > am scrambling to get the demo up for customers today. > The IP allocation part is handled by the hypervisor software. Minishift can not do much about it. When a VM starts it asks the hypervisor to give a free IP. If you have VM in shutdown/stop state for long hypervisor considers the the previous allocated IP is free after certain time, hence the issue. > >> >> Also upstream Minishift has a mailing list [2]. I would request you to >> use that as we do not consider devtools at redhat.com as our upstream >> mailing list. >> >> [1] https://github.com/minishift/minishift/issues/2163 >> >> [2] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ >> >> Thanks, >> Lala >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Wed Jul 25 20:34:52 2018 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 25 Jul 2018 15:34:52 -0500 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Wed, Jul 25, 2018 at 11:44 AM Lalatendu Mohanty wrote: > > > On Wed, Jul 25, 2018 at 9:37 PM, Burr Sutter wrote: > >> >> >> On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty >> wrote: >> >>> On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad wrote: >>> >>>> Only after the first/initial start After this the address is fixed and >>>> will be applied to the VM on start. >>>> It writes a configuration file into the persistent storage of the VM >>>> and this is read on start every time. >>>> >>>> >>> Hi Burr, >>> >>> I have a question for you. When we implemented "--set-static" feature >>> we had the question around whether --set-static should be part of >>> "minishift start" or "minishift ip". There were arguments for both the >>> sides. This was one of the reason we kept this feature as experimental. >>> When a feature is experimental we look for user feedback and then we can >>> make changes without keeping backward compatibility. >>> >>> As Gerard mentioned we need existing Minishift instance to run minishift >>> ip --set-static and you just need to run it once during the first start. >>> >>> If you run it without the instance then you will get below error >>> >>> $ minishift ip --set-static >>> Error getting IP: Docker machine "minishift" does not exist. Use >>> "docker-machine ls" to list machines. Use "docker-machine create" to add a >>> new one. >>> >>> We have an issue [1] to improve the error message, but it is clear that >>> it needs a running instance. >>> >>> Now my question is, what you think would be a better user experience >>> "minishift start --set-static" or "minishift ip --set-static" or something >>> else. >>> >> >> >> I like the proposal of using the config ?setstaticip? that gets applied >> after start. >> >> Also, one big gotcha is that subsequent minishift starts on NEW VMs will >> go able to .100, which might ?overlay? a previously created VM. This gives >> you an error in the new Vm and the old one. This just happened to me as I >> am scrambling to get the demo up for customers today. >> > > > The IP allocation part is handled by the hypervisor software. Minishift > can not do much about it. When a VM starts it asks the hypervisor to give > a free IP. If you have VM in shutdown/stop state for long hypervisor > considers the the previous allocated IP is free after certain time, hence > the issue. > > We need some smarts in minishift to at least realize it is being allocated an IP again. It seems to be a very common occurrence, in short time intervals (minutes) if you are changing wifi access points minishift stop close laptop move open laptop connect to a new wifi minishift start > >> >>> >>> Also upstream Minishift has a mailing list [2]. I would request you to >>> use that as we do not consider devtools at redhat.com as our upstream >>> mailing list. >>> >>> [1] https://github.com/minishift/minishift/issues/2163 >>> >>> [2] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ >>> >>> Thanks, >>> Lala >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Thu Jul 26 02:04:45 2018 From: gbraad at redhat.com (Gerard Braad) Date: Thu, 26 Jul 2018 10:04:45 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Hi Burr, And this is why there is an option `m ip --set-static` as it sets the same IP forced onto the network interface. but the smart solution is also not to rely on a bridged network option here, as you can never predict what the IP range of the 'new wifi' is. Or avoid all of this and set up your own VM using a static address, maybe using vagrant or using the Hypervisor management interface, tweak the settings from the console to use the network rc scripts, etc. and then provision OpenShift using the Remote/Exisitng VM feature of minishift (the generic driver) => https://docs.openshift.org/latest/minishift/using/run-against-an-existing-machine.html Our hands are tied when it comes to IP assignment, as these are controlled by the hypervisor. The way the docker machine library interacts with these hypervisors prevents us from doing very fancy stuff. It is a known limitation, for which we already have a better solution than minikube ATM. What are you missing? regards, Gerard On Thu, Jul 26, 2018 at 4:35 AM Burr Sutter wrote: > > > > On Wed, Jul 25, 2018 at 11:44 AM Lalatendu Mohanty wrote: >> >> >> >> On Wed, Jul 25, 2018 at 9:37 PM, Burr Sutter wrote: >>> >>> >>> >>> On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty wrote: >>>> >>>> On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad wrote: >>>>> >>>>> Only after the first/initial start After this the address is fixed and >>>>> will be applied to the VM on start. >>>>> It writes a configuration file into the persistent storage of the VM >>>>> and this is read on start every time. >>>>> >>>> >>>> Hi Burr, >>>> >>>> I have a question for you. When we implemented "--set-static" feature we had the question around whether --set-static should be part of "minishift start" or "minishift ip". There were arguments for both the sides. This was one of the reason we kept this feature as experimental. When a feature is experimental we look for user feedback and then we can make changes without keeping backward compatibility. >>>> >>>> As Gerard mentioned we need existing Minishift instance to run minishift ip --set-static and you just need to run it once during the first start. >>>> >>>> If you run it without the instance then you will get below error >>>> >>>> $ minishift ip --set-static >>>> Error getting IP: Docker machine "minishift" does not exist. Use "docker-machine ls" to list machines. Use "docker-machine create" to add a new one. >>>> >>>> We have an issue [1] to improve the error message, but it is clear that it needs a running instance. >>>> >>>> Now my question is, what you think would be a better user experience "minishift start --set-static" or "minishift ip --set-static" or something else. >>> >>> >>> >>> I like the proposal of using the config ?setstaticip? that gets applied after start. >>> >>> Also, one big gotcha is that subsequent minishift starts on NEW VMs will go able to .100, which might ?overlay? a previously created VM. This gives you an error in the new Vm and the old one. This just happened to me as I am scrambling to get the demo up for customers today. >> >> >> >> The IP allocation part is handled by the hypervisor software. Minishift can not do much about it. When a VM starts it asks the hypervisor to give a free IP. If you have VM in shutdown/stop state for long hypervisor considers the the previous allocated IP is free after certain time, hence the issue. >> > > We need some smarts in minishift to at least realize it is being allocated an IP again. It seems to be a very common occurrence, in short time intervals (minutes) if you are changing wifi access points > > minishift stop > close laptop > move > open laptop > connect to a new wifi > minishift start > > >>> >>> >>>> >>>> >>>> Also upstream Minishift has a mailing list [2]. I would request you to use that as we do not consider devtools at redhat.com as our upstream mailing list. >>>> >>>> [1] https://github.com/minishift/minishift/issues/2163 >>>> >>>> [2] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ >>>> >>>> Thanks, >>>> Lala >> >> From bsutter at redhat.com Thu Jul 26 20:30:21 2018 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 26 Jul 2018 15:30:21 -0500 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: On Wed, Jul 25, 2018 at 9:04 PM Gerard Braad wrote: > Hi Burr, > > And this is why there is an option `m ip --set-static` as it sets the > same IP forced onto the network interface. > but the smart solution is also not to rely on a bridged network option > here, as you can never predict what the IP range of the 'new wifi' is. > > Or avoid all of this and set up your own VM using a static address, > maybe using vagrant or using the Hypervisor management interface, > tweak the settings from the console to use the network rc scripts, > etc. and then provision OpenShift using the Remote/Exisitng VM feature > of minishift (the generic driver) => > > https://docs.openshift.org/latest/minishift/using/run-against-an-existing-machine.html > > Our hands are tied when it comes to IP assignment, as these are > controlled by the hypervisor. The way the docker machine library > interacts with these hypervisors prevents us from doing very fancy > stuff. It is a known limitation, for which we already have a better > solution than minikube ATM. > > What are you missing? > > I do not know right the solution my use case is: open laptop minishift start do a demo minishift stop minishift profile set nextdemo minishift start do the nextdemo minishift stop (I dislike keeping the VM running when the laptop sleeps) close the laptop move to next location open laptop repeat I basically run 3 main demos/scripts A: bit.ly/msa-instructions B: bit.ly/istio-tutorial C: bit.ly/faas-tutorial For this week, I ran A & C on my laptop while Christian ran B on his. We are working to make OpenShift installable on public cloud VMs, therefore we would not have to worry about the laptop/minishift having issues with changing networks - but it does mean you have to have internet connectivity (and sometimes you do not). > regards, > > > Gerard > On Thu, Jul 26, 2018 at 4:35 AM Burr Sutter wrote: > > > > > > > > On Wed, Jul 25, 2018 at 11:44 AM Lalatendu Mohanty > wrote: > >> > >> > >> > >> On Wed, Jul 25, 2018 at 9:37 PM, Burr Sutter > wrote: > >>> > >>> > >>> > >>> On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty < > lmohanty at redhat.com> wrote: > >>>> > >>>> On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad > wrote: > >>>>> > >>>>> Only after the first/initial start After this the address is fixed > and > >>>>> will be applied to the VM on start. > >>>>> It writes a configuration file into the persistent storage of the VM > >>>>> and this is read on start every time. > >>>>> > >>>> > >>>> Hi Burr, > >>>> > >>>> I have a question for you. When we implemented "--set-static" > feature we had the question around whether --set-static should be part of > "minishift start" or "minishift ip". There were arguments for both the > sides. This was one of the reason we kept this feature as experimental. > When a feature is experimental we look for user feedback and then we can > make changes without keeping backward compatibility. > >>>> > >>>> As Gerard mentioned we need existing Minishift instance to run > minishift ip --set-static and you just need to run it once during the > first start. > >>>> > >>>> If you run it without the instance then you will get below error > >>>> > >>>> $ minishift ip --set-static > >>>> Error getting IP: Docker machine "minishift" does not exist. Use > "docker-machine ls" to list machines. Use "docker-machine create" to add a > new one. > >>>> > >>>> We have an issue [1] to improve the error message, but it is clear > that it needs a running instance. > >>>> > >>>> Now my question is, what you think would be a better user experience > "minishift start --set-static" or "minishift ip --set-static" or something > else. > >>> > >>> > >>> > >>> I like the proposal of using the config ?setstaticip? that gets > applied after start. > >>> > >>> Also, one big gotcha is that subsequent minishift starts on NEW VMs > will go able to .100, which might ?overlay? a previously created VM. This > gives you an error in the new Vm and the old one. This just happened to me > as I am scrambling to get the demo up for customers today. > >> > >> > >> > >> The IP allocation part is handled by the hypervisor software. Minishift > can not do much about it. When a VM starts it asks the hypervisor to give > a free IP. If you have VM in shutdown/stop state for long hypervisor > considers the the previous allocated IP is free after certain time, hence > the issue. > >> > > > > We need some smarts in minishift to at least realize it is being > allocated an IP again. It seems to be a very common occurrence, in short > time intervals (minutes) if you are changing wifi access points > > > > minishift stop > > close laptop > > move > > open laptop > > connect to a new wifi > > minishift start > > > > > >>> > >>> > >>>> > >>>> > >>>> Also upstream Minishift has a mailing list [2]. I would request you > to use that as we do not consider devtools at redhat.com as our upstream > mailing list. > >>>> > >>>> [1] https://github.com/minishift/minishift/issues/2163 > >>>> > >>>> [2] > https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ > >>>> > >>>> Thanks, > >>>> Lala > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Fri Jul 27 05:43:44 2018 From: gbraad at redhat.com (Gerard Braad) Date: Fri, 27 Jul 2018 13:43:44 +0800 Subject: [Devtools] must solve this minishift IP problem In-Reply-To: References: Message-ID: Can you test something for us: open laptop minishift start *minishift ip --set-static* do a demo minishift stop minishift profile set nextdemo minishift start *minishift ip --set-static* do the nextdemo minishift stop (I dislike keeping the VM running when the laptop sleeps) close the laptop move to next location open laptop repeat Each time you would move back to the previous demo, can you check with *minishift ip* if the IP is still the same? I understand that sleeping is not a good idea; as this also leeds to clock skews for xhyve which affect SSL/TLS. Would really like to know if the Fixed IP option works for you. On Fri, Jul 27, 2018 at 4:30 AM Burr Sutter wrote: > > > On Wed, Jul 25, 2018 at 9:04 PM Gerard Braad wrote: > >> Hi Burr, >> >> And this is why there is an option `m ip --set-static` as it sets the >> same IP forced onto the network interface. >> but the smart solution is also not to rely on a bridged network option >> here, as you can never predict what the IP range of the 'new wifi' is. >> >> Or avoid all of this and set up your own VM using a static address, >> maybe using vagrant or using the Hypervisor management interface, >> tweak the settings from the console to use the network rc scripts, >> etc. and then provision OpenShift using the Remote/Exisitng VM feature >> of minishift (the generic driver) => >> >> https://docs.openshift.org/latest/minishift/using/run-against-an-existing-machine.html >> >> Our hands are tied when it comes to IP assignment, as these are >> controlled by the hypervisor. The way the docker machine library >> interacts with these hypervisors prevents us from doing very fancy >> stuff. It is a known limitation, for which we already have a better >> solution than minikube ATM. >> >> What are you missing? >> >> > I do not know right the solution > > my use case is: > open laptop > minishift start > do a demo > minishift stop > minishift profile set nextdemo > minishift start > do the nextdemo > minishift stop (I dislike keeping the VM running when the laptop sleeps) > close the laptop > move to next location > open laptop > repeat > > I basically run 3 main demos/scripts > A: bit.ly/msa-instructions > B: bit.ly/istio-tutorial > C: bit.ly/faas-tutorial > For this week, I ran A & C on my laptop while Christian ran B on his. > > We are working to make OpenShift installable on public cloud VMs, > therefore we would not have to worry about the laptop/minishift having > issues with changing networks - but it does mean you have to have internet > connectivity (and sometimes you do not). > > > > > >> regards, >> >> >> Gerard >> On Thu, Jul 26, 2018 at 4:35 AM Burr Sutter wrote: >> > >> > >> > >> > On Wed, Jul 25, 2018 at 11:44 AM Lalatendu Mohanty >> wrote: >> >> >> >> >> >> >> >> On Wed, Jul 25, 2018 at 9:37 PM, Burr Sutter >> wrote: >> >>> >> >>> >> >>> >> >>> On Tue, Jul 24, 2018 at 12:59 PM Lalatendu Mohanty < >> lmohanty at redhat.com> wrote: >> >>>> >> >>>> On Tue, Jul 24, 2018 at 8:03 PM, Gerard Braad >> wrote: >> >>>>> >> >>>>> Only after the first/initial start After this the address is fixed >> and >> >>>>> will be applied to the VM on start. >> >>>>> It writes a configuration file into the persistent storage of the VM >> >>>>> and this is read on start every time. >> >>>>> >> >>>> >> >>>> Hi Burr, >> >>>> >> >>>> I have a question for you. When we implemented "--set-static" >> feature we had the question around whether --set-static should be part of >> "minishift start" or "minishift ip". There were arguments for both the >> sides. This was one of the reason we kept this feature as experimental. >> When a feature is experimental we look for user feedback and then we can >> make changes without keeping backward compatibility. >> >>>> >> >>>> As Gerard mentioned we need existing Minishift instance to run >> minishift ip --set-static and you just need to run it once during the >> first start. >> >>>> >> >>>> If you run it without the instance then you will get below error >> >>>> >> >>>> $ minishift ip --set-static >> >>>> Error getting IP: Docker machine "minishift" does not exist. Use >> "docker-machine ls" to list machines. Use "docker-machine create" to add a >> new one. >> >>>> >> >>>> We have an issue [1] to improve the error message, but it is clear >> that it needs a running instance. >> >>>> >> >>>> Now my question is, what you think would be a better user experience >> "minishift start --set-static" or "minishift ip --set-static" or something >> else. >> >>> >> >>> >> >>> >> >>> I like the proposal of using the config ?setstaticip? that gets >> applied after start. >> >>> >> >>> Also, one big gotcha is that subsequent minishift starts on NEW VMs >> will go able to .100, which might ?overlay? a previously created VM. This >> gives you an error in the new Vm and the old one. This just happened to me >> as I am scrambling to get the demo up for customers today. >> >> >> >> >> >> >> >> The IP allocation part is handled by the hypervisor software. >> Minishift can not do much about it. When a VM starts it asks the >> hypervisor to give a free IP. If you have VM in shutdown/stop state for >> long hypervisor considers the the previous allocated IP is free after >> certain time, hence the issue. >> >> >> > >> > We need some smarts in minishift to at least realize it is being >> allocated an IP again. It seems to be a very common occurrence, in short >> time intervals (minutes) if you are changing wifi access points >> > >> > minishift stop >> > close laptop >> > move >> > open laptop >> > connect to a new wifi >> > minishift start >> > >> > >> >>> >> >>> >> >>>> >> >>>> >> >>>> Also upstream Minishift has a mailing list [2]. I would request you >> to use that as we do not consider devtools at redhat.com as our upstream >> mailing list. >> >>>> >> >>>> [1] https://github.com/minishift/minishift/issues/2163 >> >>>> >> >>>> [2] >> https://lists.minishift.io/admin/lists/minishift.lists.minishift.io/ >> >>>> >> >>>> Thanks, >> >>>> Lala >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Sat Jul 28 16:21:45 2018 From: bsutter at redhat.com (Burr Sutter) Date: Sat, 28 Jul 2018 12:21:45 -0400 Subject: [Devtools] racing toward the next round of presentations Message-ID: I saw about 200 users this week, but they were primarily "real customers" since it was organized by our sales team - aka high quality "leads". Next, the first whole week of August, my guess is that we will see another 200 to 300 "real customers" (sales team organized) but I also have about 400 off-the-street folks (organized by O'rielly Safari [1]). This later batch of people need me to be much more "kubernetes upstream friendly", so I have a few questions along those lines. Which version of Minikube matches Minishift? https://github.com/kubernetes/minikube/releases https://github.com/minishift/minishift/releases Is there an easy way (or documented way) to match these up? Ideally, my demos/labs are fully portable between minikube and minishift. [1] https://www.safaribooksonline.com/live-training/courses/9-steps-to-awesome-with-kubernetes/0636920196099/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at redhat.com Mon Jul 30 02:06:54 2018 From: gbraad at redhat.com (Gerard Braad) Date: Mon, 30 Jul 2018 10:06:54 +0800 Subject: [Devtools] racing toward the next round of presentations In-Reply-To: References: Message-ID: Hi Burr, About monthly we try to sync up with them and exchange issues we share and discuss possible solutions. We try to align with Minikube feature-wise, but at the moment we have no bandwidth to handle porting changes back. Portability between our implementations is not the biggest problem, as long as you can guarantee an application deploys on both kubernetes and openshift in the same way. If we put effort into this, would you be able to show a demo that we could use as a base line for this attempt? It would also help if you create an issue for us to discuss and track progress and issues along the way. Especially as it allows us to refer to issues/and questions at Minikube's end too. Gerard On Sun, Jul 29, 2018 at 12:22 AM Burr Sutter wrote: > I saw about 200 users this week, but they were primarily "real customers" > since it was organized by our sales team - aka high quality "leads". > > Next, the first whole week of August, my guess is that we will see another > 200 to 300 "real customers" (sales team organized) but I also have about > 400 off-the-street folks (organized by O'rielly Safari [1]). > > This later batch of people need me to be much more "kubernetes upstream > friendly", so I have a few questions along those lines. > > Which version of Minikube matches Minishift? > https://github.com/kubernetes/minikube/releases > https://github.com/minishift/minishift/releases > Is there an easy way (or documented way) to match these up? > > Ideally, my demos/labs are fully portable between minikube and minishift. > > [1] > https://www.safaribooksonline.com/live-training/courses/9-steps-to-awesome-with-kubernetes/0636920196099/ > > > > _______________________________________________ > 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 Mon Jul 30 06:57:15 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 30 Jul 2018 12:27:15 +0530 Subject: [Devtools] racing toward the next round of presentations In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 7:36 AM, Gerard Braad wrote: > Hi Burr, > > > About monthly we try to sync up with them and exchange issues we share and > discuss possible solutions. > We try to align with Minikube feature-wise, but at the moment we have no > bandwidth to handle porting changes back. > Portability between our implementations is not the biggest problem, as > long as you can guarantee an application deploys on both kubernetes and > openshift in the same way. > > If we put effort into this, would you be able to show a demo that we could > use as a base line for this attempt? > It would also help if you create an issue for us to discuss and track > progress and issues along the way. > Especially as it allows us to refer to issues/and questions at Minikube's > end too. > > > Gerard > > On Sun, Jul 29, 2018 at 12:22 AM Burr Sutter wrote: > >> I saw about 200 users this week, but they were primarily "real customers" >> since it was organized by our sales team - aka high quality "leads". >> >> Next, the first whole week of August, my guess is that we will see >> another 200 to 300 "real customers" (sales team organized) but I also have >> about 400 off-the-street folks (organized by O'rielly Safari [1]). >> >> This later batch of people need me to be much more "kubernetes upstream >> friendly", so I have a few questions along those lines. >> >> Which version of Minikube matches Minishift? >> > I just check Minikube 0.28.2 and if we compare major features Minishift vs Minikube, Minishift has all the features of Minikube and some more. However there is difference in the way these features are implemented. > https://github.com/kubernetes/minikube/releases >> https://github.com/minishift/minishift/releases >> Is there an easy way (or documented way) to match these up? >> > We never documented this. Personally I feel Minikube is not maintained properly and some of its features are half baked. Do you need an comparative writeup? >> Ideally, my demos/labs are fully portable between minikube and minishift. >> >> [1] https://www.safaribooksonline.com/live-training/courses/9-steps-to- >> awesome-with-kubernetes/0636920196099/ >> >> >> >> _______________________________________________ >> 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 Mon Jul 30 15:12:35 2018 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 30 Jul 2018 11:12:35 -0400 Subject: [Devtools] racing toward the next round of presentations In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 2:57 AM Lalatendu Mohanty wrote: > > > On Mon, Jul 30, 2018 at 7:36 AM, Gerard Braad wrote: > >> Hi Burr, >> >> >> About monthly we try to sync up with them and exchange issues we share >> and discuss possible solutions. >> We try to align with Minikube feature-wise, but at the moment we have no >> bandwidth to handle porting changes back. >> Portability between our implementations is not the biggest problem, as >> long as you can guarantee an application deploys on both kubernetes and >> openshift in the same way. >> >> > If we put effort into this, would you be able to show a demo that we could >> use as a base line for this attempt? >> It would also help if you create an issue for us to discuss and track >> progress and issues along the way. >> Especially as it allows us to refer to issues/and questions at Minikube's >> end too. >> >> >> Gerard >> >> On Sun, Jul 29, 2018 at 12:22 AM Burr Sutter wrote: >> >>> I saw about 200 users this week, but they were primarily "real >>> customers" since it was organized by our sales team - aka high quality >>> "leads". >>> >>> Next, the first whole week of August, my guess is that we will see >>> another 200 to 300 "real customers" (sales team organized) but I also have >>> about 400 off-the-street folks (organized by O'rielly Safari [1]). >>> >>> This later batch of people need me to be much more "kubernetes upstream >>> friendly", so I have a few questions along those lines. >>> >>> Which version of Minikube matches Minishift? >>> >> > > I just check Minikube 0.28.2 and if we compare major features Minishift vs > Minikube, Minishift has all the features of Minikube and some more. However > there is difference in the way these features are implemented. > I started working with minikube 0.28.1 - I wanted Kubernetes 1.10 and guessed it might be the right one I have now also seen a feature mismatch - like "minikube profile list" and "minikube profile set myprofile" does not seem to work. > > >> https://github.com/kubernetes/minikube/releases >>> https://github.com/minishift/minishift/releases >>> Is there an easy way (or documented way) to match these up? >>> >> > We never documented this. Personally I feel Minikube is not maintained > properly and some of its features are half baked. Do you need an > comparative writeup? > Yes and No :-) I think the task is pretty simple. On the both "releases" pages, it should indicate what version of Kubernetes/Openshift it is bringing along by default - this will then allow the user to pick the right version of kubectl as well. I do like how minikube's releases page offers "how to install" docs. By the way, I like telling people that minikube is the upstream to minishift much like Kubernetes is the upstream to OpenShift and kubectl is to oc. I am not sure if the minikube team has download numbers but I am betting they have seen a dramatic growth over the last 12 months as numerous 3rd parties are starting to offer "training" on Kubernetes via minikube. > > >>> Ideally, my demos/labs are fully portable between minikube and >>> minishift. >>> >>> [1] >>> https://www.safaribooksonline.com/live-training/courses/9-steps-to-awesome-with-kubernetes/0636920196099/ >>> >>> >>> >>> _______________________________________________ >>> 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 lmohanty at redhat.com Mon Jul 30 19:18:16 2018 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Tue, 31 Jul 2018 00:48:16 +0530 Subject: [Devtools] racing toward the next round of presentations In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 8:42 PM, Burr Sutter wrote: > > > On Mon, Jul 30, 2018 at 2:57 AM Lalatendu Mohanty > wrote: > >> >> >> On Mon, Jul 30, 2018 at 7:36 AM, Gerard Braad wrote: >> >>> Hi Burr, >>> >>> >>> About monthly we try to sync up with them and exchange issues we share >>> and discuss possible solutions. >>> We try to align with Minikube feature-wise, but at the moment we have no >>> bandwidth to handle porting changes back. >>> Portability between our implementations is not the biggest problem, as >>> long as you can guarantee an application deploys on both kubernetes and >>> openshift in the same way. >>> >>> >> If we put effort into this, would you be able to show a demo that we >>> could use as a base line for this attempt? >>> It would also help if you create an issue for us to discuss and track >>> progress and issues along the way. >>> Especially as it allows us to refer to issues/and questions at >>> Minikube's end too. >>> >>> >>> Gerard >>> >>> On Sun, Jul 29, 2018 at 12:22 AM Burr Sutter wrote: >>> >>>> I saw about 200 users this week, but they were primarily "real >>>> customers" since it was organized by our sales team - aka high quality >>>> "leads". >>>> >>>> Next, the first whole week of August, my guess is that we will see >>>> another 200 to 300 "real customers" (sales team organized) but I also have >>>> about 400 off-the-street folks (organized by O'rielly Safari [1]). >>>> >>>> This later batch of people need me to be much more "kubernetes upstream >>>> friendly", so I have a few questions along those lines. >>>> >>>> Which version of Minikube matches Minishift? >>>> >>> >> >> I just check Minikube 0.28.2 and if we compare major features Minishift >> vs Minikube, Minishift has all the features of Minikube and some more. >> However there is difference in the way these features are implemented. >> > > I started working with minikube 0.28.1 - I wanted Kubernetes 1.10 and > guessed it might be the right one > > I have now also seen a feature mismatch - like "minikube profile list" and > "minikube profile set myprofile" does not seem to work. > Because Minikube has some half baked features. If we want to have same features implemented in Minikube then it wont be copy pasting code but we need to spend considerable amount of work for this. They do not share the same code base now. Question: When you use Minikube and Minishift do you feel they are equally polished or one is better than the other? > > >> >> >>> https://github.com/kubernetes/minikube/releases >>>> https://github.com/minishift/minishift/releases >>>> Is there an easy way (or documented way) to match these up? >>>> >>> >> We never documented this. Personally I feel Minikube is not maintained >> properly and some of its features are half baked. Do you need an >> comparative writeup? >> > > Yes and No :-) > > I think the task is pretty simple. On the both "releases" pages, it > should indicate what version of Kubernetes/Openshift it is bringing along > by default - this will then allow the user to pick the right version of > kubectl as well. > > I do like how minikube's releases page offers "how to install" docs. > > By the way, I like telling people that minikube is the upstream to > minishift > much like Kubernetes is the upstream to OpenShift > and kubectl is to oc. > Minikube is not upstream to Minishift. The code base has diverged and it can not be converged now. The code has diverged because we have different mechanism to provision Kubernetes vs OpenShift. We have gone back and forth on this. We do not see any value from code point of view if we make Minikube as our upstream. From marketing point of view there might be value as you mentioned but for us it would be double work. > I am not sure if the minikube team has download numbers but I am betting > they have seen a dramatic growth over the last 12 months as numerous 3rd > parties are starting to offer "training" on Kubernetes via minikube. > Yes, they get higher numbers than Minishift because Kubernetes has a bigger community i.e. higher download numbers are not because Minikube is awesome. Please correct me if I am wrong. If you want to benefited from Minikube community then we should add code in Minikube to provision OpenShift (not the default but if user wants) , but then user gets confused around what to use for OpenShift. IMO both should not co-exist. May be it is time we should take another look what we can do to address this issue. -Lala > >> >> >>>> Ideally, my demos/labs are fully portable between minikube and >>>> minishift. >>>> >>>> [1] https://www.safaribooksonline.com/live-training/courses/9-steps-to- >>>> awesome-with-kubernetes/0636920196099/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Tue Jul 31 14:11:45 2018 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 31 Jul 2018 10:11:45 -0400 Subject: [Devtools] racing toward the next round of presentations In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 3:18 PM Lalatendu Mohanty wrote: > > > On Mon, Jul 30, 2018 at 8:42 PM, Burr Sutter wrote: > >> >> >> On Mon, Jul 30, 2018 at 2:57 AM Lalatendu Mohanty >> wrote: >> >>> >>> >>> On Mon, Jul 30, 2018 at 7:36 AM, Gerard Braad wrote: >>> >>>> Hi Burr, >>>> >>>> >>>> About monthly we try to sync up with them and exchange issues we share >>>> and discuss possible solutions. >>>> We try to align with Minikube feature-wise, but at the moment we have >>>> no bandwidth to handle porting changes back. >>>> Portability between our implementations is not the biggest problem, as >>>> long as you can guarantee an application deploys on both kubernetes and >>>> openshift in the same way. >>>> >>>> >>> If we put effort into this, would you be able to show a demo that we >>>> could use as a base line for this attempt? >>>> It would also help if you create an issue for us to discuss and track >>>> progress and issues along the way. >>>> Especially as it allows us to refer to issues/and questions at >>>> Minikube's end too. >>>> >>>> >>>> Gerard >>>> >>>> On Sun, Jul 29, 2018 at 12:22 AM Burr Sutter >>>> wrote: >>>> >>>>> I saw about 200 users this week, but they were primarily "real >>>>> customers" since it was organized by our sales team - aka high quality >>>>> "leads". >>>>> >>>>> Next, the first whole week of August, my guess is that we will see >>>>> another 200 to 300 "real customers" (sales team organized) but I also have >>>>> about 400 off-the-street folks (organized by O'rielly Safari [1]). >>>>> >>>>> This later batch of people need me to be much more "kubernetes >>>>> upstream friendly", so I have a few questions along those lines. >>>>> >>>>> Which version of Minikube matches Minishift? >>>>> >>>> >>> >>> I just check Minikube 0.28.2 and if we compare major features Minishift >>> vs Minikube, Minishift has all the features of Minikube and some more. >>> However there is difference in the way these features are implemented. >>> >> >> I started working with minikube 0.28.1 - I wanted Kubernetes 1.10 and >> guessed it might be the right one >> >> I have now also seen a feature mismatch - like "minikube profile list" >> and "minikube profile set myprofile" does not seem to work. >> > > Because Minikube has some half baked features. If we want to have same > features implemented in Minikube then it wont be copy pasting code but we > need to spend considerable amount of work for this. They do not share the > same code base now. > > Question: When you use Minikube and Minishift do you feel they are equally > polished or one is better than the other? > I find them to be fairly equal except for: - minikube start up is a LOT faster - minikube profiles are not worth using - not sure what the equivalent of "oc project" is in "kubectl" - what namespace am I in? - minishift addon enable admin-user is unique otherwise, they feel basically the same so far. I have not yet completed my demo scripts, perhaps I will run across something else that feels different. the first "demo script" (or lab) is about done here: https://github.com/burrsutter/9stepsawesome/blob/master/1_installation_ready.adoc > >> >>> >>> >>>> https://github.com/kubernetes/minikube/releases >>>>> https://github.com/minishift/minishift/releases >>>>> Is there an easy way (or documented way) to match these up? >>>>> >>>> >>> We never documented this. Personally I feel Minikube is not maintained >>> properly and some of its features are half baked. Do you need an >>> comparative writeup? >>> >> >> Yes and No :-) >> >> I think the task is pretty simple. On the both "releases" pages, it >> should indicate what version of Kubernetes/Openshift it is bringing along >> by default - this will then allow the user to pick the right version of >> kubectl as well. >> >> I do like how minikube's releases page offers "how to install" docs. >> >> By the way, I like telling people that minikube is the upstream to >> minishift >> much like Kubernetes is the upstream to OpenShift >> and kubectl is to oc. >> > > Minikube is not upstream to Minishift. The code base has diverged and it > can not be converged now. The code has diverged because we have different > mechanism to provision Kubernetes vs OpenShift. > > We have gone back and forth on this. We do not see any value from code > point of view if we make Minikube as our upstream. From marketing point of > view there might be value as you mentioned but for us it would be double > work. > > >> I am not sure if the minikube team has download numbers but I am betting >> they have seen a dramatic growth over the last 12 months as numerous 3rd >> parties are starting to offer "training" on Kubernetes via minikube. >> > > Yes, they get higher numbers than Minishift because Kubernetes has a > bigger community i.e. higher download numbers are not because Minikube is > awesome. Please correct me if I am wrong. > > > If you want to benefited from Minikube community then we should add code > in Minikube to provision OpenShift (not the default but if user wants) , > but then user gets confused around what to use for OpenShift. IMO both > should not co-exist. > > May be it is time we should take another look what we can do to address > this issue. > > -Lala > > >> >>> >>> >>>>> Ideally, my demos/labs are fully portable between minikube and >>>>> minishift. >>>>> >>>>> [1] >>>>> https://www.safaribooksonline.com/live-training/courses/9-steps-to-awesome-with-kubernetes/0636920196099/ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: