1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
cf CLI v6.50.0 is now live

Jenna Goldstrich
 

Hello everyone!

The cf CLI team has just released cf CLI v6.50.0

The major highlight of this release is that we now support Log Cache in the cf CLI!

See the release notes for more information (https://github.com/cloudfoundry/cli/releases/tag/v6.50.0)

If you have any feedback on this new release we would love to hear from you.  Please respond via this email or find us in the Cloud Foundry Slack #cli channel.

Thank you!
Jenna, the cf CLI and v3 Acceleration teams.

--
Jenna Goldstrich
Software Engineer @ VMWare - Cloud Foundry Seattle
BOSH OpenStack CPI maintenance

Riegger, Felix
 

Dear Friends of OpenStack,

 

SAP announced in August 2019 [1] to stop the maintenance of the BOSH OpenStack CPI and related projects by the end of 2019. Pivotal/VMware jumped in to take over the maintenance of the CPI. The handover has been completed and Pivotal/VMware now officially maintains the BOSH OpenStack CPI [2]. To get support please reach out to #bosh [6] or #bosh-core-dev [7] Slack channels.

 

The CF OpenStack validator [3] and bosh-openstack-environment-templates [4] are now unmaintained and will be moved to the cloudfoundy-attic [5] organization after a short grace period.

 

Kind regards,

Morgan and Felix

 

 

[1] https://lists.cloudfoundry.org/g/cf-bosh/message/2651

[2] https://github.com/cloudfoundry/bosh-openstack-cpi-release

[3] https://github.com/cloudfoundry-incubator/cf-openstack-validator

[4] https://github.com/cloudfoundry-incubator/bosh-openstack-environment-templates

[5] https://github.com/cloudfoundry-attic/

[6] https://cloudfoundry.slack.com/archives/C02HPPYQ2

[7] https://cloudfoundry.slack.com/archives/C094QRLEQ
Networking and Service Mesh in CF-for-k8s

Gabriel Rosenhouse <grosenhouse@...>
 

On the SIG CF for Kubernetes call this morning we discussed Networking, Routing and Service Mesh topics in detail.

A recording is available here.  Thanks to the Cloud Foundry foundation staff , Swarna and Bree, for making the recording available.



Here are some rough notes I took from our call.  Feel free to reply with corrections, feedback and questions.



1. What kind of feature parity are we targeting for networking in CF-for-K8s vs CF-for-BOSH?


The 1.0 release will provide basic http(s) ingress to apps and system components, log stream for apps, documented log and metrics for operational visibility, and transparent mTLS at every workload.


Some things will be more expensive for us to re-implement using the new networking tech stack in cf-for-k8s

We don't expect to get those done before a 1.0 release.


Support for Application Security Groups (ASGs) and app-to-app network policies will not block the 1.0 release.  We hope to deliver those soon afterwards. However, in the 1.0 release we will ship with deny-by-default for both app-to-app and app-egress (ASG-managed).  The alternative, where 1.0 has allow-by-default, and a 1.x moves to deny-by-default, would result in a user-facing breakage during thee upgrade.


Because the vast majority of CF Apps need some kind of app-egress in order to function, we will recommend that, while waiting for support for Cloud Controller-defined ASGs, an operator could instead use Kubectl to apply their own Kubernetes NetworkPolicy objects to provide app egress allow rules.  Such NetworkPolicy objects will continue to work even after CF-for-K8s is enhanced to provide full support for ASGs. Similarly for app-to-app network policies.


The caveat is that such operator-specified NetworkPolicies, like any kubernetes object created directly by the operator, will not be exposed to Cloud Foundry app devs.  There is a risk that these allow-rules will be present without users being aware. As with any production system, we recommend that the operator regularly audit all network policies.  



2. Current dependency on Istio.  What's up with that?


We recognize there are legitimate concerns about the governance of Istio, its complexity and it's resource consumption.  We don't expect that Cloud Foundry will have a hard-dependency on it, and aren't attached to it in the long-term.


App Developers won't use the Istio API directly.


Operators may touch a bit of it here or there when installing CF-for-K8s, but it should be narrowly scoped.  In the near-term, we won't be supporting the Istio API beyond those narrow, operator-facing bits. Custom Istio config (or network policy, for that matter) voids your warranty.


We could consider leaning on the Service Mesh Interface (SMI) as an abstraction layer if there's demand for swappability, although we haven't yet looked at it's suitability, and we're not committing to supporting this in the short-term.


Istio does provide value in transparent mTLS everywhere, and that's a big part of why we're using it right now.  Although alternatives like Linkerd may be worth considering instead.



3. Could migration from CF-for-BOSH/Diego to cf-for-k8s be eased by service-mesh-style connectivity between a Diego cluster and a K8s cluster?


Yes.  If we want to zero-downtime-deploy apps to cf-for-k8s, it is reasonable for those apps to be able to connect back to apps deployed on cf-diego.  Also apps on cf-diego being able to connect to apps on cf-for-k8s.


IP connectivity between containers across clusters would be nice, but many vendors & users don't have this.


CF-for-BOSH-diego has Envoy proxies in each app instance, but they aren't managed by Istio in supported releases (we've ceased development in the istio bosh release).


Alternative solution may involve: share internal route data across clusters, update DNS so that diego clients connect to a cluster-local egress-gateway, which can mTLS tunnel to an ingress gateway in the remote cf-for-k8s cluster.  The reverse could happen from client sidecars and skip the egress gateway. This would require quite a bit more technical design to de-risk, but seems viable.




Happy to field questions and corrections over reply email, or ping me in #cf-for-k8s in cloud foundry slack.


Thank you!
IMPORTANT NOTICE: [ruby-buildpack] End of Support for ruby versions 2.4.x after 2020-04-03

Kashyap Vedurmudi
 

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


Note: As 2.4.x is the current default for the Ruby version in the buildpack, the default Ruby version will be updated to 2.7.x as a part of this removal. If you’d like to use a different Ruby version, please configure your application to select that version[2].


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


[1] - https://www.ruby-lang.org/en/news/2019/04/01/ruby-2-4-6-released/

[2] - https://docs.cloudfoundry.org/buildpacks/ruby/index.html#runtime

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


Thanks,

Kashyap Vedurmudi, CF Buildpacks PM
Re: CF Application Runtime PMC: Services API Project Lead Call for Nominations

Matt McNeeney
 

Hi everyone,

VMware would like to nominate Miguel Luna for the Services API Project Lead in the Application Runtime PMC.

Miguel is a Staff Product Manager at VMware in London who is involved in the Open Service Broker API community and is responsible for enabling enterprise developers to go faster by increasing the number of tools available to them. Miguel has an engineering background and was previously leading the handset and devices product program at the telecommunications company giffgaff, where he engaged across the Spanish giant Telefonica group to advocate for lean ways of working and putting community at the heart of the innovation model.

Thanks,

Matt McNeeney


On Sat, 29 Feb 2020 at 00:14, Eric Malm via Lists.Cloudfoundry.Org <emalm=vmware.com@...> wrote:
Hi, everyone,

Laurel Gray, the lead for the Services API project within the Application Runtime PMC, has stepped down from the project. We thank her for her service.

The Services API team, located in London, 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 Friday, March 13, 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
Cloud Foundry Community Workroom at Kubecon/CloudnativeCon EU 2020

Swarna Podila
 

Dear Cloud Foundry Community,
For those of you attending Kubecon/CloudnativeCon EU 2020, please note that F002/F003 room is available for the cloud foundry community.  This is to foster the cross-community collaboration onsite.

This room is an "open-for-cf-community" workroom with no prior reservation required.  This room will be equipped with tables and chairs along with a whiteboard and some markers.  

Please do not hesitate to reach out to me (prior to the event) or the events team onsite, if you have any questions.

-- 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.
[Proposal] CAPI V3 Service Instances

devangelista@...
 

Hello everyone,
 
The Services API Team has been working on a model for the Cloud Controller V3 API for Service Instances.
You can view the proposals here:
https://docs.google.com/document/d/1P5laZqVYjtl_boSdpksT5LHOFjhm6CQLzWVx24UpXpM/edit?usp=sharing

We are seeking feedback from the community to help us finalize this proposal and move forward with implementation.

We are looking forward to your comments! You can contact us by replying to this email, or in our cloud foundry slack channel #svat 

Best regards
George and Derik
On Behalf of the Services API Team
_._,_._,_
CF Application Runtime PMC: Services API Project Lead Call for Nominations

Eric Malm
 

Hi, everyone,

Laurel Gray, the lead for the Services API project within the Application Runtime PMC, has stepped down from the project. We thank her for her service.

The Services API team, located in London, 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 Friday, March 13, 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: Incubating KubeCF

Krannich, Bernd
 

Congrats to Vlad, Troy and the other folks at Suse!

 

Cheers,

Bernd

 

From: <cf-dev@...> on behalf of Troy Topnik <troy.topnik@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 27. February 2020 at 23:19
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Incubating KubeCF

 

Thanks Eric and Runtime PMC for moving this along so quickly.

Looking forward to comments, questions, and hopefully contributions from the community.

Cheers,

TT

--

Troy Topnik

Senior Product Manager, 

SUSE Cloud Application Platform 

troy.topnik@...

 
Re: Incubating KubeCF

Troy Topnik
 

Thanks Eric and Runtime PMC for moving this along so quickly.

Looking forward to comments, questions, and hopefully contributions from the community.

Cheers,

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
IMPORTANT NOTICE: [go-buildpack] End of Support for golang versions 1.12.x after 2020-03-27

Kashyap Vedurmudi
 

The first release of the Go buildpack after March 27, 2020 will no longer include Go versions 1.12.x. These Go versions will no longer be supported upstream.[1] Please migrate your Go apps to supported versions of Go before that time.


Note: Unless you are manually specifying a version of Go for the buildpack to use, or you have customized your Go buildpack, no action is required.


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


[1] - https://golang.org/doc/devel/release.html#policy


Thanks,

Kashyap Vedurmudi, CF Buildpacks PM
Re: Incubating KubeCF

Chris Clark
 

Yay!  Congrats, everyone.


On Thu, Feb 27, 2020 at 8:01 AM Swarna Podila <spodila@...> wrote:
Excellent news!  Thank you so much, Vlad and Troy and the entire kubecf team.

-- 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, Feb 27, 2020 at 7:31 AM Eric Malm <emalm@...> wrote:
Hi, all,

I'm pleased to announce that the Runtime PMC has approved the incubation proposal for KubeCF. Congratulations, Vlad and Troy!

Best,
Eric

On Tue, Feb 18, 2020 at 11:36 AM Eric Malm <emalm@...> wrote:
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:

Hello again, here’s the proposal doc with more details:

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

 

Cheers,

Vlad

 

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?

 

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

 



--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation
Re: Incubating KubeCF

Swarna Podila
 

Excellent news!  Thank you so much, Vlad and Troy and the entire kubecf team.

-- 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, Feb 27, 2020 at 7:31 AM Eric Malm <emalm@...> wrote:
Hi, all,

I'm pleased to announce that the Runtime PMC has approved the incubation proposal for KubeCF. Congratulations, Vlad and Troy!

Best,
Eric

On Tue, Feb 18, 2020 at 11:36 AM Eric Malm <emalm@...> wrote:
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:

Hello again, here’s the proposal doc with more details:

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

 

Cheers,

Vlad

 

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?

 

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

 
Re: Deprecation of cf-syslog-drain-release

Stephan Merker
 

Hi Jesse,

 

thanks for your answers.

 

@Sai: Do you have already an idea when CF 13 will show up?

 

Best regards,

Stephan

 

From: cf-dev@... <cf-dev@...> On Behalf Of Jesse Weaver
Sent: Dienstag, 25. Februar 2020 18:43
To: Merker, Stephan <stephan.merker@...>
Cc: cf-dev@...; Saikiran Yerram <syerram@...>
Subject: Re: [cf-dev] Deprecation of cf-syslog-drain-release

 

 

 

On Tue, Feb 25, 2020 at 8:31 AM Merker, Stephan <stephan.merker@...> wrote:

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.

  1. https://lists.cloudfoundry.org/g/cf-dev/message/8304?p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357
  2. https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml

Re: Incubating KubeCF

Eric Malm <emalm@...>
 

Hi, all,

I'm pleased to announce that the Runtime PMC has approved the incubation proposal for KubeCF. Congratulations, Vlad and Troy!

Best,
Eric


On Tue, Feb 18, 2020 at 11:36 AM Eric Malm <emalm@...> wrote:
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:

Hello again, here’s the proposal doc with more details:

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

 

Cheers,

Vlad

 

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?

 

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

 
Re: Bi-weekly Round-Up: Technical + Ecosystem Updates

Chris Clark
 

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:

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

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

Interesting Finds from Around the Web:

Who’s hiring?  

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


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

Dieu Cao <dcao@...>
 

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
Nats Release v33

Aidan Obley <aobley@...>
 

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

Jesse Weaver
 



On Tue, Feb 25, 2020 at 8:31 AM Merker, Stephan <stephan.merker@...> wrote:

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.

  1. https://lists.cloudfoundry.org/g/cf-dev/message/8304?p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357
  2. https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml

Re: Deprecation of cf-syslog-drain-release

Stephan Merker
 

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

 

---

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.

  1. https://lists.cloudfoundry.org/g/cf-dev/message/8304?p=,,,20,0,0,0::relevance,,syslog+agent,20,2,0,26724357
  2. https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/add-syslog-agent.yml

521 - 540 of 9433