|
Re: Bi-weekly Round-Up: Technical + Ecosystem Updates
This month, the Cloud Foundry Foundation celebrated our 5th birthday! We thought we’d treat ourselves to something nice, like this spectacular webpage commemorating this event, a laudatory video, and a blog post; it was a virtual bubble bath of self-reflection and community love.
Abby had this to say about the milestone here:
https://medium.com/@ab415/and-yet-its-still-early-days-for-cloud-5-years-at-cloud-foundry-foundation-e697003e7de7
Chip had this to say about the ever changing platform:
https://thenewstack.io/from-bystander-to-cto-my-five-year-journey-with-the-cloud-foundry-foundation/
From The Last Few Weeks:
Community Updates:
All Things Cloud Foundry Summit:
- Call for proposals for Cloud Foundry Summit is open (closes March 20): https://lists.cloudfoundry.org/g/cf-dev/topic/cloud_foundry_summit_is_back/70059069?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,70059069
- Help choose a date for The Unconference at #CFSummit North America 2020 https://docs.google.com/forms/d/e/1FAIpQLSchuPoBPALrYrYp55G9zTOoKE1uOWU2Ia8_uYJpXM105A6-QQ/viewform
Dates To Remember (All times US Pacific):
- CF for Kubernetes SIG call – 8:30 AM on March 3
- Bi-Weekly CF App Runtime PMC meeting – 10:30 AM on March 3
Interesting Finds from Around the Web:
|
|
|
Call for Help with Vulnerability Management for CFF projects
All,
The CF community is looking for a handful of volunteers to help reconstitute a multi-member vulnerability management team for CFF projects. Recently, the task has fallen to the Pivotal/VMware security team alone. However, the whole community has a stake in this process.
We're looking for individuals that either: (1) have past experience managing security reports responsibly within either a commercial or open source setting, or (2) are willing and capable of learning by doing. One of the keys to success here will be for the volunteers to have a true sense of being responsible for this process.
Don't worry if you're not a security expert. You do have to be willing to spend a few hours a week helping manage the process.
If interested, reply here or contact me directly. Once we get a reasonable group of volunteers, we'll setup the appropriate meetings to get started.
Thanks,
Dieu Cao
CFF PMC Council Chair
|
|
|
Hi cf-dev,
A new nats-release was cut.
Release Highlights
- Enhancement: Operators can configure nats-tls with hostnames instead of just IPs. Jobs nats and nats-tls provide hostname on links. See the example-manifests/ops-files/enable_nats_tls_for_cf.yml for an example working configuration with a bosh-dns-alias. story
- Golang Upgraded to Go1.13.7
Regards,
CloudFoundry Networking Program
|
|
|
Re: Deprecation of cf-syslog-drain-release
Hi Jesse,
Do you have a rough schedule when you want to remove the adapters and disable cf-syslog-drain release in cf-deployment?
Our current plan is to ship this in cf-deployment v13.0.0 (in coordination with the Release Integration team).
Is it in weeks or months?
This is dependent on cf-deployment's release schedule.
Will there be an ops file to opt out of the new architecture for some time once it got the default?
We do not presently plan to offer this, for a couple reasons:
1) The add-syslog-agent.yml ops file has existed as an opt-in for some time. 2) The new architecture will change which parts of the foundation are impacted by high syslog output, but does not result in any other change for operators or developers. The syslog output format and configuration mechanism should be unchanged.
We are planning to offer an ops file in cf-deployment v12 that will put the syslog agents in place, ready to be flipped on in v13, so that the upgrade takes less time and causes much less downtime in app syslog drains.
Best regards,
Stephan
---
From: cf-dev@... <cf-dev@...>
On Behalf Of Jesse Weaver
Sent: Donnerstag, 13. Februar 2020 21:58
To: cf-dev@...
Subject: [cf-dev] Deprecation of cf-syslog-drain-release
As previously announced [1], the Loggregator team has developed a new way to forward application logs over syslog using agents, rather than centralized adapters. This new approach can scale
to higher log volume and numbers of app drains, and allows log egress from CloudFoundry without any dependence on the Loggregator firehose.
We have had an ops file[2] to switch to this new architecture in cf-deployment for some time, and are working to make it the default in a coming major version of cf-deployment. This would mean the removal of the scalable-syslog architecture, with its schedulers
and adapters, and the cf-syslog-drain release.
Once this has been released, we would like to mark the cf-syslog-drain release as deprecated, and halt development.
Please let us know if you have any concerns or questions.
-
https://lists.cloudfoundry.org/g/cf-dev/message/8304?p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357
-
https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml
|
|
|
Re: Deprecation of cf-syslog-drain-release
Hi Jesse,
Do you have a rough schedule when you want to remove the adapters and disable cf-syslog-drain release in cf-deployment? Is it in weeks or months?
Will there be an ops file to opt out of the new architecture for some time once it got the default?
Best regards,
Stephan
---
toggle quoted messageShow quoted text
From: cf-dev@... <cf-dev@...>
On Behalf Of Jesse Weaver
Sent: Donnerstag, 13. Februar 2020 21:58
To: cf-dev@...
Subject: [cf-dev] Deprecation of cf-syslog-drain-release
As previously announced [1], the Loggregator team has developed a new way to forward application logs over syslog using agents, rather than centralized adapters. This new approach can scale
to higher log volume and numbers of app drains, and allows log egress from CloudFoundry without any dependence on the Loggregator firehose.
We have had an ops file[2] to switch to this new architecture in cf-deployment for some time, and are working to make it the default in a coming major version of cf-deployment. This would mean the removal of the scalable-syslog architecture, with its schedulers
and adapters, and the cf-syslog-drain release.
Once this has been released, we would like to mark the cf-syslog-drain release as deprecated, and halt development.
Please let us know if you have any concerns or questions.
-
https://lists.cloudfoundry.org/g/cf-dev/message/8304?p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357
-
https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml
|
|
|
Unconference in Austin - help decide the most suitable date please
Ivana Scott <ivana.scott@...>
Hi all,
We are hoping to bring the Unconference to Austin this June and run it in conjunction with the OS Summit and CF Summit NA.
Please help us decide on a date by voting via the form below:
https://buff.ly/2HjeKGj
Thanks for your help and hope to see you in Austin :-)
Best Regards,
Ivana Scott - Business Operations Manager
|
|
|
Hi Igor, Could you provide the specific docker image that you're using, and the full command used to run it? We have several Docker images under the user " cfidentity", but we don't really provide specific support for them, as they are mostly used in our pipelines or for other testing purposes. Any information you could provide about your use-case would be appreciated. Our k8s directory has some k8s templates that should get you going if your broader desire is to use k8s as well as Docker.
|
|
|
Igor Ryadinskii <igor.ryadinskii@...>
Hi, I use your wonderful UAA module, thanks for it. But I have error on /oauth/token request that property ${smtp.javaMailProperties.mail.smtp.auth} Not mapped . I use docker image from docker hub. Can you help with it? Best regards, Igor
|
|
|
Re: [cf-bosh] CF Summit North America 2020: Seeking Program Chair Nominations
Swarna Podila
Hi Everyone, Thank you for all the nominations so far. Given the timing of the CAB call, it felt right to extend the deadline by 24hours. So please feel free to send your nominations [1] for program co-chairs for CF Summit NA by 11:59PM US Pacific Time on Feb 19th. -- [1] https://forms.gle/5DH91j2JPevPLd8p7 Thank you, Swarna.
|
|
|
Thanks, Vlad!
Everyone, if you do have comments for the proposal document, please make them there or on this message thread by the 11:59 PM PST on Thursday, Feb 20. I've asked for the Runtime PMC members to approve the project via email starting at that point, with the intent of resolving the proposal by early next week, instead of waiting for synchronous discussion at the March 3rd PMC meeting.
Best,
Eric
On Wed, Feb 12, 2020 at 1:56 PM Vlad Iovanov < viovanov@...> wrote:
|
|
|
Reminder: CAB call on Wednesday, February 19th @ 8AM PT / 11AM ET / 5PM CET
Troy Topnik
Howdy all! We have a CAB call coming up Wed. 19th at 8AM Pacific. There's a tentative agenda that includes the usual updates from the Foundation, the PMC projects, and a couple of talks about CF smoke tests from:
- Onno Brouwer, Rijkswaterstaat
- Savani Tatake & Piyush Diwan, T Mobile
Time permitting, we may briefly discuss the KubeCF incubation proposal and maybe even get a CF-on-K8s overview. As always, you can see the agenda here: https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xILet me know if you have anything to add or change. Thanks, TT --
Troy Topnik
troy.topnik@...
|
|
|
Deprecation of cf-syslog-drain-release
As previously announced [1], the Loggregator team has developed a new way to forward application logs over syslog using agents, rather than centralized adapters. This new approach can scale to higher log volume and numbers of app drains, and allows log egress from CloudFoundry without any dependence on the Loggregator firehose. We have had an ops file[2] to switch to this new architecture in cf-deployment for some time, and are working to make it the default in a coming major version of cf-deployment. This would mean the removal of the scalable-syslog architecture, with its schedulers and adapters, and the cf-syslog-drain release. Once this has been released, we would like to mark the cf-syslog-drain release as deprecated, and halt development. Please let us know if you have any concerns or questions. - https://lists.cloudfoundry.org/g/cf-dev/message/8304?p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357
- https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml
|
|
|
toggle quoted messageShow quoted text
From: Chip Childers
Sent: Tuesday, February 11, 2020 8:02 PM
To: CF Developers Mailing List
Subject: Re: [cf-dev] Incubating KubeCF
Happy to see this Vlad!
Who is proposed to be the project lead, and who are the initial committers?
On Mon, Feb 10, 2020 at 11:44 PM Vlad Iovanov <VIovanov@...> wrote:
Hi all,
SUSE would like to propose the KubeCF project for incubation in the Application Runtime PMC.
Kube CF is a Cloud Foundry distribution that runs on Kubernetes.
It uses the cf-operator [1] to deploy a full Cloud Foundry, that runs all the certified components.
It can also run Eirini [2] instead of Diego (so your apps are also run natively on Kube).
It’s fully open source with an Apache 2.0 license and can currently be found on GitHub at
https://github.com/SUSE/kubecf.
The project would follow a distributed committer model.
Cheers,
Vlad
[1]
https://github.com/cloudfoundry-incubator/cf-operator
[2]
https://github.com/cloudfoundry-incubator/eirini
|
|
|
Troy Topnik
We'd like to propose Vlad Iovanov as project lead with the following additional initial committers:
Right now this project is pretty closely tied to Quarks (i.e. works with cf-operator) so there's overlap with that team.
Vlad is preparing a proposal document (coming soon) so we can capture discussion.
TT --
Troy Topnik
Senior Product Manager,
SUSE Cloud Application Platform
troy.topnik@...
|
|
|
Chip Childers <cchilders@...>
Happy to see this Vlad!
Who is proposed to be the project lead, and who are the initial committers?
Chip Childers, CTO Cloud Foundry Foundation
On Mon, Feb 10, 2020 at 11:44 PM Vlad Iovanov < VIovanov@...> wrote:
Hi all,
SUSE would like to propose the KubeCF project for incubation in the Application Runtime PMC.
Kube CF is a Cloud Foundry distribution that runs on Kubernetes.
It uses the cf-operator [1] to deploy a full Cloud Foundry, that runs all the certified components.
It can also run Eirini [2] instead of Diego (so your apps are also run natively on Kube).
It’s fully open source with an Apache 2.0 license and can currently be found on GitHub at
https://github.com/SUSE/kubecf.
The project would follow a distributed committer model.
Cheers,
Vlad
[1]
https://github.com/cloudfoundry-incubator/cf-operator
[2]
https://github.com/cloudfoundry-incubator/eirini
|
|
|
Dr Nic Williams <drnicwilliams@...>
Looking forward to a bright future for CF this year! Thanks for pioneering ahead with the SCF -> KubeCF/Quarks projects.
There be dragons, for sure, but they are dragons of love :)
Nic -- Dr Nic Williams Stark & Wayne LLC +61 437 276 076 twitter @drnic
|
|
|
Vlad Iovanov <VIovanov@...>
Hi all,
SUSE would like to propose the KubeCF project for incubation in the Application Runtime PMC.
Kube CF is a Cloud Foundry distribution that runs on Kubernetes.
It uses the cf-operator [1] to deploy a full Cloud Foundry, that runs all the certified components.
It can also run Eirini [2] instead of Diego (so your apps are also run natively on Kube).
It’s fully open source with an Apache 2.0 license and can currently be found on GitHub at
https://github.com/SUSE/kubecf.
The project would follow a distributed committer model.
Cheers,
Vlad
[1]
https://github.com/cloudfoundry-incubator/cf-operator
[2]
https://github.com/cloudfoundry-incubator/eirini
|
|
|
Re: [cf-bosh] CF Summit North America 2020: Seeking Program Chair Nominations
Swarna Podila
Hi Dan, Yes, blind review of CFP submissions is possible and we do intend to do blind review this year. I will update the blog post accordingly; thank you for asking the question.
-- Swarna Podila (she/her) Senior Director, Community | Cloud Foundry FoundationYou can read more about pronouns here, or please ask if you'd like to find out more.
Hi Swarna,
Will a blind selection process be possible this year? Regards, Daniel 'Deejay' Jones - CTO +44 (0)79 8000 9153
On Fri, 7 Feb 2020 at 17:04, Swarna Podila < spodila@...> wrote: Dear Friends, It is that time of Cloud Foundry Summit again where we need your help in establishing the program committee to review CFP submissions. Given the new format of Summits this year, we will also look to our program chairs to help structure the content in the best way suited for our community.
I've written up a quick post [1] that explains it and hopefully answers all your questions (if there are more questions, please don't hesitate to ask here or on in #summit or #cff-forum channels on slack).
Get nominating today [2]! The nominations close on Feb 18, 11:59PM US PST.
--
-- Swarna Podila (she/her) Senior Director, Community | Cloud Foundry FoundationYou can read more about pronouns here, or please ask if you'd like to find out more.
|
|
|
Re: Component Changes in CF-for-K8s
Hi Daniel, CAPI PM here - yes, kpack is replacing traditional staging in CF4K8s so we can move to an image based staging workflow for k8s. The nice thing with kpack is that it makes use of CNB ( buildpacks.io) and the buildpacks team has done the work to make sure this new buildpacks work in both CF4BOSH and CF4K8s.
Hi folks,
What's the deal with components in CF getting CNCF-friendly replacements in CF-for-K8s? The repo points out that Istio, envoy, kpack and fluentd are in the mix.
Presumably kpack is replacing traditional staging? And is fluentd replacing Loggregator, or supplementing it?
Has there been any discussion of what this means for maintaining feature parity between CF4BOSH and CF4K8s, and for technical certification of CF platforms? Regards, Daniel 'Deejay' Jones - CTO +44 (0)79 8000 9153
|
|
|
Re: Component Changes in CF-for-K8s
We (the Loggregator team) are looking to replace the existing Loggregator infrastructure with Fluentd + Log Cache.
Hi folks,
What's the deal with components in CF getting CNCF-friendly replacements in CF-for-K8s? The repo points out that Istio, envoy, kpack and fluentd are in the mix.
Presumably kpack is replacing traditional staging? And is fluentd replacing Loggregator, or supplementing it?
Has there been any discussion of what this means for maintaining feature parity between CF4BOSH and CF4K8s, and for technical certification of CF platforms? Regards, Daniel 'Deejay' Jones - CTO +44 (0)79 8000 9153
|
|
|
