Daniel Mikusa
That's awesome, thanks for sharing!
On Fri, Mar 13, 2020 at 4:42 AM <dmcintyre@...> wrote: Hi all,
|
|
Dr Nic Williams <drnicwilliams@...>
Great idea Duncan. Great to have more sample apps for PHP. Nic --
|
|
dmcintyre@...
Hi all,
Just want to let the PHPers among you know I've added a new repo php-cfenv (https://github.com/cloudfoundry-community/php-cfenv) Inspired by java-cfenv and cf-helper-php, this library makes it easy for PHP apps to consume services in CloudFoundry. I've also posted a (really really basic) demo app showing binding to MongoDB (https://github.com/dmcintyre-pivotal/php-cfenv-demo) All feedback gratefully received. Duncan
|
|
Re: KubeCF 1.0
Eric Malm <emalm@...>
Congratulations, Vlad, Troy, and the rest of the KubeCF team! That's great news! Best, Eric
On Thu, Mar 12, 2020 at 12:40 AM Simon D Moser <smoser@...> wrote:
|
|
Re: Stratos 3.0.0
Chip Childers <cchilders@...>
Another awesome release announcement. Great work folks! Chip Childers, CTO Cloud Foundry Foundation
On Thu, Mar 12, 2020 at 11:31 AM Richard Cox <RiCox@...> wrote:
|
|
Stratos 3.0.0
Richard Cox <RiCox@...>
Hi Everybody!
It gives me great pleasure to announce the release of Stratos 3.0.0.
This release contains many improvements, tweaks and fixes. Full release notes are available here - https://github.com/cloudfoundry/stratos/releases/tag/3.0.0.
We welcome your feedback, comments and bug reports - Please feel free to raise an issue in github (https://github.com/cloudfoundry/stratos) or reach out directly to us in slack (#stratos)
Regards,
Richard Cox
on behalf of the Stratos team
|
|
Re: KubeCF 1.0
Simon D Moser
Congrats to all involved!
toggle quoted messageShow quoted text
Von meinem iPhone gesendet
Am 12.03.2020 um 07:54 schrieb Krannich, Bernd <bernd.krannich@...>:
|
|
Re: KubeCF 1.0
Krannich, Bernd
Congrats for the 1.0 to Vlad, Troy, Jeff and crew!
Regards, Bernd
From: <cf-dev@...> on behalf of Chip Childers <cchilders@...>
This is awesome news! I love that Stratos works with it as well. :)
Chip Childers, CTO Cloud Foundry Foundation
On Wed, Mar 11, 2020 at 6:58 PM Vlad Iovanov <viovanov@...> wrote:
|
|
Re: KubeCF 1.0
Chip Childers <cchilders@...>
This is awesome news! I love that Stratos works with it as well. :) Chip Childers, CTO Cloud Foundry Foundation
On Wed, Mar 11, 2020 at 6:58 PM Vlad Iovanov <viovanov@...> wrote:
|
|
Routing Release 0.199.0
Aidan Obley <aobley@...>
Hi cf-dev, A new routing-release was cut. Release Highlights
Regards,
|
|
Re: KubeCF 1.0
Dieu Cao <dcao@...>
Congrats! Very exciting news! Dieu
On Wed, Mar 11, 2020 at 4:34 PM Dr Nic Williams <drnicwilliams@...> wrote:
|
|
Re: KubeCF 1.0
Dr Nic Williams <drnicwilliams@...>
Congrats to everyone who has worked on the project! Nic
|
|
KubeCF 1.0
Vlad Iovanov
Hello everyone,
We released KubeCF 1.0 today! https://github.com/cloudfoundry-incubator/kubecf/releases/tag/v1.0.0
A big thank you to everyone that has contributed to this new flavor of Cloud Foundry!
We invite the community to try things out and help us make it better.
We'd also like to ask for your help. We are reorganizing the kubecf development teams, and there is room for new contributors. If you want to help shape this project, please come talk to us on the #kubecf-dev channel. No prior kubernetes experience needed.
Cheers, Vlad
|
|
cf-for-k8s metric instrumentation
#loggregator
Hello CF Community!
We wanted to share a document[1] that describes some best practices, and solicit feedback for instrumenting workloads in cf-for-k8s. From a metric standpoint we are making good progress in cf-for-k8s on container metrics (see our metric proxy[2]) and are starting to move towards metrics from other platform components. The major difference here is that we are no longer utilizing Loggregator envelopes, and are moving to a Prometheus exposition standard. We are here to help if your component is using something like statsd and needs to convert to Prometheus. The document should be open to comments and suggestions so please make your comments there. 1. https://docs.google.com/document/d/1XdkqIJ2SeqajNyzyTOjLg_VjuatSTCtown4-0xZEH3Q/edit# 2. https://github.com/cloudfoundry/metric-proxy
|
|
Re: Bi-weekly Round-Up: Technical + Ecosystem Updates
Chris Clark
Hope you’re all healthy, relaxed and washing your hands regularly. Many events are being canceled, as you’ve *probably* noticed. KubeCon + CloudNativeCon Europe (originally set for March 30 to April 2, 2020) has been postponed to July or August 2020. Unfortunately, KubeCon + CloudNativeCon + Open Source Summit China in July has been canceled altogether. Read more here. From the Last Few Weeks:
Community Updates:
All Things Cloud Foundry Summit:
Dates To Remember (All times US Pacific):
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.
|
|
Re: Deprecation of cf-syslog-drain-release
Saikiran Yerram
We are in the planning stage and I will have concrete times by EOW.
|
|
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
|
|