Date   

Re: CF Application Runtime PMC: CLI Project Lead Call for Nominations

Eric Malm
 

Hi, everyone,
 
VMware is nominating Zach Robinson for the CLI Project Lead in the Application Runtime PMC.
 
Zach has worked at Pivotal and VMware as a core contributor to Cloud Foundry since 2013, most recently as the lead for the CAPI project team in the App Runtime PMC and as a product manager focused on the CF app-developer experience. Over the years, he has worked with the CF Services, Runtime, CAPI, and CLI teams including anchoring Runtime and PMing CAPI, with contributions to many Cloud Foundry components. His previous experience includes over 10 years of engineering, primarily in the financial sector.
 
Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, February 10, 2020.
 
Thanks,
Eric Malm


CF Application Runtime PMC: CLI Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Abby Chau, the lead for the CLI project within the Application Runtime PMC, has stepped down from the project. We thank her for her service.

The CLI team, located in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, February 10, 2020.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead


Re: CF app that helps with self-healing

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

To me this seems a lot like a health check.  Is there some reason that you couldn't add a health check endpoint to your app instances (either directly, or as a sidecar) and then let CF take care of restarting the app instances for you?


From: cf-dev@... <cf-dev@...> on behalf of Siva <mailsiva@...>
Sent: Monday, January 27, 2020 11:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] CF app that helps with self-healing
 

[EXTERNAL EMAIL]

Thanks Daniel J and Daniel M for your inputs.
Troy - We are also thinking something along those lines to see of we can use the App Autoscaler for the restarts.

-Siva

On Mon, Jan 27, 2020 at 10:05 AM Troy Topnik <troy.topnik@...> wrote:
Ideally you'd want to trace the application misbehavior to a root cause in the application itself, but I think we've all been in the situation where "turn it off and on again" is an easier solution. :)

I wonder if this could be a feature request for App-AutoScaler? It already has access to the metric types required for the operation, but it would need to be able to take a policy action based on those metrics other than scaling up or down (e.g. "adjustment" : "restart" ).

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 



--


Re: CF app that helps with self-healing

Siva <mailsiva@...>
 

Thanks Daniel J and Daniel M for your inputs.
Troy - We are also thinking something along those lines to see of we can use the App Autoscaler for the restarts.

-Siva


On Mon, Jan 27, 2020 at 10:05 AM Troy Topnik <troy.topnik@...> wrote:
Ideally you'd want to trace the application misbehavior to a root cause in the application itself, but I think we've all been in the situation where "turn it off and on again" is an easier solution. :)

I wonder if this could be a feature request for App-AutoScaler? It already has access to the metric types required for the operation, but it would need to be able to take a policy action based on those metrics other than scaling up or down (e.g. "adjustment" : "restart" ).

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 



Re: CF app that helps with self-healing

Troy Topnik
 

Ideally you'd want to trace the application misbehavior to a root cause in the application itself, but I think we've all been in the situation where "turn it off and on again" is an easier solution. :)

I wonder if this could be a feature request for App-AutoScaler? It already has access to the metric types required for the operation, but it would need to be able to take a policy action based on those metrics other than scaling up or down (e.g. "adjustment" : "restart" ).

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 


Re: CF app that helps with self-healing

Daniel Mikusa
 



On Fri, Jan 24, 2020 at 5:28 PM Siva <mailsiva@...> wrote:
Hi Daniel,
Thanks for your response.
I am aware of all the options you are suggesting. But what we are looking for is a process to restart an app instance without human intervention from an alert policy in our monitoring system. This monitoring system is outside of CF and does not have access to CF CLI. But it can access REST endpoints.

The cf cli is just a glorified rest client. If you can access the cloud controller API for your foundation, you can do everything I mentioned w/out the cf cli & by using raw rest commands.


+1 to everything Daniel Jones said in his response.

Hope that helps!

Dan

 
For eg - The monitoring system will detect a high CPU utilization on one of the app instance. It will raise an alert which will trigger a policy that will call a REST endpoint of this self healing app. Based on the parameters passed in the request, the self-healing app will restart the requested app instance.
This is required when the app does not know that it is in a bad state but some metrics we are tracking are indicating that the app instance need to be restarted.
Hope that makes sense.

Thanks
Siva

On Fri, Jan 24, 2020 at 9:55 AM Daniel Mikusa <dmikusa@...> wrote:
Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan



--


Re: CF app that helps with self-healing

Daniel Jones
 

Hi Siva,

I'm not aware of a similar solution that already exists. A couple of thoughts:
  • Could you use HTTP healthchecks, and have the endpoint return a non-200 status code if the app detects high CPU usage itself?
  • Be mindful of how CPU usage is reported. Whilst current containerisation tech can limit how many CPU shares a process gets, it can't control the system calls that report how much CPU is available. Hence things like `top` will appear inaccurate, and you should ensure the CPU usage statistics come from the metrics that feed into the cpu-entitlement-plugin. If you want to double-check this, there's a blog post (https://www.cloudfoundry.org/blog/better-way-split-cake-cpu-entitlements/) and the folks in the #garden channel are awfully helpful.
  • Having an endpoint that allows remote termination of an app sounds like a bit of a security risk, but I'm sure you'll manage that appropriately.

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Fri, 24 Jan 2020 at 22:27, Siva <mailsiva@...> wrote:
Hi Daniel,
Thanks for your response.
I am aware of all the options you are suggesting. But what we are looking for is a process to restart an app instance without human intervention from an alert policy in our monitoring system. This monitoring system is outside of CF and does not have access to CF CLI. But it can access REST endpoints.
For eg - The monitoring system will detect a high CPU utilization on one of the app instance. It will raise an alert which will trigger a policy that will call a REST endpoint of this self healing app. Based on the parameters passed in the request, the self-healing app will restart the requested app instance.
This is required when the app does not know that it is in a bad state but some metrics we are tracking are indicating that the app instance need to be restarted.
Hope that makes sense.

Thanks
Siva

On Fri, Jan 24, 2020 at 9:55 AM Daniel Mikusa <dmikusa@...> wrote:
Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan



--


Re: CF app that helps with self-healing

Siva <mailsiva@...>
 

Hi Daniel,
Thanks for your response.
I am aware of all the options you are suggesting. But what we are looking for is a process to restart an app instance without human intervention from an alert policy in our monitoring system. This monitoring system is outside of CF and does not have access to CF CLI. But it can access REST endpoints.
For eg - The monitoring system will detect a high CPU utilization on one of the app instance. It will raise an alert which will trigger a policy that will call a REST endpoint of this self healing app. Based on the parameters passed in the request, the self-healing app will restart the requested app instance.
This is required when the app does not know that it is in a bad state but some metrics we are tracking are indicating that the app instance need to be restarted.
Hope that makes sense.

Thanks
Siva


On Fri, Jan 24, 2020 at 9:55 AM Daniel Mikusa <dmikusa@...> wrote:
Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan



Re: CF app that helps with self-healing

Daniel Mikusa
 

Not sure I totally get what you are asking, but `cf restart-app-instance` will restart an instance, so if you have an alert trigger a script, you could script the restart.

Or you could just have the app itself know when it gets into a bad state, presumably it would if it's emitting the metrics to indicate this, and exit. When it exits the platform will just restart the app.

Dan


On Fri, Jan 24, 2020 at 12:30 PM Siva <mailsiva@...> wrote:
Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan


CF app that helps with self-healing

Siva <mailsiva@...>
 

Dear CF community,
We are trying to find a way to selectively restart some instances of apps or to restart a specific app on an as needed basis based on some alerts that we receive from our monitoring solution. One option we are considering is to have a self-healing app deployed in CF which will have some REST endpoints exposed which we can call from our alert policies that will perform those actions for us. This self-healing app will essentially have the capabilities of CF CLI for stopping and starting services and instances. This app will also be protected by UAA.
Before we go off and start developing this app, I wanted to check if anyone in the CF community has thought about this approach before and have a solution in place or any ideas to consider.

Thanks,
Siva Balan


Cloud Foundry Summit is BACK - Submit a Talk!

Swarna Podila
 

Dear cloud foundry community,
It is not every day that you see two emails from me in one day :-) 

I wanted to make sure you all received this and noticed the link[1] to CF Summit CFP and the timeline:
  • CFP closes March 20, 2020 11:59PM US Pacific
  • Speaker notifications: April 8, 2020
  • Schedule will be announced: April 9, 2020
We look forward to seeing you all at Summit.  Please do not hesitate to contact any of us at the Foundation if you have any questions.


-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.


---------- Forwarded message ---------
From: Deborah Giles <dgiles@...>
Date: Thu, Jan 23, 2020 at 12:00 PM
Subject: Cloud Foundry Summit is BACK - Submit a Talk!
To: <spodila@...>


Don’t Miss Your Chance to Speak at the Ultimate Enterprise Developer Event

Waterloo. City of the Violet Crown. Bat City. Silicon Hills. Those are just four of the nicknames that help “keep Austin weird.”

Cloud Foundry Summit returns this summer to Austin, Texas to help simplify the developer experience. The one-day event will be co-located with Open Source Summit, the premier event for open source developers and technologists. Join the broader open source ecosystem at OSS then dive in deep with Cloud Foundry at CF Summit — built by and for the community.

Enterprise developers choose Cloud Foundry because it simplifies their workflows in an increasingly complicated cloud-native landscape. We’re upgrading the developer experience and making it easy to automate, scale and manage cloud apps throughout their lifecycle, from startups to the Fortune 500.

We invite you to join us on June 25, 2020 to speak on stage at Cloud Foundry Summit. This year’s tracks include:

  • Contributor Track includes how to contribute, how to get involved in the community, and project updates. 
  • Developer Experience Track includes how Cloud Foundry simplifies your workflow, technical challenges and solutions from CF users, and why empathy matters for developers.
We also invite you to submit a talk for the Cloud Foundry Summit Diversity Luncheon. You can find the Diversity Luncheon application embedded in the standard CFP for the event. The Foundation is committed to five value-driven actions: Be open, be inclusive, be kind, be transparent and be curious. We aim to bring these sensibilities to the Diversity Luncheon — and beyond.

The CFP for Cloud Foundry Summit closes March 20, 2020 at 11:59 pm PT. 

SUBMIT YOUR TALK »

Sponsoring Cloud Foundry Summit demonstrates your commitment to building the future of digital business. Connect with this cutting edge community in Austin to gain valuable mindshare of an elite audience of technical pioneers.

SPONSOR CLOUD FOUNDRY SUMMIT »
Cloud Foundry Summit Highlight Video

This email was sent by: Cloud Foundry Foundation

The Linux Foundation

1 Letterman Dr., Building D
San Francisco, CA, 94129, United States

Update Profile


New lead for Community (CAB) meetings

Swarna Podila
 

Dear CF Community,
Max (popularly known as "Dr. Max", cc'd here) has been running Cloud Foundry Community Advisory Board (CAB) meetings for the past 4-ish years now.  As he mentioned during the recent calls, 2020 is a great opportunity for any of you in the community to nominate yourself (or someone you know is interested) to take the baton from Max.  Max will continue being an active member of our community; we just think that other members may want to take an opportunity to step up and make their mark in our community.  

The responsibilities will be to host 
  • the monthly CAB calls by sourcing interesting topics/demos for the meetings
  • in-person CAB meetings at Cloud Foundry Summits (we, from the Foundation, can help you with that)
If you are unsure of the responsibilities or if you would like to talk to Max directly, please feel free to reach out to him.

Please send us your nominations no later than February 5th. 

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.


Re: UAA Deployment #uaa

Dr Nic Williams <drnicwilliams@...>
 

I coded up running UAA locally awhile back and you might find something useful in my scripts, or consider using the scripts yourself


Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic


UAA Deployment #uaa

santiago@...
 

Hello,
I'm facing issues when trying to deploy a war file into Tomcat.I can build the file and everything but after deploying it into Tomcat I'm getting the below error.
Can anyone help me? thanks!

Exception

javax.servlet.ServletException: Servlet.init() for servlet [spring] threw exception
	org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
	org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
	org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367)
	org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)
	org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1598)
	org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	java.base/java.lang.Thread.run(Thread.java:834)

Root Cause

java.lang.IllegalStateException: Listeners cannot be added to context [/uaa] as the context has been initialised
	org.cloudfoundry.identity.uaa.impl.config.YamlServletProfileInitializer.initialize(YamlServletProfileInitializer.java:80)
	org.cloudfoundry.identity.uaa.impl.config.YamlServletProfileInitializer.initialize(YamlServletProfileInitializer.java:50)
	org.springframework.web.servlet.FrameworkServlet.applyInitializers(FrameworkServlet.java:764)
	org.springframework.web.servlet.FrameworkServlet.configureAndRefreshWebApplicationContext(FrameworkServlet.java:701)
	org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:668)
	org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:716)
	org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:591)
	org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:530)
	org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:170)
	javax.servlet.GenericServlet.init(GenericServlet.java:158)
	org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
	org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
	org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367)
	org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)
	org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1598)
	org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	java.base/java.lang.Thread.run(Thread.java:834)
 


Routing Release 0.197.0

Keshav Sharma <ksharma@...>
 

Hello CF community,
Routing Release 0.197.0 has been cut!

Release Highlights

  • Platform Operators can now experience easier debugging using human readable timestamps based on configuration in gorouter.stdout.log details

  • We received feedback that the access.log app_time metric is ambiguous since it includes network time and not just application time. To avoid any confusion for application developers, the gorouter access.log no longer emits the app_time metric details

CF-Bosh Networking


Re: CF vs PAS4BOSH vs PAS4K8s vs TKG

Daniel Jones
 

Ta!

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Wed, 15 Jan 2020 at 15:49, Eric Malm <emalm@...> wrote:
Hi, Daniel,

In general, "PAS" refers to VMware's commercial distribution of CFAR. "PAS4K8s" is shorthand for the K8s-targeted version currently under pre-GA development, and "PAS4BOSH" is the parallel construction referring specifically to the current BOSH-based product. As with Pivotal/VMware's previous commercialized CFAR products, we intend to build PAS4K8s on top of project development taking place openly in the CFF community.

That said, I would encourage commentary on the document to focus on contributions to and development of those CFF projects, and not to any vendor-specific concerns or products.

Thanks,
Eric

On Wed, Jan 15, 2020 at 2:00 AM Daniel Jones <daniel.jones@...> wrote:
Hi all,

Would it be possible for someone from VMware MAPBU to clarify a few terms for the benefit of the community?
  • Is PAS4BOSH a synonym for CF as currently packaged? Do y'all use the terms interchangeably?
  • Is PAS4K8s simply CF packaged in a Kubernetes-native format, or something else? 
  • Should the community pay heed to discussions about PAS4K8s because that will affect/trickle down to open source CF, or is this proprietary-only code forevermore?
  • Is TKG in any way related to the OSS CF community, or is this an internal project that we should disregard as none of our business?
These questions came up as a result of reading the comments on CF-RFC 030:
  • "are we sure we want to invest that much time and effort in CF?"
  • "Would we imagine doing this in PAS4BOSH? [...] Or maybe just going forward for PAS4K8s and TKG work"
  • "I imagined this only for CF (not PAS4K8S)"
  • "Many teams are shifting focus to PAS4BOSH" (assuming this is a typo and the author meant PAS4K8s)
It's great that folks are having these discussions in the open, and I wouldn't want to discourage this from happening. I also appreciate that things are probably in flux and being figured out currently.

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


Request for Feedback - Cloudfoundry for Kubernetes Integration artifact from Release Integration team

Saikiran Yerram
 

Hi CF Community,

The Release Integration team has been working on a proposal for supporting the integration needs of projects contributing to Cloudfoundry on Kubernetes. We are looking for feedback from the Cloud Foundry Community on what we have proposed so far.

You can find the proposal here.

Looking forward to hearing from you.

Thanks
-- 
Saikiran Yerram
Release Integration team


Re: CF vs PAS4BOSH vs PAS4K8s vs TKG

Eric Malm <emalm@...>
 

Hi, Daniel,

In general, "PAS" refers to VMware's commercial distribution of CFAR. "PAS4K8s" is shorthand for the K8s-targeted version currently under pre-GA development, and "PAS4BOSH" is the parallel construction referring specifically to the current BOSH-based product. As with Pivotal/VMware's previous commercialized CFAR products, we intend to build PAS4K8s on top of project development taking place openly in the CFF community.

That said, I would encourage commentary on the document to focus on contributions to and development of those CFF projects, and not to any vendor-specific concerns or products.

Thanks,
Eric


On Wed, Jan 15, 2020 at 2:00 AM Daniel Jones <daniel.jones@...> wrote:
Hi all,

Would it be possible for someone from VMware MAPBU to clarify a few terms for the benefit of the community?
  • Is PAS4BOSH a synonym for CF as currently packaged? Do y'all use the terms interchangeably?
  • Is PAS4K8s simply CF packaged in a Kubernetes-native format, or something else? 
  • Should the community pay heed to discussions about PAS4K8s because that will affect/trickle down to open source CF, or is this proprietary-only code forevermore?
  • Is TKG in any way related to the OSS CF community, or is this an internal project that we should disregard as none of our business?
These questions came up as a result of reading the comments on CF-RFC 030:
  • "are we sure we want to invest that much time and effort in CF?"
  • "Would we imagine doing this in PAS4BOSH? [...] Or maybe just going forward for PAS4K8s and TKG work"
  • "I imagined this only for CF (not PAS4K8S)"
  • "Many teams are shifting focus to PAS4BOSH" (assuming this is a typo and the author meant PAS4K8s)
It's great that folks are having these discussions in the open, and I wouldn't want to discourage this from happening. I also appreciate that things are probably in flux and being figured out currently.

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


Re: CF vs PAS4BOSH vs PAS4K8s vs TKG

Davanum Srinivas
 

Daniel,

As i understand it, TKG is an internal project unrelated to either OSS communities (CF or k8s).

Thanks,
Dims


On Wed, Jan 15, 2020 at 5:00 AM Daniel Jones <daniel.jones@...> wrote:
Hi all,

Would it be possible for someone from VMware MAPBU to clarify a few terms for the benefit of the community?
  • Is PAS4BOSH a synonym for CF as currently packaged? Do y'all use the terms interchangeably?
  • Is PAS4K8s simply CF packaged in a Kubernetes-native format, or something else? 
  • Should the community pay heed to discussions about PAS4K8s because that will affect/trickle down to open source CF, or is this proprietary-only code forevermore?
  • Is TKG in any way related to the OSS CF community, or is this an internal project that we should disregard as none of our business?
These questions came up as a result of reading the comments on CF-RFC 030:
  • "are we sure we want to invest that much time and effort in CF?"
  • "Would we imagine doing this in PAS4BOSH? [...] Or maybe just going forward for PAS4K8s and TKG work"
  • "I imagined this only for CF (not PAS4K8S)"
  • "Many teams are shifting focus to PAS4BOSH" (assuming this is a typo and the author meant PAS4K8s)
It's great that folks are having these discussions in the open, and I wouldn't want to discourage this from happening. I also appreciate that things are probably in flux and being figured out currently.

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists



--
Davanum Srinivas :: https://twitter.com/dims


CF vs PAS4BOSH vs PAS4K8s vs TKG

Daniel Jones
 

Hi all,

Would it be possible for someone from VMware MAPBU to clarify a few terms for the benefit of the community?
  • Is PAS4BOSH a synonym for CF as currently packaged? Do y'all use the terms interchangeably?
  • Is PAS4K8s simply CF packaged in a Kubernetes-native format, or something else? 
  • Should the community pay heed to discussions about PAS4K8s because that will affect/trickle down to open source CF, or is this proprietary-only code forevermore?
  • Is TKG in any way related to the OSS CF community, or is this an internal project that we should disregard as none of our business?
These questions came up as a result of reading the comments on CF-RFC 030:
  • "are we sure we want to invest that much time and effort in CF?"
  • "Would we imagine doing this in PAS4BOSH? [...] Or maybe just going forward for PAS4K8s and TKG work"
  • "I imagined this only for CF (not PAS4K8S)"
  • "Many teams are shifting focus to PAS4BOSH" (assuming this is a typo and the author meant PAS4K8s)
It's great that folks are having these discussions in the open, and I wouldn't want to discourage this from happening. I also appreciate that things are probably in flux and being figured out currently.

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists

521 - 540 of 9369