Congrats for releasing 1.0!

 

From: <cf-dev@...> on behalf of Simon D Moser <smoser@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Friday, 20. December 2019 at 20:57
To: "cf-dev@..." <cf-dev@...>
Cc: "cf-bosh@..." <cf-bosh@...>
Subject: Re: [cf-dev] [cf-bosh] Project Quarks CF Operator 1.0

 

way to go Quarks team! Awesome news!



From:        "Chris Clark" <cclark@...>
To:        cf-bosh@...
Cc:        "cf-dev@..." <cf-dev@...>
Date:        20/12/2019 18:57
Subject:        [EXTERNAL] Re: [cf-dev] [cf-bosh] Project Quarks CF Operator 1.0
Sent by:        cf-dev@...

---

Congrats Vlad and the rest of the Quarks team! That's great news.

On Fri, Dec 20, 2019 at 9:45 AM Vlad Iovanov <VIovanov@...> wrote:
Hello everyone,
 
On behalf of the Quarks team, I'd like to introduce Cloud Foundry Operator v1.0.0.
https://github.com/cloudfoundry-incubator/cf-operator/releases/tag/v1.0.0
 
This is our first stable release. Feedback is most welcome.
Please stay tuned for a corresponding Kube CF release.
 
Many thanks to everyone that's been testing and working with us to make this happen.
 
Beginning of next year, we’re planning to improve docs, publish some tutorials and use some of the new features in Kube CF.
 
Happy holidays!
 
Thanks,
The Quarks team
 
 


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation

Hello everyone,

 

On behalf of the Quarks team, I'd like to introduce Cloud Foundry Operator v1.0.0.

https://github.com/cloudfoundry-incubator/cf-operator/releases/tag/v1.0.0

 

This is our first stable release. Feedback is most welcome.

Please stay tuned for a corresponding Kube CF release.

 

Many thanks to everyone that's been testing and working with us to make this happen.

 

Beginning of next year, we’re planning to improve docs, publish some tutorials and use some of the new features in Kube CF.

 

Happy holidays!

 

Thanks,

The Quarks team

 

 

KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  

 

KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  

 

In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  

 

It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  

 

There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  

 

You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 

 

Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  

 

So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 

 

Thanks! 

 

SUSE Cloud Foundry Team 

KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  

 

KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  

 

In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  

 

It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  

 

There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  

 

You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 

 

Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  

 

So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 

 

Thanks! 

 

SUSE Cloud Foundry Team