Date   

Stratos 3.1.0

Richard Cox
 

Hi Everybody!

It gives me great pleasure to announce the release of Stratos 3.1.0.

Highlights include...

- CF user roles can be added and removed via username
- The way Stratos handles large lists has received may improvements
- Jetstream logging of API requests can now be disabled
- Deploy CF Application now supports all v3 manifest features such as multiple buildpacks
- Administrators can now edit the details of existing endpoints
- The Stratos user profile icon now supports Gravatar

Full release notes are available here - https://github.com/cloudfoundry/stratos/releases/tag/3.1.0.

We welcome your feedback, comments and bug reports. Please feel free to raise them in github (https://github.com/cloudfoundry/stratos) or reach out directly to us in slack (#stratos)

Regards,

Richard Cox
on behalf of the Stratos team


Routing Release 0.200.0

Clay Kauzlaric <ckauzlaric@...>
 

Hi cf-dev!

A new Routing Release has been cut.

Routing Release Highlights

Regards,
CloudFoundry Networking Program


CF-Networking and Silk Release 2.29.0

Clay Kauzlaric <ckauzlaric@...>
 

Hi cf-dev!

New CF-Networking and Silk Releases have been cut.

CF-Networking Release Highlights
Silk Release Highlights

Regards,
CloudFoundry Networking Program


Re: REQUEST for REVIEW - Scope for CF-Deployment v13.0

Marco Voelz
 

Thanks for taking the time to getting this resolved, Sai! Highly appreciated!

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of Saikiran Yerram <syerram@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Monday, 20. April 2020 at 16:32
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] REQUEST for REVIEW - Scope for CF-Deployment v13.0

 

Hello everyone,

We are moving the cf-deployment v13.0 release date from 04/27/2020 to 05/04/2020. We are running behind schedule and there are still open questions on the scope.

We are working on resolving questions in the release note, so please check-in for updates later this week.

https://docs.google.com/document/d/1s07x8ONnaCqY8pY5dXK94wwjVWT1jFE0RppbdvL4kyg/edit?usp=sharing

_._,_._,_


Re: REQUEST for REVIEW - Scope for CF-Deployment v13.0

Saikiran Yerram
 

Hello everyone,

We are moving the cf-deployment v13.0 release date from 04/27/2020 to 05/04/2020. We are running behind schedule and there are still open questions on the scope.

We are working on resolving questions in the release note, so please check-in for updates later this week.

https://docs.google.com/document/d/1s07x8ONnaCqY8pY5dXK94wwjVWT1jFE0RppbdvL4kyg/edit?usp=sharing


KubeCF 2.0.0 is out!

Jaime Gomes
 

After some CI difficulties…KubeCF 2.0 is finally here! https://github.com/cloudfoundry-incubator/kubecf/releases/tag/v2.0.0
I welcome everyone to check the release notes to know what is coming on this major version.
Big applause to the team for code contributions and the community for the support and discussions on Slack and Github issues. See u all next week ;)

warning: this major version introduces some changes required to consume Eirini as a native component (scheduled for next week's release) by forcing the usage of kubecf name throughout the deployment resources (pod, namespace, ...) and so, upgrading from 1.x to 2.x will not be possible!


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

Zach Robinson
 

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: Is anyone working on a CF CRD & Controller?

Daniel Jones
 

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: CF Application Runtime PMC: UAA Project Lead Call for Nominations

Eric Malm
 

Hi, everyone,

VMware is nominating Pablo Schuhmacher for the UAA Project Lead in the Application Runtime PMC.

Pablo is a senior product manager at VMware working with the UAA team. Over the course of his 4 years at Pivotal and VMware, Pablo has worked across several Pivotal R&D teams and on many Pivotal Labs engagements. He has also worked with the Innovation Strategy team to provide consulting on product strategy and enterprise transformation for clients such as The Home Depot, Boeing, and Dick’s Sporting Goods.

Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PDT on Wednesday, April 29, 2020.

Thanks,
Eric Malm


From: cf-dev@... <cf-dev@...> on behalf of Eric Malm via lists.cloudfoundry.org <emalm=vmware.com@...>
Sent: Wednesday, April 15, 2020 5:32 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: [cf-dev] CF Application Runtime PMC: UAA Project Lead Call for Nominations
 
Hi, everyone,

Dan Beneke, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project, as he has recently left VMware. We thank him for his service.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Wednesday, April 29, 2020.

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

Thanks,
Eric Malm, CF Application Runtime PMC Lead


CF Application Runtime PMC: UAA Project Lead Call for Nominations

Eric Malm
 

Hi, everyone,

Dan Beneke, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project, as he has recently left VMware. We thank him for his service.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Wednesday, April 29, 2020.

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

Thanks,
Eric Malm, CF Application Runtime PMC Lead


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

Zach Robinson
 

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: Is anyone working on a CF CRD & Controller?

Keshav Sharma
 

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: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Chip Childers <cchilders@...>
 

Awesome! Once those are ready, let us know so that we can us that to help folks that land on the main cloudfoundry.org site. :)

It's also a topic in the Cloud Foundry and Kubernetes tutorial here > http://tutorials.cloudfoundry.org/cf-and-k8s/docs/cf-on-k8s/

Feedback on that welcome (or just PR any proposed changes!) > https://github.com/cloudfoundry-tutorials/cf-and-k8s

Chip Childers
Executive Director
Cloud Foundry Foundation


On Mon, Apr 13, 2020 at 3:10 PM Troy Topnik <troy.topnik@...> wrote:
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 
 


Is anyone working on a CF CRD & Controller?

Daniel Jones
 

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: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Troy Topnik
 

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


Re: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Chip Childers <cchilders@...>
 

Awesome! Thanks Sai, Troy, Swarna and everyone that is working to bring cf to k8s. :)

Chip Childers
Executive Director
Cloud Foundry Foundation


On Fri, Apr 10, 2020 at 3:43 PM Saikiran Yerram <syerram@...> wrote:
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


Re: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Saikiran Yerram
 

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


Re: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Daniel Jones
 

+1 for this. It's confusing for customers/users, and undermines confidence in the ecosystem if people aren't sure what/how to pick and when/if they may converge.

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


On Fri, 10 Apr 2020 at 15:24, Chip Childers <cchilders@...> wrote:
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

tools from k14s - ytt, kapp, kbld


--
Saikiran Yerram


Re: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Dieu Cao <dcao@...>
 

Woohoo!


On Fri, Apr 10, 2020 at 7:24 AM Chip Childers <cchilders@...> wrote:
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

tools from k14s - ytt, kapp, kbld


--
Saikiran Yerram


Re: Announcing Cloudfoundry for Kubernetes 0.1.0 release

Chip Childers <cchilders@...>
 

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

tools from k14s - ytt, kapp, kbld


--
Saikiran Yerram

401 - 420 of 9369