Hi Daniel, 
The CF-K8s Networking team is currently working on a solution using Route CRD- to introduce a “Route” custom resource and have Cloud Controller make/update these directly as part of the `cf map-route` and `cf unmap-route` workflows. Happy to discuss this further in our Cloud-Foundry Slack- #networking group. Regards, Keshav Sharma Product Manager | CF-K8s-Networking VMware

On Wed, Apr 15, 2020 at 3:01 AM Daniel Jones <daniel.jones@...> wrote:

Hi all,

In the spirit of community, I'm going to ask this question outright and in the open - is anyone (*looks at VMware MAPBU*) working on a CRD and accompanying controller for CF on Kubernetes?

Anyone with a non-trivial amount of Cloud Foundry experience knows that whilst the imperative interface of the CF CLI is great for exploratory work, it's far from ideal for production environments. I make a point of telling folks in CF training courses that no human should be using the CLI in production, other than for debugging.

A declarative interface for CF has always been desirable, and its omission is going to become even more stark once running CF on Kubernetes is the norm. We've had cf-mgmt which is close, but involves more steps than is ideal.

It'd be great to have one or more CRDs that represent the state of a Cloud Foundry, and accompanying controllers that converge upon that state. When I talk about state, I mean things like orgs, spaces, service broker registrations, service instances, roles and so on.

Four years ago I started work on a project called cf-converger to diff and converge a Cloud Foundry instance on a state declared in YAML. I got distracted with running a business and doing billable work, so whilst the concept was proven, it never really got to a state of usefulness. Plus, I seemed to spend half my coding time just writing excessively-verbose chained method calls on the official Java CF client :D 

I see such a solution as an inevitability in the Kubernetes-based future. Whilst I'm personally tempted to resurrect the project, it makes very little sense for a company like EngineerBetter to divert resources from billable work to a project that is needed, but can't be monetised.

Are any of the big players working on something similar? Is it something we should all be thinking and talking about? Is there any point in the community working on such a solution, or are one of the bigger companies secretly working on something that would supersede any community effort?

Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

@DanielJonesEB

EngineerBetter Ltd - More than cloud platform specialists

Hi all,

In the spirit of community, I'm going to ask this question outright and in the open - is anyone (*looks at VMware MAPBU*) working on a CRD and accompanying controller for CF on Kubernetes?

Anyone with a non-trivial amount of Cloud Foundry experience knows that whilst the imperative interface of the CF CLI is great for exploratory work, it's far from ideal for production environments. I make a point of telling folks in CF training courses that no human should be using the CLI in production, other than for debugging.

A declarative interface for CF has always been desirable, and its omission is going to become even more stark once running CF on Kubernetes is the norm. We've had cf-mgmt which is close, but involves more steps than is ideal.

It'd be great to have one or more CRDs that represent the state of a Cloud Foundry, and accompanying controllers that converge upon that state. When I talk about state, I mean things like orgs, spaces, service broker registrations, service instances, roles and so on.

Four years ago I started work on a project called cf-converger to diff and converge a Cloud Foundry instance on a state declared in YAML. I got distracted with running a business and doing billable work, so whilst the concept was proven, it never really got to a state of usefulness. Plus, I seemed to spend half my coding time just writing excessively-verbose chained method calls on the official Java CF client :D 

I see such a solution as an inevitability in the Kubernetes-based future. Whilst I'm personally tempted to resurrect the project, it makes very little sense for a company like EngineerBetter to divert resources from billable work to a project that is needed, but can't be monetised.

Are any of the big players working on something similar? Is it something we should all be thinking and talking about? Is there any point in the community working on such a solution, or are one of the bigger companies secretly working on something that would supersede any community effort?

Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

@DanielJonesEB

EngineerBetter Ltd - More than cloud platform specialists

Congratulations Sai and everyone working in CF-for-K8s! 

@Chip and Dan: As Sai mentions, we'll be drafting something for cloudfoundry.org and/or docs.cloudfoundry.org to point users to the appropriate project for their interest or need. We also talked about putting some "if you're looking for..." blurbs in both project READMEs to help clarify.

TT

--

Troy Topnik

Senior Product Manager, 

SUSE Cloud Application Platform 

troy.topnik@...

 

Hey Chip,

Thanks! A lot of people were involved in making this happen!

Yes, that is the plan. We discussed this topic in one of the SIG calls last month but now is a good time to make that happen as we have our first 0.1.0 release. 

My plan is to work with Troy Topnik, Swarna to build this page. Troy already published a blog post with comparisons but it is worth having a dedicated page on Cloud Foundry with details so that users can decide which project to start with. Also, we will need to keep it up to date, so our users continue to get optimal experience as the products evolve.

Thanks,
Sai

This is awesome news. Well done to the RelInt team!

Have the KubeCF and RelInt considered creating a document somewhere that folks can reference to know what the "current state" differences between KubeCF and cf-for-k8s are? IMO, that will help people navigate what will be an ever-changing set of differences/similarities when deciding which project to start with.

Chip Childers

Executive Director

Cloud Foundry Foundation

On Thu, Apr 9, 2020 at 7:17 PM Saikiran Yerram <syerram@...> wrote:

Release Notes

--------------------

Introducing the v0.1.0 alpha version of Cloud Foundry for Kubernetes

Installation

Follow the instructions in the How to Deploy document.

Background

The Release Integration team has been developing a Cloud Foundry deployment artifact to install the Cloud Foundry Foundation on a Kubernetes cluster. The deployment artifact contains the new Kubernetes-native CF components, which are built on top of popular Kubernetes projects like kpack, fluentd, and Istio.

The deployment artifact has been available to the community for some time with limited capabilities. The primary goal was to enable CF contributing projects to rapidly iterate on their components.

With the recent integration of buildpacks support, we are excited to release the first version, 0.1, of this product "Cloud Foundry for Kubernetes" (aka "cf-for-k8s"). We will continue to create 0.X releases as new capabilities are added and we improve stability of cf-for-k8s. We plan to establish a release cadence.

Highlights

App staging with kpack

With the 0.1 release, users can now push an app with source code. In the Cloud Foundry for Bosh, the Cloud Controller issues a staging request to Diego, which detects and builds a droplet with the right Cloud Foundry build packs. Once the droplet is built, it then schedules the app on one or more Diego cells.  

In cf-for-k8s, CAPI issues the request to kpack, which uses cloud-native buildpacks to detect the app language and then build the app image. Once the app image is available, the image is pushed to the app registry and a request is sent to Eirini to schedule the app workloads, which are scheduled as one or more K8s pod deployments. Once the app workloads are available, users can curl the app.

Encrypted communication

The v0.1 release comes with Istio, which enforces encrypted communication between components, app workloads, and ingress gateway. In the Cloud Foundry for Bosh, each component owned the responsibility of managing and enforcing encrypted communication. All of this responsibility is now delegated to Istio. 

Istio uses sidecar, which is deployed to every pod, to encrypt communication between all CF components, app workloads and shared resources like the database. In addition, Istio will rotate certificates automatically without requiring any intervention from the component teams or platform engineers.

Manage cf-for-k8s lifecycle with kapp

In the Cloud Foundry for Bosh, Platform engineers and Contributing teams relied on bosh deploy command to install, upgrade or remove Cloud Foundry foundation on VMs. 

Kapp provides a similar experience where users can install, upgrade or remove Cloud Foundry on Kubernetes. Unlike kubectl apply command that exits before resources are created in the cluster, kapp waits until all resources are created and continuously provides status updates on the resource availability. In addition, kapp can delete all cf-for-k8s resources in one swoop.

Furthermore, kapp provides resource differences when upgrading to new versions of cf-for-k8s. Platform engineers can audit the differences (new resources, updates to existing resources) between their current foundation and the new version (e.g. new version of cf-for-k8s may bump cluster resource needs).

Templating with ytt 

ytt (pronounced spelled out) is a templating tool that understands YAML structure. Product delivery teams can use it to create reusable YAML templates that operators can use for product configuration.

Reusable configuration and built in full featured programming language help ease the burden of configuring complex software. The built in YAML structure helps reduce the mental overhead of YAML construction. You can reuse the same templates in different environments by injecting environment-specific values (via cf-install-values.yml) at deploy time. For example, configuring app registry, your domain certificates and so on. 

Furthermore, with the custom validations, and fast and deterministic execution, you can take advantage of faster feedback loops when creating, testing, and deploying templates.

ytt ‘s “overlay” functionality helps users manage the customization of complex software configuration by providing advanced configuration. Using an overlay, you can replace parts or whole of cf-for-k8s templates. For e.g. see `remove-resource-requirements.yml`, which reduces needs for matching resources, so cf-for-k8s can be installed on smaller environments.

Documentation

The main documentation page for cf-for-k8s contains a variety of resources to help get you started. You can find instructions on deploying CF, guidelines for contributors, and other helpful resources. We eagerly accept PRs if you have corrections, suggestions, etc.

Configuration options

Platform operators define their configuration using a cf-for-k8s “values” file. See the sample-cf-install-values.yml file as suggested by the deploy documentation.

• cf-for-k8s has been shown to run on multiple distributions of Kubernetes, including GKE, PKS, AKS, EKS, Minikube and Kind. 

• Both Docker Hub and Google’s Container Registry can be used as the App Registry.

If there are any missing configuration options, we recommend you create a feature request issue in the cf-for-k8s repository. We would like to know more about your usecases. 

Compatibility

Kubernetes

• 1.15 or 1.16

Known Issues

For a list of known issues with this release, please visit the issues page in the repository. A few notable issues are listed below,

1. cf push does not stream app staging logs.

2. Upgrading cf-for-k8s is not yet supported

3. Custom buildpacks and cf cli buildpacks related commands are not supported.

Feedback

We love feedback. Please file a GitHub issue for bugs, feature requests, or suggestions. Or reach out to us on Cloud Foundry Slack in #cf-for-k8s.

Coming Next

You can see our upcoming prioritized work in our CF Release Integration tracker project.

Resources

• cf-for-k8s repository

• cf-for-k8s known issues

tools from k14s - ytt, kapp, kbld

--

Saikiran Yerram

This is awesome news. Well done to the RelInt team!

Have the KubeCF and RelInt considered creating a document somewhere that folks can reference to know what the "current state" differences between KubeCF and cf-for-k8s are? IMO, that will help people navigate what will be an ever-changing set of differences/similarities when deciding which project to start with.

Chip Childers

Executive Director

Cloud Foundry Foundation

On Thu, Apr 9, 2020 at 7:17 PM Saikiran Yerram <syerram@...> wrote:

Release Notes

--------------------

Introducing the v0.1.0 alpha version of Cloud Foundry for Kubernetes

Installation

Follow the instructions in the How to Deploy document.

Background

The Release Integration team has been developing a Cloud Foundry deployment artifact to install the Cloud Foundry Foundation on a Kubernetes cluster. The deployment artifact contains the new Kubernetes-native CF components, which are built on top of popular Kubernetes projects like kpack, fluentd, and Istio.

The deployment artifact has been available to the community for some time with limited capabilities. The primary goal was to enable CF contributing projects to rapidly iterate on their components.

With the recent integration of buildpacks support, we are excited to release the first version, 0.1, of this product "Cloud Foundry for Kubernetes" (aka "cf-for-k8s"). We will continue to create 0.X releases as new capabilities are added and we improve stability of cf-for-k8s. We plan to establish a release cadence.

Highlights

App staging with kpack

With the 0.1 release, users can now push an app with source code. In the Cloud Foundry for Bosh, the Cloud Controller issues a staging request to Diego, which detects and builds a droplet with the right Cloud Foundry build packs. Once the droplet is built, it then schedules the app on one or more Diego cells.  

In cf-for-k8s, CAPI issues the request to kpack, which uses cloud-native buildpacks to detect the app language and then build the app image. Once the app image is available, the image is pushed to the app registry and a request is sent to Eirini to schedule the app workloads, which are scheduled as one or more K8s pod deployments. Once the app workloads are available, users can curl the app.

Encrypted communication

The v0.1 release comes with Istio, which enforces encrypted communication between components, app workloads, and ingress gateway. In the Cloud Foundry for Bosh, each component owned the responsibility of managing and enforcing encrypted communication. All of this responsibility is now delegated to Istio. 

Istio uses sidecar, which is deployed to every pod, to encrypt communication between all CF components, app workloads and shared resources like the database. In addition, Istio will rotate certificates automatically without requiring any intervention from the component teams or platform engineers.

Manage cf-for-k8s lifecycle with kapp

In the Cloud Foundry for Bosh, Platform engineers and Contributing teams relied on bosh deploy command to install, upgrade or remove Cloud Foundry foundation on VMs. 

Kapp provides a similar experience where users can install, upgrade or remove Cloud Foundry on Kubernetes. Unlike kubectl apply command that exits before resources are created in the cluster, kapp waits until all resources are created and continuously provides status updates on the resource availability. In addition, kapp can delete all cf-for-k8s resources in one swoop.

Furthermore, kapp provides resource differences when upgrading to new versions of cf-for-k8s. Platform engineers can audit the differences (new resources, updates to existing resources) between their current foundation and the new version (e.g. new version of cf-for-k8s may bump cluster resource needs).

Templating with ytt 

ytt (pronounced spelled out) is a templating tool that understands YAML structure. Product delivery teams can use it to create reusable YAML templates that operators can use for product configuration.

Reusable configuration and built in full featured programming language help ease the burden of configuring complex software. The built in YAML structure helps reduce the mental overhead of YAML construction. You can reuse the same templates in different environments by injecting environment-specific values (via cf-install-values.yml) at deploy time. For example, configuring app registry, your domain certificates and so on. 

Furthermore, with the custom validations, and fast and deterministic execution, you can take advantage of faster feedback loops when creating, testing, and deploying templates.

ytt ‘s “overlay” functionality helps users manage the customization of complex software configuration by providing advanced configuration. Using an overlay, you can replace parts or whole of cf-for-k8s templates. For e.g. see `remove-resource-requirements.yml`, which reduces needs for matching resources, so cf-for-k8s can be installed on smaller environments.

Documentation

The main documentation page for cf-for-k8s contains a variety of resources to help get you started. You can find instructions on deploying CF, guidelines for contributors, and other helpful resources. We eagerly accept PRs if you have corrections, suggestions, etc.

Configuration options

Platform operators define their configuration using a cf-for-k8s “values” file. See the sample-cf-install-values.yml file as suggested by the deploy documentation.

• cf-for-k8s has been shown to run on multiple distributions of Kubernetes, including GKE, PKS, AKS, EKS, Minikube and Kind. 

• Both Docker Hub and Google’s Container Registry can be used as the App Registry.

If there are any missing configuration options, we recommend you create a feature request issue in the cf-for-k8s repository. We would like to know more about your usecases. 

Compatibility

Kubernetes

• 1.15 or 1.16

Known Issues

For a list of known issues with this release, please visit the issues page in the repository. A few notable issues are listed below,

1. cf push does not stream app staging logs.

2. Upgrading cf-for-k8s is not yet supported

3. Custom buildpacks and cf cli buildpacks related commands are not supported.

Feedback

We love feedback. Please file a GitHub issue for bugs, feature requests, or suggestions. Or reach out to us on Cloud Foundry Slack in #cf-for-k8s.

Coming Next

You can see our upcoming prioritized work in our CF Release Integration tracker project.

Resources

• cf-for-k8s repository

• cf-for-k8s known issues

tools from k14s - ytt, kapp, kbld

--

Saikiran Yerram

Release Notes

--------------------

Introducing the v0.1.0 alpha version of Cloud Foundry for Kubernetes

Installation

Follow the instructions in the How to Deploy document.

Background

The Release Integration team has been developing a Cloud Foundry deployment artifact to install the Cloud Foundry Foundation on a Kubernetes cluster. The deployment artifact contains the new Kubernetes-native CF components, which are built on top of popular Kubernetes projects like kpack, fluentd, and Istio.

The deployment artifact has been available to the community for some time with limited capabilities. The primary goal was to enable CF contributing projects to rapidly iterate on their components.

With the recent integration of buildpacks support, we are excited to release the first version, 0.1, of this product "Cloud Foundry for Kubernetes" (aka "cf-for-k8s"). We will continue to create 0.X releases as new capabilities are added and we improve stability of cf-for-k8s. We plan to establish a release cadence.

Highlights

App staging with kpack

With the 0.1 release, users can now push an app with source code. In the Cloud Foundry for Bosh, the Cloud Controller issues a staging request to Diego, which detects and builds a droplet with the right Cloud Foundry build packs. Once the droplet is built, it then schedules the app on one or more Diego cells.  

In cf-for-k8s, CAPI issues the request to kpack, which uses cloud-native buildpacks to detect the app language and then build the app image. Once the app image is available, the image is pushed to the app registry and a request is sent to Eirini to schedule the app workloads, which are scheduled as one or more K8s pod deployments. Once the app workloads are available, users can curl the app.

Encrypted communication

The v0.1 release comes with Istio, which enforces encrypted communication between components, app workloads, and ingress gateway. In the Cloud Foundry for Bosh, each component owned the responsibility of managing and enforcing encrypted communication. All of this responsibility is now delegated to Istio. 

Istio uses sidecar, which is deployed to every pod, to encrypt communication between all CF components, app workloads and shared resources like the database. In addition, Istio will rotate certificates automatically without requiring any intervention from the component teams or platform engineers.

Manage cf-for-k8s lifecycle with kapp

In the Cloud Foundry for Bosh, Platform engineers and Contributing teams relied on bosh deploy command to install, upgrade or remove Cloud Foundry foundation on VMs. 

Kapp provides a similar experience where users can install, upgrade or remove Cloud Foundry on Kubernetes. Unlike kubectl apply command that exits before resources are created in the cluster, kapp waits until all resources are created and continuously provides status updates on the resource availability. In addition, kapp can delete all cf-for-k8s resources in one swoop.

Furthermore, kapp provides resource differences when upgrading to new versions of cf-for-k8s. Platform engineers can audit the differences (new resources, updates to existing resources) between their current foundation and the new version (e.g. new version of cf-for-k8s may bump cluster resource needs).

Templating with ytt 

ytt (pronounced spelled out) is a templating tool that understands YAML structure. Product delivery teams can use it to create reusable YAML templates that operators can use for product configuration.

Reusable configuration and built in full featured programming language help ease the burden of configuring complex software. The built in YAML structure helps reduce the mental overhead of YAML construction. You can reuse the same templates in different environments by injecting environment-specific values (via cf-install-values.yml) at deploy time. For example, configuring app registry, your domain certificates and so on. 

Furthermore, with the custom validations, and fast and deterministic execution, you can take advantage of faster feedback loops when creating, testing, and deploying templates.

ytt ‘s “overlay” functionality helps users manage the customization of complex software configuration by providing advanced configuration. Using an overlay, you can replace parts or whole of cf-for-k8s templates. For e.g. see `remove-resource-requirements.yml`, which reduces needs for matching resources, so cf-for-k8s can be installed on smaller environments.

Documentation

The main documentation page for cf-for-k8s contains a variety of resources to help get you started. You can find instructions on deploying CF, guidelines for contributors, and other helpful resources. We eagerly accept PRs if you have corrections, suggestions, etc.

Configuration options

Platform operators define their configuration using a cf-for-k8s “values” file. See the sample-cf-install-values.yml file as suggested by the deploy documentation.

• cf-for-k8s has been shown to run on multiple distributions of Kubernetes, including GKE, PKS, AKS, EKS, Minikube and Kind. 

• Both Docker Hub and Google’s Container Registry can be used as the App Registry.

If there are any missing configuration options, we recommend you create a feature request issue in the cf-for-k8s repository. We would like to know more about your usecases. 

Compatibility

Kubernetes

• 1.15 or 1.16

Known Issues

For a list of known issues with this release, please visit the issues page in the repository. A few notable issues are listed below,

1. cf push does not stream app staging logs.

2. Upgrading cf-for-k8s is not yet supported

3. Custom buildpacks and cf cli buildpacks related commands are not supported.

Feedback

We love feedback. Please file a GitHub issue for bugs, feature requests, or suggestions. Or reach out to us on Cloud Foundry Slack in #cf-for-k8s.

Coming Next

You can see our upcoming prioritized work in our CF Release Integration tracker project.

Resources

• cf-for-k8s repository

• cf-for-k8s known issues

tools from k14s - ytt, kapp, kbld

--

Saikiran Yerram

Best of luck Chip. You’ll do a great job!

Thanks Abby for your years of at the helm.

Dr Nic

On Wed, 8 Apr 2020 at 12:20 am, Chip Childers <cchilders@...> wrote:

Quick follow up! I mistakenly stated that the AMA is on Thursday April 8th... which does not exist this year. The AMA is on Thursday April 9th. See you on Slack!

Chip Childers

Executive Director

Cloud Foundry Foundation

On Tue, Apr 7, 2020 at 9:10 AM Chip Childers <cchilders@...> wrote:

Cloud Foundry Community,

First and foremost, I truly hope that each of you is doing as well as can be expected in these extraordinary times.

As you may have seen, we announced a leadership change this morning. I am stepping into the role of Executive Director of the Cloud Foundry Foundation. Abby Kearns has accepted an executive role with another organization, to be announced. This is a very exciting opportunity for Abby, and all of us on the foundation’s staff and directors are extremely happy for her. Abby has been leading the foundation for several years through quite a bit of change in our project, our community, and the broader market. She’s not going far, but she will be missed.

We also announced that Paul Fazzone, SVP Tanzu R&D at VMware, has been elected to chair the board of directors. Paul has been a strong advocate and supporter of the foundation, having served as Treasurer for the foundation and as a director for several years now. Paul is taking over the role of chair from John Roese, who has been a steady hand from the organization’s inception. I am looking forward to working much more closely with Paul as we push the organization forward into the future. 

Our focus as a community has always been to make developers’ lives easier, and each of you has played a part in the long list of user success stories. Even today, as society grapples with the incredible challenge of a global pandemic, I am reminded of the incredible value of the work this community does. Organizations from around the world that have adopted Cloud Foundry are using it to respond in these trying times, each in their own way. National governments have used the Cloud Foundry platform to rapidly build, deploy and scale software that is helping their citizens get information and register for economic support. Countless corporations are using Cloud Foundry to both support their customers in new ways and do their part for the greater good. These responses have required actions measured in days and hours, not weeks and months. In short, this community’s efforts over the years have built something worthing being truly proud of.

This community is also one that has managed to continuously evolve the architecture of the platform through several major cycles of change. Today is no different, as we have come together on the shared mission of bringing the Cloud Foundry developer experience to Kubernetes clusters everywhere. 

As the ancient Greek philosopher, Heraclitus said, “Change is the only constant in life.” Our community embraces that way of thinking, both for the Cloud Foundry project itself and when considering how to continue to enhance the developer experience provided by the platform. Ultimately, the core Cloud Foundry function cf-push will remain well into the future, and its architecture will continue to evolve.

I’m sure many of you have questions about these changes, and I welcome the opportunity to answer them. Feel free to email me directly ( cchilders@... ), or join us for a slack-based AMA this Thursday, April 8th, from 8-10 AM PST on the Cloud Foundry community’s slack instance in the #cff-forum channel. I will be happy to discuss the transition, the future of the Foundation and respond to any comments or questions you may have.

-chip

Chip Childers

Executive Director

Cloud Foundry Foundation

--

Dr Nic Williams

Stark & Wayne LLC

http://starkandwayne.com

+61 437 276 076

twitter @drnic

Dear Cloud Foundry Community,

Over the last year, we have seen the industry shift towards deploying software on top of Kubernetes. As a result, we have all chosen to invest heavily in building on top of Kubernetes. Separately, we have also observed that BOSH has reached a point of stability and maturity, such that there aren’t lots of incoming feature requests and enhancements to add.

We continue to view BOSH as an important project and are still fully committed to supporting our OSS users using BOSH for the next couple years . However, in light of these changes, several BOSH PMC projects[1] will be shifting from the pairing model to the distributed committer model (for more information about distributed committer vs pairing models, see the CFF Development Operations Policy [2], section IV.B.). Shatarupa Nandi (snandi@..., @rupa on CFF Slack) and Nadja Conklin (nconklin@..., @Nadja Conklin on CFF Slack) will temporarily step in as Project Leads. 

We are moving away from having a full time team working on each of the projects. Instead, we will have 6-8 engineers who will dedicate a portion of their time on a regular basis for ongoing support and maintenance of the BOSH projects. This will likely result in the following changes:

• A reduced cadence of cutting new stemcells and patching existing stemcells for low and medium severity CVEs. Presently, we aim to cut new stemcell patches every 2 weeks. We will now be doing the same every 6 weeks. We will maintain the status quo for high and critical CVEs and will patch those as soon as possible.

• We will pause working on Bionic stemcells and will not be cutting a new line of Bionic stemcells. We are aware that Xenial stemcells are supported until April 2021. This is an area where we are seeking help from the CFF community. Please see the end of the email. We may pick up this work during the 2nd half of the year, depending on cf-for-k8s adoption and our level of staffing on BOSH.

• A reduced cadence of new releases of BOSH PMC projects[1]. Since there will be little active development, we will move to cutting releases ad-hoc when there are enough changes built up.

• We will pause active development on the various CPIs (including OpenStack CPI, Azure CPI, GCP CPI, and AWS CPI.) We will continue to patch critical bugs, backwards incompatible IaaS API changes, and high severity CVEs. However, we will not be adding features to extend the capabilities of the CPIs.

• While we will continue to answer questions about BOSH, we will likely be less responsive than before. We still hope to answer questions on these Slack channels within a reasonable time. We will be most active in #bosh. Other BOSH Slack channels (for example, #bosh-core-dev) will see reduced activity and will be deprecated over time.

• The committers are all on cf-bosh@..., and will continue to engage with the community of users and contributors via the mailing lists. 

We would like to seek help from other members of the Cloud Foundry community to help with ongoing maintenance of the BOSH projects. Here are some ways in which you can help us:

• Please help your friends in the community by answering questions on #bosh

• If you would like to contribute to adding Bionic support and/or start publishing Bionic stemcells on bosh.io, we would welcome PRs and will be happy to work with you to review and merge them. If you are interested in forming an OSS team to build Bionic stemcells and add support for Bionic to Cloud Foundry components, please reach out to Marco Voelz or Shatarupa Nandi.

• If you would like improvements in BOSH and/or the CPIs, please consider contributing the feature directly via PRs to the various repos

• If you notice a buildup of features / fixes that warrant a release being cut, ping the team via cf-bosh@...

• If you would like to be a Project Lead for any of these projects, please reach out to Shatarupa Nandi and/or Nadja Conklin.

Thank you for your help and support!

[1] This includes the following repos: bosh, bosh-agent, bosh-dns-release, bosh-linux-stemcell-builder, bosh-deployment, bosh-cli, bbl, bosh.io github org, docs-bosh, bpm-release, bosh-google-cpi-release, bosh-azure-cpi-release, bosh-openstack-cpi-release, bosh-aws-cpi-release, bosh-lite, bosh-utils, bosh-s3cli, bosh-acceptance-tests, jumpbox-deployment, os-conf-release.

[2] https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF-DEV-OPS-POLICY.pdf

Quick follow up! I mistakenly stated that the AMA is on Thursday April 8th... which does not exist this year. The AMA is on Thursday April 9th. See you on Slack!

Chip Childers

Executive Director

Cloud Foundry Foundation

On Tue, Apr 7, 2020 at 9:10 AM Chip Childers <cchilders@...> wrote:

Cloud Foundry Community,

First and foremost, I truly hope that each of you is doing as well as can be expected in these extraordinary times.

As you may have seen, we announced a leadership change this morning. I am stepping into the role of Executive Director of the Cloud Foundry Foundation. Abby Kearns has accepted an executive role with another organization, to be announced. This is a very exciting opportunity for Abby, and all of us on the foundation’s staff and directors are extremely happy for her. Abby has been leading the foundation for several years through quite a bit of change in our project, our community, and the broader market. She’s not going far, but she will be missed.

We also announced that Paul Fazzone, SVP Tanzu R&D at VMware, has been elected to chair the board of directors. Paul has been a strong advocate and supporter of the foundation, having served as Treasurer for the foundation and as a director for several years now. Paul is taking over the role of chair from John Roese, who has been a steady hand from the organization’s inception. I am looking forward to working much more closely with Paul as we push the organization forward into the future. 

Our focus as a community has always been to make developers’ lives easier, and each of you has played a part in the long list of user success stories. Even today, as society grapples with the incredible challenge of a global pandemic, I am reminded of the incredible value of the work this community does. Organizations from around the world that have adopted Cloud Foundry are using it to respond in these trying times, each in their own way. National governments have used the Cloud Foundry platform to rapidly build, deploy and scale software that is helping their citizens get information and register for economic support. Countless corporations are using Cloud Foundry to both support their customers in new ways and do their part for the greater good. These responses have required actions measured in days and hours, not weeks and months. In short, this community’s efforts over the years have built something worthing being truly proud of.

This community is also one that has managed to continuously evolve the architecture of the platform through several major cycles of change. Today is no different, as we have come together on the shared mission of bringing the Cloud Foundry developer experience to Kubernetes clusters everywhere. 

As the ancient Greek philosopher, Heraclitus said, “Change is the only constant in life.” Our community embraces that way of thinking, both for the Cloud Foundry project itself and when considering how to continue to enhance the developer experience provided by the platform. Ultimately, the core Cloud Foundry function cf-push will remain well into the future, and its architecture will continue to evolve.

I’m sure many of you have questions about these changes, and I welcome the opportunity to answer them. Feel free to email me directly ( cchilders@... ), or join us for a slack-based AMA this Thursday, April 8th, from 8-10 AM PST on the Cloud Foundry community’s slack instance in the #cff-forum channel. I will be happy to discuss the transition, the future of the Foundation and respond to any comments or questions you may have.

-chip

Chip Childers

Executive Director

Cloud Foundry Foundation

It is an understatement when we say “these are unprecedented times.” During these times of uncertainty, the Cloud Foundry Foundation wants to offer an open zoom “break room” for our community. Please feel free to “walk” into this break room and hang out with others. (Please do remember: Code of conduct applies here as well.)

From the Last Few Weeks:

• KubeCF released v1.0 AND v1.0.1! Message here. Blog post here. Press release here.
• Stratos released v3.0! Message here.
• CF routing v0.199.0 was released. Message here.
• Miguel Luna has taken over as project lead of the Services API project.
• CF for Kubernetes SIG call video from March 17 is up. Focus on container to container networking. Video here.
• CF CAB call video from March 18 is up here. Nice update and demo of CF-for-k8s!

Community Updates:

• Have a question for the staff at Cloud Foundry Foundation? Want to stay current with updates for the Foundation? Join the new #cff-forum channel on the community Slack.

All things Cloud Foundry Summit:

• Call for proposals for Cloud Foundry NA Summit is (still) open (extended to April 3).

Dates To Remember (All times US Pacific):

• CF Operators Sig Meeting – 8:00 AM on March 25
• CF for Kubernetes SIG call – 8:30 AM on March 31
• Bi-Weekly CF App Runtime PMC meeting – 10:30 AM on March 31

Check the community calendar for updates and meeting details here: https://www.cloudfoundry.org/community-calendar/

Interesting Finds from Around the Web:

• https://medium.com/@eeenotes/containerizing-cf-be4ebb81cf0f
• https://github.blog/2020-03-16-npm-is-joining-github/?utm_campaign=1584377606&utm_medium=social&utm_source=twitter&utm_content=1584377606
• https://techcrunch.com/2020/03/11/aws-launches-bottlerocket-a-linux-based-os-for-container-hosting/
• https://headtopics.com/us/vmware-created-a-new-business-unit-that-includes-pivotal-and-heptio-business-insider-11779107
• https://www.zdnet.com/article/pet-the-cat-own-the-bathrobe-linus-torvalds-on-working-from-home/
• https://www.zdnet.com/article/with-kubecf-cloud-foundry-comes-to-kubernetes/
• https://www.sdxcentral.com/articles/news/cloud-foundry-foundation-adopts-kubecf-runtime/2020/03/

Who’s hiring?  

Check out the jobs board https://www.cloudfoundry.org/cf-jobs/

• SAP Cloud Platform is hiring https://twitter.com/voelzmo/status/1240626439898136578 
• Resilient Scale is looking for folks with experience in Cloud Foundry and Concourse: https://www.linkedin.com/pulse/join-our-team-resilient-scale-steve-greenberg/?published=t
• Royal Bank of Scotland is looking for a Cloud Application Architect: https://jobs.rbs.com/jobs/4784789-cloud-application-architect 
• Anynines is looking for a Sys Admins, System Engineers, and Software Developers: https://www.anynines.com/career 

 

Looking for an industry event to attend or to submit a speaking proposal? We put together a helpful calendar of events for 2020: https://calendar.google.com/calendar?cid=Y2xvdWRmb3VuZHJ5Lm9yZ181Yjg2a2dobzkwdmNqOWtncDE3cjljYjh1c0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t 

Cloud Foundry Community,

First and foremost, I truly hope that each of you is doing as well as can be expected in these extraordinary times.

As you may have seen, we announced a leadership change this morning. I am stepping into the role of Executive Director of the Cloud Foundry Foundation. Abby Kearns has accepted an executive role with another organization, to be announced. This is a very exciting opportunity for Abby, and all of us on the foundation’s staff and directors are extremely happy for her. Abby has been leading the foundation for several years through quite a bit of change in our project, our community, and the broader market. She’s not going far, but she will be missed.

We also announced that Paul Fazzone, SVP Tanzu R&D at VMware, has been elected to chair the board of directors. Paul has been a strong advocate and supporter of the foundation, having served as Treasurer for the foundation and as a director for several years now. Paul is taking over the role of chair from John Roese, who has been a steady hand from the organization’s inception. I am looking forward to working much more closely with Paul as we push the organization forward into the future. 

Our focus as a community has always been to make developers’ lives easier, and each of you has played a part in the long list of user success stories. Even today, as society grapples with the incredible challenge of a global pandemic, I am reminded of the incredible value of the work this community does. Organizations from around the world that have adopted Cloud Foundry are using it to respond in these trying times, each in their own way. National governments have used the Cloud Foundry platform to rapidly build, deploy and scale software that is helping their citizens get information and register for economic support. Countless corporations are using Cloud Foundry to both support their customers in new ways and do their part for the greater good. These responses have required actions measured in days and hours, not weeks and months. In short, this community’s efforts over the years have built something worthing being truly proud of.

This community is also one that has managed to continuously evolve the architecture of the platform through several major cycles of change. Today is no different, as we have come together on the shared mission of bringing the Cloud Foundry developer experience to Kubernetes clusters everywhere. 

As the ancient Greek philosopher, Heraclitus said, “Change is the only constant in life.” Our community embraces that way of thinking, both for the Cloud Foundry project itself and when considering how to continue to enhance the developer experience provided by the platform. Ultimately, the core Cloud Foundry function cf-push will remain well into the future, and its architecture will continue to evolve.

I’m sure many of you have questions about these changes, and I welcome the opportunity to answer them. Feel free to email me directly ( cchilders@... ), or join us for a slack-based AMA this Thursday, April 8th, from 8-10 AM PST on the Cloud Foundry community’s slack instance in the #cff-forum channel. I will be happy to discuss the transition, the future of the Foundation and respond to any comments or questions you may have.

-chip

Chip Childers

Executive Director

Cloud Foundry Foundation