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.
From: cf-dev@... <cf-dev@...>
On Behalf Of Jesse Weaver
Sent: Donnerstag, 13. Februar 2020 21:58
Subject: [cf-dev] Deprecation of cf-syslog-drain-release
As previously announced , 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 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.