Date   

cf-for-k8s 0.2.0 alpha release

Saikiran Yerram
 

Hello CF community,

We just shipped cf-for-k8s 0.2.0 alpha release, so please check out the release notes here. Some notable highlights of this release,

- Users can now see streaming logs during cf push command. woot!
- Users can now see app metrics.
- Removed install.sh so users have the freedom to use ytt and kapp however they like (e.g. pass additional config of their choice)

There are many other updates worth looking into. Please take it for a spin and give us your feedback via issues or in slack channel #cf-for-k8s. 

Thank you to all the contributors!! 

Resources:

--
Saikiran Yerram


IMPORTANT NOTICE: [nodejs-buildpack] End of Support for Node.js versions 13.x after 2020-06-04

Kashyap Vedurmudi
 

The first release of the Node.js buildpack after 2020-06-04 will no longer include Node.js versions 13.x. These Node.js versions will no longer be supported upstream.[1] Please migrate your Node.js apps to supported versions of Node.js before that time.


As always, the buildpacks team is happy to answer questions you may have about this deprecation in the #buildpacks Slack channel[2].


[1] - https://github.com/nodejs/Release

[2] - https://cloudfoundry.slack.com/archives/C02HWMDUQ


Thanks,

Kashyap Vedurmudi, Buildpacks PM



Re: Deployment of HDI in US10 fails

Jonathan Matthews <contact+cfdev@...>
 

Hi Vidhya,

I’m afraid I’ve never heard of most of these terms in Cloud Foundry context! 

After a bit of googling, assuming they’re terms as they’re being used here (
https://blogs.sap.com/2018/02/05/building-multi-target-applications-mta-for-cloud-foundry-using-your-favorite-ide/), this sounds like a very provider-specific issue, and one which you should route to your commercial CF provider in the first instance. 

J

On Mon, 4 May 2020 at 19:58, A N, Sri Vidhya <sri.vidhya.a.n@...> wrote:

Hi,

 

We are trying to deploy HDI mta to US10 and we encounter the below issue.

 

The service created for hdi has parameters defined for schema and databaseid.

 

The same mta was deployed on EU10 successfully.

 

Caused by: org.cloudfoundry.client.v2.ClientV2Exception: CF-ServiceFetchInstanceParametersNotSupported(120004): This service does not support fetching service instance parameters.
    at org.cloudfoundry.reactor.util.ErrorPayloadMappers.lambda$null$0(ErrorPayloadMappers.java:47)
    Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Assembly trace from producer [reactor.core.publisher.MonoFlatMap] :
    reactor.core.publisher.Mono.checkpoint(Mono.java:1863)
    org.cloudfoundry.reactor.client.v2.serviceinstances.ReactorServiceInstances.getParameters(ReactorServiceInstances.java:94)
Error has been observed at the following site(s):
    |_ Mono.checkpoint ? at org.cloudfoundry.reactor.client.v2.serviceinstances.ReactorServiceInstances.getParameters(ReactorServiceInstances.java:94)
Stack trace:
        at org.cloudfoundry.reactor.util.ErrorPayloadMappers.lambda$null$0(ErrorPayloadMappers.java:47)

 

Could you please help us troubleshoot the issue.

 

Thank You

Regards

Vidhya

 

--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html


Deployment of HDI in US10 fails

A N, Sri Vidhya <sri.vidhya.a.n@...>
 

Hi,

 

We are trying to deploy HDI mta to US10 and we encounter the below issue.

 

The service created for hdi has parameters defined for schema and databaseid.

 

The same mta was deployed on EU10 successfully.

 

Caused by: org.cloudfoundry.client.v2.ClientV2Exception: CF-ServiceFetchInstanceParametersNotSupported(120004): This service does not support fetching service instance parameters.
    at org.cloudfoundry.reactor.util.ErrorPayloadMappers.lambda$null$0(ErrorPayloadMappers.java:47)
    Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Assembly trace from producer [reactor.core.publisher.MonoFlatMap] :
    reactor.core.publisher.Mono.checkpoint(Mono.java:1863)
    org.cloudfoundry.reactor.client.v2.serviceinstances.ReactorServiceInstances.getParameters(ReactorServiceInstances.java:94)
Error has been observed at the following site(s):
    |_ Mono.checkpoint ? at org.cloudfoundry.reactor.client.v2.serviceinstances.ReactorServiceInstances.getParameters(ReactorServiceInstances.java:94)
Stack trace:
        at org.cloudfoundry.reactor.util.ErrorPayloadMappers.lambda$null$0(ErrorPayloadMappers.java:47)

 

Could you please help us troubleshoot the issue.

 

Thank You

Regards

Vidhya

 


Re: Removing bits-service from cf-deployment

Thun, Philipp
 

Hi,

 

I don’t think that using bits-service with the mentioned ops files will work. In fact support for bits-service is broken since cf-deployment v12.39 (incl. CAPI v1.92, more precisely commit https://github.com/cloudfoundry/cloud_controller_ng/commit/66fb2bd434656e8caa060ff55e6c87a296ab1455 that adds a new method which is not implemented in the Ruby BitsService::Client class). Is our observation correct or are we doing something wrong when setting up a current version of cf-d with bits-service?

 

Thanks,

Philipp

 


Re: Is anyone working on a CF CRD & Controller?

pierre Oblin
 

Just as inspiration, and maybe spike implémentation, a déclarative approach based on terraform HCL is probably a good way to start

Le mar. 28 avr. 2020 à 19:18, Zach Robinson <zrobinson@...> a écrit :
Hey Daniel,

Wanted to follow up. There's now a doc to start building out our understanding of CRDs here https://docs.google.com/document/d/1mIMH4uEtIJkZjVa5mKWJoIAIeVyM4gVqO-Cx5JtYgtE/edit?usp=sharing

Shared with the mailing list under topic "Exploring CRDs in CF".  Would love to get your thoughts and feedback.

-Zach

On Thu, Apr 16, 2020 at 4:09 PM Zach Robinson <zrobinson@...> wrote:
Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

Yes, this is the current approach for the CRDs that Cloud Controller interacts with now. There are also reconciliation loops that we run for these resources analogous to how we've always reconciled CCDB state with Diego.

I think this method has developed organically from our goal of preserving in-place workflows via having the same API surface, allowing cli to function without changes, while trying to consume existing functionality in k8s. I think the longer term goal here is to review that usage and be more intentional about how we expect CRDs to fit into the system as a whole.

-Zach

On Thu, Apr 16, 2020 at 4:10 AM Daniel Jones <daniel.jones@...> wrote:
Thanks for that folks - especially for such a long and detailed response, Zach. Much appreciated.

It's great that folks are already thinking about this.

Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

I'd kinda imagined things going the other way around, introducing the CRDs as a new user interface, and have the controllers do the diff and then post/put to CloudController. The intention here would be saving Kubes-native folks (and CI servers!) from having to deal with the imperative interface. I was working on the assumption that all CF concepts would be exposed as CRDs.

From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well.

I'd always dodged this area in cf-converger as it was the most complicated, and the biggest break from the current CF experience :)

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

I can imagine that the logical concept of orgs may one day map onto distinct Kubernetes namespaces, but I hadn't imagined that orgs would in any way disappear, or not be configurable via the Kubernetes approach.

It'd be great to hear what others think on all of this.

Thanks again for sharing, Keshav and Zach.

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


On Wed, 15 Apr 2020 at 23:45, Zach Robinson <zrobinson@...> wrote:
Hey Daniel,

Thanks for starting a convo. The timing couldn't be better. I can share some of the thinking going on in both CAPI and VMware land. 

But first and foremost I want to address the question: "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?" - yes, yes, a thousand times yes to community collaboration!

The topic of CRDs is kind of huge. It's really great to hear your focus is on things like orgs/spaces. From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well. There's a lot of ground to cover clearly.

In terms of things that are in flight now.
  • Keshav kindly shared that networking is looking to provide Route CRDs.
  • Networking is also exploring providing Security Groups as CRDs.
  • CAPI is integrating kpack into CF to provide buildpack staging. This is done by generating kpack CRDs.
Currently these CRDs are being created and owned by the Cloud Controller, which enables us to present backward compatible APIs to our CLI and UI like stratos, while moving the implementation down into controllers fronted by CRDs.  There's an obvious potential to interact with k8s directly in the future, but the current use case is to be used by CC. Except for kpack which is an excellent stand alone tool already :).  

These efforts are great and are allowing us to begin a path towards using existing k8s tooling and projects to provide Cloud Foundry outcomes, but obviously there's a lot further to go.

From VMware's side, over the last couple weeks, there has been an effort to explore what it might look like to use CRDs entirely as a source of truth for *all* CF data, in place of a SQL database, as a learning exercise, not necessarily a desired outcome. The primary goal of that effort was to start the convo that we're having now, and to be able to contribute in a meaningful way.  Note there are no VMware-based plans to dump a fully fledged proposal. We need to start from a premise as a community of understanding how/why/and which resources are valuable as CRDs.

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

I think we'll need to start some dedicated working document to collaborate in. I had planned on facilitating that after some of the investigation that VMware has wraps up, but I don't think that's a reason to hold off if you or somebody else in the community has thoughts they want to start getting down. CAPI and other teams can contribute to an existing doc if that makes sense. Any other thoughts you'd prefer for next steps?

Looking forward to a continued conversation.

-Zach


On Wed, Apr 15, 2020 at 9:56 AM Keshav Sharma <ksharma@...> wrote:
Hi Daniel, 
The CF-K8s Networking team is currently working on a solution using Route CRDto 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
EngineerBetter Ltd - More than cloud platform specialists


Release Integration No Longer Testing CATs on BOSH Lite

Dave Walter <dwalter@...>
 

Hi All,

The CF Release Integration team wanted to give y'all a heads up that we have decided to stop running CATs on our BOSH lite CI environment due to its flakey nature and the time wasted debugging.

Going forward, we are only validating new changes on BOSH lite by running smoke-tests. Please feel free to reach out if you have any questions.

Regards,
Dave


Re: Is anyone working on a CF CRD & Controller?

Vlad Iovanov
 

On the Quarks team we’ve been working with CRDs for some time and we’d like to socialize with other teams doing similar work.

Maybe we could setup a slack channel specific to this?

Cheers,

Vlad

 

From: Daniel Jones
Sent: Friday, May 1, 2020 1:31 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] Is anyone working on a CF CRD & Controller?

 

Ta! I've been on full-time billable work with customers all week, but I'll take a look now.


Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

EngineerBetter Ltd - More than cloud platform specialists

 

 

On Tue, 28 Apr 2020 at 18:17, Zach Robinson <zrobinson@...> wrote:

Hey Daniel,

 

Wanted to follow up. There's now a doc to start building out our understanding of CRDs here https://docs.google.com/document/d/1mIMH4uEtIJkZjVa5mKWJoIAIeVyM4gVqO-Cx5JtYgtE/edit?usp=sharing

 

Shared with the mailing list under topic "Exploring CRDs in CF".  Would love to get your thoughts and feedback.

 

-Zach

 

On Thu, Apr 16, 2020 at 4:09 PM Zach Robinson <zrobinson@...> wrote:

Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

 

Yes, this is the current approach for the CRDs that Cloud Controller interacts with now. There are also reconciliation loops that we run for these resources analogous to how we've always reconciled CCDB state with Diego.

 

I think this method has developed organically from our goal of preserving in-place workflows via having the same API surface, allowing cli to function without changes, while trying to consume existing functionality in k8s. I think the longer term goal here is to review that usage and be more intentional about how we expect CRDs to fit into the system as a whole.

 

-Zach

 

On Thu, Apr 16, 2020 at 4:10 AM Daniel Jones <daniel.jones@...> wrote:

Thanks for that folks - especially for such a long and detailed response, Zach. Much appreciated.

 

It's great that folks are already thinking about this.

 

Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

 

I'd kinda imagined things going the other way around, introducing the CRDs as a new user interface, and have the controllers do the diff and then post/put to CloudController. The intention here would be saving Kubes-native folks (and CI servers!) from having to deal with the imperative interface. I was working on the assumption that all CF concepts would be exposed as CRDs.

 

From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well.

 

I'd always dodged this area in cf-converger as it was the most complicated, and the biggest break from the current CF experience :)

 

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

 

I can imagine that the logical concept of orgs may one day map onto distinct Kubernetes namespaces, but I hadn't imagined that orgs would in any way disappear, or not be configurable via the Kubernetes approach.

 

It'd be great to hear what others think on all of this.

Thanks again for sharing, Keshav and Zach.


Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

EngineerBetter Ltd - More than cloud platform specialists

 

 

On Wed, 15 Apr 2020 at 23:45, Zach Robinson <zrobinson@...> wrote:

Hey Daniel,

 

Thanks for starting a convo. The timing couldn't be better. I can share some of the thinking going on in both CAPI and VMware land. 

 

But first and foremost I want to address the question: "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?" - yes, yes, a thousand times yes to community collaboration!

 

The topic of CRDs is kind of huge. It's really great to hear your focus is on things like orgs/spaces. From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well. There's a lot of ground to cover clearly.

 

In terms of things that are in flight now.

  • Keshav kindly shared that networking is looking to provide Route CRDs.
  • Networking is also exploring providing Security Groups as CRDs.
  • CAPI is integrating kpack into CF to provide buildpack staging. This is done by generating kpack CRDs.

Currently these CRDs are being created and owned by the Cloud Controller, which enables us to present backward compatible APIs to our CLI and UI like stratos, while moving the implementation down into controllers fronted by CRDs.  There's an obvious potential to interact with k8s directly in the future, but the current use case is to be used by CC. Except for kpack which is an excellent stand alone tool already :).  

 

These efforts are great and are allowing us to begin a path towards using existing k8s tooling and projects to provide Cloud Foundry outcomes, but obviously there's a lot further to go.

 

From VMware's side, over the last couple weeks, there has been an effort to explore what it might look like to use CRDs entirely as a source of truth for *all* CF data, in place of a SQL database, as a learning exercise, not necessarily a desired outcome. The primary goal of that effort was to start the convo that we're having now, and to be able to contribute in a meaningful way.  Note there are no VMware-based plans to dump a fully fledged proposal. We need to start from a premise as a community of understanding how/why/and which resources are valuable as CRDs.

 

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

 

I think we'll need to start some dedicated working document to collaborate in. I had planned on facilitating that after some of the investigation that VMware has wraps up, but I don't think that's a reason to hold off if you or somebody else in the community has thoughts they want to start getting down. CAPI and other teams can contribute to an existing doc if that makes sense. Any other thoughts you'd prefer for next steps?

 

Looking forward to a continued conversation.

 

-Zach

 

 

On Wed, Apr 15, 2020 at 9:56 AM Keshav Sharma <ksharma@...> wrote:

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

EngineerBetter Ltd - More than cloud platform specialists

 


Re: Stepping down as CF Extension PMC lead and a small TBT present

Daniel Jones
 

Thanks Max - it brought a smile to my face to go over those photos and see all the friends I've had the opportunity to make in the ecosystem, and remember the fun times at conferences.

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


On Fri, 1 May 2020 at 09:54, Krannich, Bernd <bernd.krannich@...> wrote:

Hi Dr. Max,

 

Sad to see you stepping down as Extensions PMC lead. Thank you very much for all you have done for the CF community!

 

I’m hopeful that one day in the (hopefully not too distant) future we’ll again bump into each other at one of the great open source conferences somewhere in the world so that we can hang out together.

 

All the best,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

 

 

From: <cf-dev@...> on behalf of Swarna Podila <spodila@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Friday, 1. May 2020 at 01:16
To: Dr Nic Williams <drnicwilliams@...>
Cc: CF Developers Mailing List <cf-dev@...>, cf-extensions-pmc <cf-extensions-pmc@...>
Subject: Re: [cf-dev] Stepping down as CF Extension PMC lead and a small TBT present

 

Hi Dr. Max,

 

Your presence is invaluable to our community.  I can only name a few hats you wore over the years, but all the roles you've taken on helped us immensely in shaping our community! 

  • hosting Community Call 
  • leading the Extensions-PMC 
  • supporting us immensely for Hackathons at Summit
  • advocating Cloud Foundry technology in our community and within the broader open source community 
  • representing our community everywhere
  • being a true Cloud Foundry Ambassador!
  • capturing all the amazing memories and sharing the pictures with us
  • ...and so many more.

 

Thank you so much for all your contributions and efforts.  We genuinely and sincerely thank you.

 

 

-- 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.

 

 

On Thu, Apr 30, 2020 at 3:47 PM Dr Nic Williams <drnicwilliams@...> wrote:

Thanks Dr Max for everything you’ve done — and all the photos!

 

Dr Nic

 

On Fri, 1 May 2020 at 8:33 am, Michael Maximilien <maxim@...> wrote:






Hi, all,


After four years (almost) at the helm of CF Extensions, I am announcing that I am stepping down as the lead. I believe the time is ripe as CF is transitioning to new waters and since I am less involved with the projects these days, it's time for someone else to take over and steer us to greener pastures.


I took on the CF Extensions lead role when none existed at the end of 2016. I remember, like yesterday, when Sam asked me to start an Extensions PMC for Cloud Foundry during our summit in Frankfurt. Since then, we have added close to 20 extensions projects with many having graduated and a few fading away. Exactly what we envisioned, so for that I am happy and thankful to your participation and contributions.


Overall, I feel positive and hopeful that better days are ahead for CF and this community. You have a vibrant group of contributors and excellent committed leadership in the Cloud Foundry Foundation. I will miss the kindness, brersity, and excellence that this community has always strived to achieve and uphold.


That said, I will not be far away. I am still involved in OSS for IBM and will be happy to help in any way I can, when you need me. Swarna will be sending a separate email to look for volunteers and elect a leader.


-----
With that, my little TBT present to you are the following curated photographs I have taken of you during our time together at the many CF Summits, CF days, and events all across the world.


From some of the first CF Summit NA: Santa Clara in
2015-16-17; to CF Summit Asia in Shanghai 2016; to CF Days: Pune, India 2016, Misk, Belarus 2016, London 2018, NY 2018, and Copenhagen 2018; to CF Summit Europe: Frankfurt 2016, Basel 2017-2018, Den Haag 2019; and most recently CF Summit NA: Boston 2018 and Philadelphia 2019.


You've often seen me with a camera in hand shooting away. So here's the main reason, to allow us to remember, to look back, and to reminisce a bit on the great memories, fun times, and lasting friendships we have forged in this community. With that, here are two curated sets of what I believe are my most memorable and best 150 photographs of Cloud Foundry community events and members. Hope you like:


50 B&amp;W:
https://photos.app.goo.gl/JUHVSRCKc9SrvuZD8
100 Color:
https://photos.app.goo.gl/mAarRq8QvAWm8Mki6


PS: While I took care to select the best photos, I can fully understand if there is a photo of you, or that you are in a photo, that you do not like or rather I not share. Please let me know and I will remove ASAP.
Also, to respect the privacy of all, I ask you to get permissions before re-sharing, of course, if the photograph includes someone other than yourself. In my experience most people agree, so just ask.

--

Dr Nic Williams

Stark & Wayne LLC

+61 437 276 076

twitter @drnic

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/CAM-_pPbYBdugvoaq4achwtKb_Pbb2_X0wFjy6Hsm8rtVfb9Gjg%40mail.gmail.com.


Re: Is anyone working on a CF CRD & Controller?

Daniel Jones
 

Ta! I've been on full-time billable work with customers all week, but I'll take a look now.

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


On Tue, 28 Apr 2020 at 18:17, Zach Robinson <zrobinson@...> wrote:
Hey Daniel,

Wanted to follow up. There's now a doc to start building out our understanding of CRDs here https://docs.google.com/document/d/1mIMH4uEtIJkZjVa5mKWJoIAIeVyM4gVqO-Cx5JtYgtE/edit?usp=sharing

Shared with the mailing list under topic "Exploring CRDs in CF".  Would love to get your thoughts and feedback.

-Zach

On Thu, Apr 16, 2020 at 4:09 PM Zach Robinson <zrobinson@...> wrote:
Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

Yes, this is the current approach for the CRDs that Cloud Controller interacts with now. There are also reconciliation loops that we run for these resources analogous to how we've always reconciled CCDB state with Diego.

I think this method has developed organically from our goal of preserving in-place workflows via having the same API surface, allowing cli to function without changes, while trying to consume existing functionality in k8s. I think the longer term goal here is to review that usage and be more intentional about how we expect CRDs to fit into the system as a whole.

-Zach

On Thu, Apr 16, 2020 at 4:10 AM Daniel Jones <daniel.jones@...> wrote:
Thanks for that folks - especially for such a long and detailed response, Zach. Much appreciated.

It's great that folks are already thinking about this.

Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

I'd kinda imagined things going the other way around, introducing the CRDs as a new user interface, and have the controllers do the diff and then post/put to CloudController. The intention here would be saving Kubes-native folks (and CI servers!) from having to deal with the imperative interface. I was working on the assumption that all CF concepts would be exposed as CRDs.

From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well.

I'd always dodged this area in cf-converger as it was the most complicated, and the biggest break from the current CF experience :)

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

I can imagine that the logical concept of orgs may one day map onto distinct Kubernetes namespaces, but I hadn't imagined that orgs would in any way disappear, or not be configurable via the Kubernetes approach.

It'd be great to hear what others think on all of this.

Thanks again for sharing, Keshav and Zach.

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


On Wed, 15 Apr 2020 at 23:45, Zach Robinson <zrobinson@...> wrote:
Hey Daniel,

Thanks for starting a convo. The timing couldn't be better. I can share some of the thinking going on in both CAPI and VMware land. 

But first and foremost I want to address the question: "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?" - yes, yes, a thousand times yes to community collaboration!

The topic of CRDs is kind of huge. It's really great to hear your focus is on things like orgs/spaces. From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well. There's a lot of ground to cover clearly.

In terms of things that are in flight now.
  • Keshav kindly shared that networking is looking to provide Route CRDs.
  • Networking is also exploring providing Security Groups as CRDs.
  • CAPI is integrating kpack into CF to provide buildpack staging. This is done by generating kpack CRDs.
Currently these CRDs are being created and owned by the Cloud Controller, which enables us to present backward compatible APIs to our CLI and UI like stratos, while moving the implementation down into controllers fronted by CRDs.  There's an obvious potential to interact with k8s directly in the future, but the current use case is to be used by CC. Except for kpack which is an excellent stand alone tool already :).  

These efforts are great and are allowing us to begin a path towards using existing k8s tooling and projects to provide Cloud Foundry outcomes, but obviously there's a lot further to go.

From VMware's side, over the last couple weeks, there has been an effort to explore what it might look like to use CRDs entirely as a source of truth for *all* CF data, in place of a SQL database, as a learning exercise, not necessarily a desired outcome. The primary goal of that effort was to start the convo that we're having now, and to be able to contribute in a meaningful way.  Note there are no VMware-based plans to dump a fully fledged proposal. We need to start from a premise as a community of understanding how/why/and which resources are valuable as CRDs.

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

I think we'll need to start some dedicated working document to collaborate in. I had planned on facilitating that after some of the investigation that VMware has wraps up, but I don't think that's a reason to hold off if you or somebody else in the community has thoughts they want to start getting down. CAPI and other teams can contribute to an existing doc if that makes sense. Any other thoughts you'd prefer for next steps?

Looking forward to a continued conversation.

-Zach


On Wed, Apr 15, 2020 at 9:56 AM Keshav Sharma <ksharma@...> wrote:
Hi Daniel, 
The CF-K8s Networking team is currently working on a solution using Route CRDto 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
EngineerBetter Ltd - More than cloud platform specialists


Re: Stepping down as CF Extension PMC lead and a small TBT present

Krannich, Bernd
 

Hi Dr. Max,

 

Sad to see you stepping down as Extensions PMC lead. Thank you very much for all you have done for the CF community!

 

I’m hopeful that one day in the (hopefully not too distant) future we’ll again bump into each other at one of the great open source conferences somewhere in the world so that we can hang out together.

 

All the best,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

 

 

From: <cf-dev@...> on behalf of Swarna Podila <spodila@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Friday, 1. May 2020 at 01:16
To: Dr Nic Williams <drnicwilliams@...>
Cc: CF Developers Mailing List <cf-dev@...>, cf-extensions-pmc <cf-extensions-pmc@...>
Subject: Re: [cf-dev] Stepping down as CF Extension PMC lead and a small TBT present

 

Hi Dr. Max,

 

Your presence is invaluable to our community.  I can only name a few hats you wore over the years, but all the roles you've taken on helped us immensely in shaping our community! 

  • hosting Community Call 
  • leading the Extensions-PMC 
  • supporting us immensely for Hackathons at Summit
  • advocating Cloud Foundry technology in our community and within the broader open source community 
  • representing our community everywhere
  • being a true Cloud Foundry Ambassador!
  • capturing all the amazing memories and sharing the pictures with us
  • ...and so many more.

 

Thank you so much for all your contributions and efforts.  We genuinely and sincerely thank you.

 

 

-- 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.

 

 

On Thu, Apr 30, 2020 at 3:47 PM Dr Nic Williams <drnicwilliams@...> wrote:

Thanks Dr Max for everything you’ve done — and all the photos!

 

Dr Nic

 

On Fri, 1 May 2020 at 8:33 am, Michael Maximilien <maxim@...> wrote:






Hi, all,


After four years (almost) at the helm of CF Extensions, I am announcing that I am stepping down as the lead. I believe the time is ripe as CF is transitioning to new waters and since I am less involved with the projects these days, it's time for someone else to take over and steer us to greener pastures.


I took on the CF Extensions lead role when none existed at the end of 2016. I remember, like yesterday, when Sam asked me to start an Extensions PMC for Cloud Foundry during our summit in Frankfurt. Since then, we have added close to 20 extensions projects with many having graduated and a few fading away. Exactly what we envisioned, so for that I am happy and thankful to your participation and contributions.


Overall, I feel positive and hopeful that better days are ahead for CF and this community. You have a vibrant group of contributors and excellent committed leadership in the Cloud Foundry Foundation. I will miss the kindness, brersity, and excellence that this community has always strived to achieve and uphold.


That said, I will not be far away. I am still involved in OSS for IBM and will be happy to help in any way I can, when you need me. Swarna will be sending a separate email to look for volunteers and elect a leader.


-----
With that, my little TBT present to you are the following curated photographs I have taken of you during our time together at the many CF Summits, CF days, and events all across the world.


From some of the first CF Summit NA: Santa Clara in
2015-16-17; to CF Summit Asia in Shanghai 2016; to CF Days: Pune, India 2016, Misk, Belarus 2016, London 2018, NY 2018, and Copenhagen 2018; to CF Summit Europe: Frankfurt 2016, Basel 2017-2018, Den Haag 2019; and most recently CF Summit NA: Boston 2018 and Philadelphia 2019.


You've often seen me with a camera in hand shooting away. So here's the main reason, to allow us to remember, to look back, and to reminisce a bit on the great memories, fun times, and lasting friendships we have forged in this community. With that, here are two curated sets of what I believe are my most memorable and best 150 photographs of Cloud Foundry community events and members. Hope you like:


50 B&amp;W:
https://photos.app.goo.gl/JUHVSRCKc9SrvuZD8
100 Color:
https://photos.app.goo.gl/mAarRq8QvAWm8Mki6


PS: While I took care to select the best photos, I can fully understand if there is a photo of you, or that you are in a photo, that you do not like or rather I not share. Please let me know and I will remove ASAP.
Also, to respect the privacy of all, I ask you to get permissions before re-sharing, of course, if the photograph includes someone other than yourself. In my experience most people agree, so just ask.

--

Dr Nic Williams

Stark & Wayne LLC

+61 437 276 076

twitter @drnic

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/CAM-_pPbYBdugvoaq4achwtKb_Pbb2_X0wFjy6Hsm8rtVfb9Gjg%40mail.gmail.com.


Seeking Nominations: Cloud Foundry Extensions PMC

Swarna Podila
 

Hi All,
You may have seen Dr. Max's note earlier.  After leading Extensions PMC for almost four years, he would like to step down and make space for new folks to take on the role. 

Please send in your nominations for a new lead for Cloud Foundry Extensions PMC by the end of day next Friday, May 8, 2020. 

-- 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: Stepping down as CF Extension PMC lead and a small TBT present

Swarna Podila
 

Hi Dr. Max,

Your presence is invaluable to our community.  I can only name a few hats you wore over the years, but all the roles you've taken on helped us immensely in shaping our community! 
  • hosting Community Call 
  • leading the Extensions-PMC 
  • supporting us immensely for Hackathons at Summit
  • advocating Cloud Foundry technology in our community and within the broader open source community 
  • representing our community everywhere
  • being a true Cloud Foundry Ambassador!
  • capturing all the amazing memories and sharing the pictures with us
  • ...and so many more.

Thank you so much for all your contributions and efforts.  We genuinely and sincerely thank you.


-- 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.


On Thu, Apr 30, 2020 at 3:47 PM Dr Nic Williams <drnicwilliams@...> wrote:
Thanks Dr Max for everything you’ve done — and all the photos!

Dr Nic

On Fri, 1 May 2020 at 8:33 am, Michael Maximilien <maxim@...> wrote:






Hi, all,


After four years (almost) at the helm of CF Extensions, I am announcing that I am stepping down as the lead. I believe the time is ripe as CF is transitioning to new waters and since I am less involved with the projects these days, it's time for someone else to take over and steer us to greener pastures.


I took on the CF Extensions lead role when none existed at the end of 2016. I remember, like yesterday, when Sam asked me to start an Extensions PMC for Cloud Foundry during our summit in Frankfurt. Since then, we have added close to 20 extensions projects with many having graduated and a few fading away. Exactly what we envisioned, so for that I am happy and thankful to your participation and contributions.


Overall, I feel positive and hopeful that better days are ahead for CF and this community. You have a vibrant group of contributors and excellent committed leadership in the Cloud Foundry Foundation. I will miss the kindness, brersity, and excellence that this community has always strived to achieve and uphold.


That said, I will not be far away. I am still involved in OSS for IBM and will be happy to help in any way I can, when you need me. Swarna will be sending a separate email to look for volunteers and elect a leader.


-----
With that, my little TBT present to you are the following curated photographs I have taken of you during our time together at the many CF Summits, CF days, and events all across the world.


From some of the first CF Summit NA: Santa Clara in
2015-16-17; to CF Summit Asia in Shanghai 2016; to CF Days: Pune, India 2016, Misk, Belarus 2016, London 2018, NY 2018, and Copenhagen 2018; to CF Summit Europe: Frankfurt 2016, Basel 2017-2018, Den Haag 2019; and most recently CF Summit NA: Boston 2018 and Philadelphia 2019.


You've often seen me with a camera in hand shooting away. So here's the main reason, to allow us to remember, to look back, and to reminisce a bit on the great memories, fun times, and lasting friendships we have forged in this community. With that, here are two curated sets of what I believe are my most memorable and best 150 photographs of Cloud Foundry community events and members. Hope you like:


50 B&amp;W:
https://photos.app.goo.gl/JUHVSRCKc9SrvuZD8
100 Color:
https://photos.app.goo.gl/mAarRq8QvAWm8Mki6


PS: While I took care to select the best photos, I can fully understand if there is a photo of you, or that you are in a photo, that you do not like or rather I not share. Please let me know and I will remove ASAP.
Also, to respect the privacy of all, I ask you to get permissions before re-sharing, of course, if the photograph includes someone other than yourself. In my experience most people agree, so just ask.


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

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/CAM-_pPbYBdugvoaq4achwtKb_Pbb2_X0wFjy6Hsm8rtVfb9Gjg%40mail.gmail.com.


Re: Stepping down as CF Extension PMC lead and a small TBT present

Jeff Hobbs <jeff.hobbs@...>
 

Thanks Dr. Max for the years steering the extensions PMC to greener pastures!

On Apr 30, 2020, at 3:33 PM, Michael Maximilien <maxim@us.ibm.com> wrote:

Hi, all,


After four years (almost) at the helm of CF Extensions, I am announcing that I am stepping down as the lead. I believe the time is ripe as CF is transitioning to new waters and since I am less involved with the projects these days, it's time for someone else to take over and steer us to greener pastures.


I took on the CF Extensions lead role when none existed at the end of 2016. I remember, like yesterday, when Sam asked me to start an Extensions PMC for Cloud Foundry during our summit in Frankfurt. Since then, we have added close to 20 extensions projects with many having graduated and a few fading away. Exactly what we envisioned, so for that I am happy and thankful to your participation and contributions.


Overall, I feel positive and hopeful that better days are ahead for CF and this community. You have a vibrant group of contributors and excellent committed leadership in the Cloud Foundry Foundation. I will miss the kindness, brersity, and excellence that this community has always strived to achieve and uphold.


That said, I will not be far away. I am still involved in OSS for IBM and will be happy to help in any way I can, when you need me. Swarna will be sending a separate email to look for volunteers and elect a leader.


-----
With that, my little TBT present to you are the following curated photographs I have taken of you during our time together at the many CF Summits, CF days, and events all across the world.


From some of the first CF Summit NA: Santa Clara in
2015-16-17; to CF Summit Asia in Shanghai 2016; to CF Days: Pune, India 2016, Misk, Belarus 2016, London 2018, NY 2018, and Copenhagen 2018; to CF Summit Europe: Frankfurt 2016, Basel 2017-2018, Den Haag 2019; and most recently CF Summit NA: Boston 2018 and Philadelphia 2019.


You've often seen me with a camera in hand shooting away. So here's the main reason, to allow us to remember, to look back, and to reminisce a bit on the great memories, fun times, and lasting friendships we have forged in this community. With that, here are two curated sets of what I believe are my most memorable and best 150 photographs of Cloud Foundry community events and members. Hope you like:


50 B&W:
https://photos.app.goo.gl/JUHVSRCKc9SrvuZD8
100 Color:
https://photos.app.goo.gl/mAarRq8QvAWm8Mki6


PS: While I took care to select the best photos, I can fully understand if there is a photo of you, or that you are in a photo, that you do not like or rather I not share. Please let me know and I will remove ASAP.
Also, to respect the privacy of all, I ask you to get permissions before re-sharing, of course, if the photograph includes someone other than yourself. In my experience most people agree, so just ask.


Re: Stepping down as CF Extension PMC lead and a small TBT present

Dr Nic Williams <drnicwilliams@...>
 

Thanks Dr Max for everything you’ve done — and all the photos!

Dr Nic

On Fri, 1 May 2020 at 8:33 am, Michael Maximilien <maxim@...> wrote:






Hi, all,


After four years (almost) at the helm of CF Extensions, I am announcing that I am stepping down as the lead. I believe the time is ripe as CF is transitioning to new waters and since I am less involved with the projects these days, it's time for someone else to take over and steer us to greener pastures.


I took on the CF Extensions lead role when none existed at the end of 2016. I remember, like yesterday, when Sam asked me to start an Extensions PMC for Cloud Foundry during our summit in Frankfurt. Since then, we have added close to 20 extensions projects with many having graduated and a few fading away. Exactly what we envisioned, so for that I am happy and thankful to your participation and contributions.


Overall, I feel positive and hopeful that better days are ahead for CF and this community. You have a vibrant group of contributors and excellent committed leadership in the Cloud Foundry Foundation. I will miss the kindness, brersity, and excellence that this community has always strived to achieve and uphold.


That said, I will not be far away. I am still involved in OSS for IBM and will be happy to help in any way I can, when you need me. Swarna will be sending a separate email to look for volunteers and elect a leader.


-----
With that, my little TBT present to you are the following curated photographs I have taken of you during our time together at the many CF Summits, CF days, and events all across the world.


From some of the first CF Summit NA: Santa Clara in
2015-16-17; to CF Summit Asia in Shanghai 2016; to CF Days: Pune, India 2016, Misk, Belarus 2016, London 2018, NY 2018, and Copenhagen 2018; to CF Summit Europe: Frankfurt 2016, Basel 2017-2018, Den Haag 2019; and most recently CF Summit NA: Boston 2018 and Philadelphia 2019.


You've often seen me with a camera in hand shooting away. So here's the main reason, to allow us to remember, to look back, and to reminisce a bit on the great memories, fun times, and lasting friendships we have forged in this community. With that, here are two curated sets of what I believe are my most memorable and best 150 photographs of Cloud Foundry community events and members. Hope you like:


50 B&amp;W:
https://photos.app.goo.gl/JUHVSRCKc9SrvuZD8
100 Color:
https://photos.app.goo.gl/mAarRq8QvAWm8Mki6


PS: While I took care to select the best photos, I can fully understand if there is a photo of you, or that you are in a photo, that you do not like or rather I not share. Please let me know and I will remove ASAP.
Also, to respect the privacy of all, I ask you to get permissions before re-sharing, of course, if the photograph includes someone other than yourself. In my experience most people agree, so just ask.


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


Stepping down as CF Extension PMC lead and a small TBT present

Michael Maximilien
 






Hi, all,


After four years (almost) at the helm of CF Extensions, I am announcing that I am stepping down as the lead. I believe the time is ripe as CF is transitioning to new waters and since I am less involved with the projects these days, it's time for someone else to take over and steer us to greener pastures.


I took on the CF Extensions lead role when none existed at the end of 2016. I remember, like yesterday, when Sam asked me to start an Extensions PMC for Cloud Foundry during our summit in Frankfurt. Since then, we have added close to 20 extensions projects with many having graduated and a few fading away. Exactly what we envisioned, so for that I am happy and thankful to your participation and contributions.


Overall, I feel positive and hopeful that better days are ahead for CF and this community. You have a vibrant group of contributors and excellent committed leadership in the Cloud Foundry Foundation. I will miss the kindness, brersity, and excellence that this community has always strived to achieve and uphold.


That said, I will not be far away. I am still involved in OSS for IBM and will be happy to help in any way I can, when you need me. Swarna will be sending a separate email to look for volunteers and elect a leader.


-----
With that, my little TBT present to you are the following curated photographs I have taken of you during our time together at the many CF Summits, CF days, and events all across the world.


From some of the first CF Summit NA: Santa Clara in
2015-16-17; to CF Summit Asia in Shanghai 2016; to CF Days: Pune, India 2016, Misk, Belarus 2016, London 2018, NY 2018, and Copenhagen 2018; to CF Summit Europe: Frankfurt 2016, Basel 2017-2018, Den Haag 2019; and most recently CF Summit NA: Boston 2018 and Philadelphia 2019.


You've often seen me with a camera in hand shooting away. So here's the main reason, to allow us to remember, to look back, and to reminisce a bit on the great memories, fun times, and lasting friendships we have forged in this community. With that, here are two curated sets of what I believe are my most memorable and best 150 photographs of Cloud Foundry community events and members. Hope you like:


50 B&amp;W:
https://photos.app.goo.gl/JUHVSRCKc9SrvuZD8
100 Color:
https://photos.app.goo.gl/mAarRq8QvAWm8Mki6


PS: While I took care to select the best photos, I can fully understand if there is a photo of you, or that you are in a photo, that you do not like or rather I not share. Please let me know and I will remove ASAP.
Also, to respect the privacy of all, I ask you to get permissions before re-sharing, of course, if the photograph includes someone other than yourself. In my experience most people agree, so just ask.



Removing bits-service from cf-deployment

James Pollard <jpollard@...>
 

Hi all,

As many of you may know, the discontinuation of bits-service was announced back in July of 2019.

We just wanted to give you all a heads up that we'll be removing the bits-service from cf-deployment in the upcoming v13 major release. After this removal, users who want to continue using bits-service will be able to do so by using the bits-service ops files from cf-d v12. (here's a link.)

⏰ If the removal of bits-service in cf-d v13 is likely to cause major headaches for you, please reach out to us ASAP❗️

Best,
release integration


FYI: Welcome “CF Backup & Restore” project to CF-Extensions

Michael Maximilien
 

Hi, all,

The CF Extensions PMC is glad to announce the acceptance of the “CF Backup &amp; Restore” plugin as the newest extension to Cloud Foundry.

With CF Backup &amp; Restore, users of Cloud Foundry can easily backup and restore their orgs, spaces, applications, and service bindings. The restoration can be into the same foundry or a different one.

The CF Backup &amp; Restore team has transitioned the project to the cf-incubator organization:

https://github.com/cloudfoundry-incubator/cf-plugin-backup

We invite you to engage with the team with questions in their Slack channel: #cf-backup-restore on the CloudFoundry slack.

In behalf of the project leaders:

Vlad Iovanov (SUSE)
Enrique Encalada (IBM)

--
dr.max Sent from my iPhone http://maximilien.org


Re: Announcing Cloud Foundry CLI v7 Release Plan

Stefan Mayr
 

Hi Josh

Am 27.04.2020 um 18:13 schrieb Josh Collins:
Dear Cloud Foundry Community,


We are nearing the completion of the v7 CF CLI and we’re excited to
announce that we’ll be cutting our GA release soon!
This is fantastic news. Our developers are waiting for some of the
experimental v3-commands to be replaced with stable CLI v7 commands.

The exact target date for the launch hasn’t been finalized but because
transitioning from v6 to v7 will require coordination and planning we’re
sending an initial heads up. We'll send follow ups to this communication
once the launch date and associated details become concrete.

 

In case you haven’t been following the development of the v7 CLI
closely, here’s three of many new capabilities that will become
available when v7 GAs:

*

Rolling Deploys
<https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html>using
the "--strategy" flag for "cf push" and other commands

*

Metadata
<https://docs.cloudfoundry.org/adminguide/metadata.html>apply labels
and annotations to apps, spaces, organizations, and other resources

*

Sidecar Processes
<https://docs.cloudfoundry.org/devguide/sidecars.html>for
applications using application manifests

...
How about manifest files? Do we have to expect any manifest syntax or
naming changes? Will some of the new CLI features also be available in
the manifest?

Thanks,

Stefan


Re: Is anyone working on a CF CRD & Controller?

Zach Robinson
 

Hey Daniel,

Wanted to follow up. There's now a doc to start building out our understanding of CRDs here https://docs.google.com/document/d/1mIMH4uEtIJkZjVa5mKWJoIAIeVyM4gVqO-Cx5JtYgtE/edit?usp=sharing

Shared with the mailing list under topic "Exploring CRDs in CF".  Would love to get your thoughts and feedback.

-Zach

On Thu, Apr 16, 2020 at 4:09 PM Zach Robinson <zrobinson@...> wrote:
Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

Yes, this is the current approach for the CRDs that Cloud Controller interacts with now. There are also reconciliation loops that we run for these resources analogous to how we've always reconciled CCDB state with Diego.

I think this method has developed organically from our goal of preserving in-place workflows via having the same API surface, allowing cli to function without changes, while trying to consume existing functionality in k8s. I think the longer term goal here is to review that usage and be more intentional about how we expect CRDs to fit into the system as a whole.

-Zach

On Thu, Apr 16, 2020 at 4:10 AM Daniel Jones <daniel.jones@...> wrote:
Thanks for that folks - especially for such a long and detailed response, Zach. Much appreciated.

It's great that folks are already thinking about this.

Zach, am I correct in thinking that the current approach is the have clients interact with CloudController, have CloudController persist to CCDB as per usual, and then CloudController post stuff to CRDs in the Kube API?

I'd kinda imagined things going the other way around, introducing the CRDs as a new user interface, and have the controllers do the diff and then post/put to CloudController. The intention here would be saving Kubes-native folks (and CI servers!) from having to deal with the imperative interface. I was working on the assumption that all CF concepts would be exposed as CRDs.

From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well.

I'd always dodged this area in cf-converger as it was the most complicated, and the biggest break from the current CF experience :)

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

I can imagine that the logical concept of orgs may one day map onto distinct Kubernetes namespaces, but I hadn't imagined that orgs would in any way disappear, or not be configurable via the Kubernetes approach.

It'd be great to hear what others think on all of this.

Thanks again for sharing, Keshav and Zach.

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


On Wed, 15 Apr 2020 at 23:45, Zach Robinson <zrobinson@...> wrote:
Hey Daniel,

Thanks for starting a convo. The timing couldn't be better. I can share some of the thinking going on in both CAPI and VMware land. 

But first and foremost I want to address the question: "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?" - yes, yes, a thousand times yes to community collaboration!

The topic of CRDs is kind of huge. It's really great to hear your focus is on things like orgs/spaces. From a CAPI perspective, I've been thinking more about representing apps and push as CRDs, and I believe the Eirini team has some thoughts in this area as well. There's a lot of ground to cover clearly.

In terms of things that are in flight now.
  • Keshav kindly shared that networking is looking to provide Route CRDs.
  • Networking is also exploring providing Security Groups as CRDs.
  • CAPI is integrating kpack into CF to provide buildpack staging. This is done by generating kpack CRDs.
Currently these CRDs are being created and owned by the Cloud Controller, which enables us to present backward compatible APIs to our CLI and UI like stratos, while moving the implementation down into controllers fronted by CRDs.  There's an obvious potential to interact with k8s directly in the future, but the current use case is to be used by CC. Except for kpack which is an excellent stand alone tool already :).  

These efforts are great and are allowing us to begin a path towards using existing k8s tooling and projects to provide Cloud Foundry outcomes, but obviously there's a lot further to go.

From VMware's side, over the last couple weeks, there has been an effort to explore what it might look like to use CRDs entirely as a source of truth for *all* CF data, in place of a SQL database, as a learning exercise, not necessarily a desired outcome. The primary goal of that effort was to start the convo that we're having now, and to be able to contribute in a meaningful way.  Note there are no VMware-based plans to dump a fully fledged proposal. We need to start from a premise as a community of understanding how/why/and which resources are valuable as CRDs.

For example when we look at orgs/spaces - we have to wonder if those are even resources we want to represent as CRDs, when k8s already has a namespace construct.

I think we'll need to start some dedicated working document to collaborate in. I had planned on facilitating that after some of the investigation that VMware has wraps up, but I don't think that's a reason to hold off if you or somebody else in the community has thoughts they want to start getting down. CAPI and other teams can contribute to an existing doc if that makes sense. Any other thoughts you'd prefer for next steps?

Looking forward to a continued conversation.

-Zach


On Wed, Apr 15, 2020 at 9:56 AM Keshav Sharma <ksharma@...> wrote:
Hi Daniel, 
The CF-K8s Networking team is currently working on a solution using Route CRDto 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
EngineerBetter Ltd - More than cloud platform specialists

381 - 400 of 9374