From bsutter at redhat.com Fri Dec 1 19:32:44 2017 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 1 Dec 2017 14:32:44 -0500 Subject: [Devtools] Metrics on Minishift Message-ID: I have a customer wanted to know when Metrics on Minishift will work I have been trying the following without success MINISHIFT_ENABLE_EXPERIMENTAL=y minishift start --profile minishift-1.9.0_2 --metrics --cpus 3 --memory 8192 --vm-driver virtualbox --openshift-version v3.7.0-rc.0 minishift v1.9.0+a511b25 I do see An error occurred getting metrics. Open Metrics URL | Don't Show Me Again and when I Open Metrics URL I get Application not available Application is not available The application is currently not serving requests at this endpoint. It may not have been started or is still starting. Possible reasons you are seeing this page: - *The host doesn't exist.* Make sure the hostname was typed correctly and that a route matching this hostname exists. - *The host exists, but doesn't have a matching path.* Check if the URL path was typed correctly and that the route was created using the desired path. - *Route and path matches, but all pods are down.* Make sure that the resources exposed by this route (pods, services, deployment configs, etc) have at least one pod running. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Mon Dec 11 13:17:56 2017 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 11 Dec 2017 08:17:56 -0500 Subject: [Devtools] Great podcast: Kelsey vs John :-) Message-ID: http://devopscafe.org/show/2017/6/18/devops-cafe-episode-72-kelsey-hightower.html If you do not know about this podcast...well, take your Christmas break and listen to about 40 hours worth of content - the vast majority is amazing. In this particular example, John (now an ex-Docker guy) talks about the value of Docker Compose and Kelsey slams it. Here is the 'big idea': Kelsey continues to make the point that Kubernetes is not a PaaS and that a this kind of declarative solution must target a PaaS. My interpretation is that a specific customer must first put all the "sub-components" into their own custom "catalog" and the declarative composition crafted by the developer must make selections from that "catalog". There are just too many details that Kubernetes, nor a vendor can choose up front. Kelsey rattles of a ton of them related to Redis like not just storage but replication & clustering configuration, backup configuration, sharing configuration, security, etc, etc. All of those details should be established by a particular customer's IT folks and then a developer can declarative just say "i want a Redis for my app". Hopefully that makes sense. Because I am now fairly certain this is the right way to go :-) Burr -------------- next part -------------- An HTML attachment was scrubbed... URL: From gercan at redhat.com Mon Dec 11 13:53:33 2017 From: gercan at redhat.com (Gorkem Ercan) Date: Mon, 11 Dec 2017 08:53:33 -0500 Subject: [Devtools] Great podcast: Kelsey vs John :-) In-Reply-To: References: Message-ID: <5EEED407-210A-4495-B831-06C75162F1CD@redhat.com> On 11 Dec 2017, at 8:17, Burr Sutter wrote: > http://devopscafe.org/show/2017/6/18/devops-cafe-episode-72-kelsey-hightower.html > > If you do not know about this podcast...well, take your Christmas > break and > listen to about 40 hours worth of content - the vast majority is > amazing. > > In this particular example, John (now an ex-Docker guy) talks about > the > value of Docker Compose and Kelsey slams it. > > Here is the 'big idea': > Kelsey continues to make the point that Kubernetes is not a PaaS and > that a > this kind of declarative solution must target a PaaS. My > interpretation is > that a specific customer must first put all the "sub-components" into > their > own custom "catalog" and the declarative composition crafted by the > developer must make selections from that "catalog". There are just > too > many details that Kubernetes, nor a vendor can choose up front. > Kelsey > rattles of a ton of them related to Redis like not just storage but > replication & clustering configuration, backup configuration, sharing > configuration, security, etc, etc. All of those details should be > established by a particular customer's IT folks and then a developer > can > declarative just say "i want a Redis for my app". > This is the direction that I was looking at for Che. In addition to subcomponents the metadata also needs to include the relationships between those components. Nowadays running a lonely container does not mean much. > Hopefully that makes sense. > > Because I am now fairly certain this is the right way to go :-) > > Burr > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From bsutter at redhat.com Mon Dec 11 15:30:26 2017 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 11 Dec 2017 10:30:26 -0500 Subject: [Devtools] Great podcast: Kelsey vs John :-) In-Reply-To: <5EEED407-210A-4495-B831-06C75162F1CD@redhat.com> References: <5EEED407-210A-4495-B831-06C75162F1CD@redhat.com> Message-ID: On Mon, Dec 11, 2017 at 8:53 AM, Gorkem Ercan wrote: > > > On 11 Dec 2017, at 8:17, Burr Sutter wrote: > > http://devopscafe.org/show/2017/6/18/devops-cafe-episode-72- >> kelsey-hightower.html >> >> If you do not know about this podcast...well, take your Christmas break >> and >> listen to about 40 hours worth of content - the vast majority is amazing. >> >> In this particular example, John (now an ex-Docker guy) talks about the >> value of Docker Compose and Kelsey slams it. >> >> Here is the 'big idea': >> Kelsey continues to make the point that Kubernetes is not a PaaS and that >> a >> this kind of declarative solution must target a PaaS. My interpretation >> is >> that a specific customer must first put all the "sub-components" into >> their >> own custom "catalog" and the declarative composition crafted by the >> developer must make selections from that "catalog". There are just too >> many details that Kubernetes, nor a vendor can choose up front. Kelsey >> rattles of a ton of them related to Redis like not just storage but >> replication & clustering configuration, backup configuration, sharing >> configuration, security, etc, etc. All of those details should be >> established by a particular customer's IT folks and then a developer can >> declarative just say "i want a Redis for my app". >> >> > This is the direction that I was looking at for Che. In addition to > subcomponents the metadata > also needs to include the relationships between those components. Nowadays > running a lonely > container does not mean much. > > Like Microservices and unlike Highlander - there can never be only one! good point on the relationships - if my Redis service needs underlying storage then at ACME corp, we use XYZ storage configured like so, the end-user (aka developer) need only answer a few questions. > > Hopefully that makes sense. >> >> Because I am now fairly certain this is the right way to go :-) >> >> Burr >> > > > _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkral at redhat.com Mon Dec 11 16:13:34 2017 From: tkral at redhat.com (Tomas Kral) Date: Mon, 11 Dec 2017 17:13:34 +0100 Subject: [Devtools] Great podcast: Kelsey vs John :-) In-Reply-To: References: <5EEED407-210A-4495-B831-06C75162F1CD@redhat.com> Message-ID: On Mon, Dec 11, 2017 at 4:30 PM, Burr Sutter wrote: > > > On Mon, Dec 11, 2017 at 8:53 AM, Gorkem Ercan wrote: > >> >> >> On 11 Dec 2017, at 8:17, Burr Sutter wrote: >> >> http://devopscafe.org/show/2017/6/18/devops-cafe-episode-72- >>> kelsey-hightower.html >>> >>> If you do not know about this podcast...well, take your Christmas break >>> and >>> listen to about 40 hours worth of content - the vast majority is amazing. >>> >>> In this particular example, John (now an ex-Docker guy) talks about the >>> value of Docker Compose and Kelsey slams it. >>> >>> Here is the 'big idea': >>> Kelsey continues to make the point that Kubernetes is not a PaaS and >>> that a >>> this kind of declarative solution must target a PaaS. My interpretation >>> is >>> that a specific customer must first put all the "sub-components" into >>> their >>> own custom "catalog" and the declarative composition crafted by the >>> developer must make selections from that "catalog". There are just too >>> many details that Kubernetes, nor a vendor can choose up front. Kelsey >>> rattles of a ton of them related to Redis like not just storage but >>> replication & clustering configuration, backup configuration, sharing >>> configuration, security, etc, etc. All of those details should be >>> established by a particular customer's IT folks and then a developer can >>> declarative just say "i want a Redis for my app". >>> >>> >> This is the direction that I was looking at for Che. In addition to >> subcomponents the metadata >> also needs to include the relationships between those components. >> Nowadays running a lonely >> container does not mean much. >> >> > Like Microservices and unlike Highlander - there can never be only one! > > good point on the relationships - if my Redis service needs underlying > storage then at ACME corp, we use XYZ storage configured like so, the > end-user (aka developer) need only answer a few questions. > This is what we are trying to do with Kedge. You would use Kedge to define just your application. For other standard services like databases that your app requires your would use Service Catalog or Helm. You just define relationship to those services in your Kedge file. This is still in the idea phase, but it is something that we have on roadmap. > > >> >> Hopefully that makes sense. >>> >>> Because I am now fairly certain this is the right way to go :-) >>> >>> Burr >>> >> >> >> _______________________________________________ >>> 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 manderse at redhat.com Mon Dec 11 22:15:19 2017 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 11 Dec 2017 23:15:19 +0100 Subject: [Devtools] Great podcast: Kelsey vs John :-) In-Reply-To: References: <5EEED407-210A-4495-B831-06C75162F1CD@redhat.com> Message-ID: just to add to the ideas ... neither kedge nor che will actually be able to nor would want to have the full picture. devs would probably often want to only work with a subset of services and some probably with a mix of "mocks" or staged services... dev teams will need a lot of skins for this cat. /max http://about.me/maxandersen On 11 Dec 2017, at 17:13, Tomas Kral wrote: > On Mon, Dec 11, 2017 at 4:30 PM, Burr Sutter > wrote: > >> >> >> On Mon, Dec 11, 2017 at 8:53 AM, Gorkem Ercan >> wrote: >> >>> >>> >>> On 11 Dec 2017, at 8:17, Burr Sutter wrote: >>> >>> http://devopscafe.org/show/2017/6/18/devops-cafe-episode-72- >>>> kelsey-hightower.html >>>> >>>> If you do not know about this podcast...well, take your Christmas >>>> break >>>> and >>>> listen to about 40 hours worth of content - the vast majority is >>>> amazing. >>>> >>>> In this particular example, John (now an ex-Docker guy) talks about >>>> the >>>> value of Docker Compose and Kelsey slams it. >>>> >>>> Here is the 'big idea': >>>> Kelsey continues to make the point that Kubernetes is not a PaaS >>>> and >>>> that a >>>> this kind of declarative solution must target a PaaS. My >>>> interpretation >>>> is >>>> that a specific customer must first put all the "sub-components" >>>> into >>>> their >>>> own custom "catalog" and the declarative composition crafted by the >>>> developer must make selections from that "catalog". There are >>>> just too >>>> many details that Kubernetes, nor a vendor can choose up front. >>>> Kelsey >>>> rattles of a ton of them related to Redis like not just storage but >>>> replication & clustering configuration, backup configuration, >>>> sharing >>>> configuration, security, etc, etc. All of those details should be >>>> established by a particular customer's IT folks and then a >>>> developer can >>>> declarative just say "i want a Redis for my app". >>>> >>>> >>> This is the direction that I was looking at for Che. In addition to >>> subcomponents the metadata >>> also needs to include the relationships between those components. >>> Nowadays running a lonely >>> container does not mean much. >>> >>> >> Like Microservices and unlike Highlander - there can never be only >> one! >> >> good point on the relationships - if my Redis service needs >> underlying >> storage then at ACME corp, we use XYZ storage configured like so, the >> end-user (aka developer) need only answer a few questions. >> > > This is what we are trying to do with Kedge. You would use Kedge to > define > just your application. For other standard services like databases that > your > app requires your would use Service Catalog or Helm. > You just define relationship to those services in your Kedge file. > > This is still in the idea phase, but it is something that we have on > roadmap. > > > >> >> >>> >>> Hopefully that makes sense. >>>> >>>> Because I am now fairly certain this is the right way to go :-) >>>> >>>> Burr >>>> >>> >>> >>> _______________________________________________ >>>> Devtools mailing list >>>> Devtools at redhat.com >>>> https://www.redhat.com/mailman/listinfo/devtools >>>> >>> >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: