|
Re: Deprecation of cf-syslog-drain-release
We are in the planning stage and I will have concrete times by EOW.
|
|
|
cf CLI v6.50.0 is now live
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!
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
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
|
|
|
Re: CF Application Runtime PMC: Services API Project Lead Call for Nominations
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
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.
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 FoundationYou can read more about pronouns here, or please ask if you'd like to find out more.
|
|
|
[Proposal] CAPI V3 Service Instances
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
|
|
|
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
--
SUSE Cloud Application Platform
|
|
|
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
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
|
|
|
toggle quoted messageShow quoted text
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 FoundationYou 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:
-- Chris Clark Technical Operations Manager Cloud Foundry Foundation
|
|
|
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 FoundationYou 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:
|
|
|
Re: Deprecation of cf-syslog-drain-release
Hi Jesse,
thanks for your answers.
@Sai: Do you have already an idea when CF 13 will show up?
Best regards,
Stephan
toggle quoted messageShow quoted text
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
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
|
|
|
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:
|
|
|
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
|
|
|
