Date   

CAB call for October 2019 is next week Wednesday 16th @ 8a Pacific

Michael Maximilien
 

FYI...
 
CAB call for October 2019 is next week Wednesday 16th @ 8a Pacific.
 
If you have a talk, a project, or would like to do a redux of your talk at CF Summit in The Hague, please contact me ASAP.
 
Reply here or ping me on Slack. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org


Re: SIG Meeting: Cloud Foundry for Kubernetes

Krannich, Bernd
 

Forgot to mention it: We are also “reviving” the corresponding Slack channel #cf-for-k8s on Cloud Foundry Slack (https://www.cloudfoundry.org/community/ à Cloud Foundry Slack).

 

From: Bernd Krannich <bernd.krannich@...>
Date: Thursday, 10. October 2019 at 15:59
To: "cf-dev@..." <cf-dev@...>, "cf-bosh@..." <cf-bosh@...>
Cc: Julz Friedman <julz.friedman@...>, Simon Moser <sdmoser@...>, Dieu Cao <dcao@...>, Eric Malm <emalm@...>, Jeff Hobbs <jeff.hobbs@...>, Troy Topnik <troy.topnik@...>, Jens Huesken <jens.huesken@...>, Swarna Podila <spodila@...>, Chip Childers <cchilders@...>
Subject: SIG Meeting: Cloud Foundry for Kubernetes

 

Hello all,

 

In a set of conversations before, at, and after CF Summit in The Hague, people from IBM, Pivotal, SAP and Suse (cc’d) came to the conclusion that it would be a good idea to suggest a “revival” of the Cloud Foundry for Kubernetes Special Interest Group meetings. The goal is to create an open forum for bringing up and discussing topics around moving Cloud Foundry on top of Kubernetes.

 

The first meeting of the SIG will be on October 15th, 8:30 AM PST and the next instance of the recurring meeting is on October 29th, two weeks later. Please see the Cloud Foundry community calendar [1] for the invites and dial-in. Additionally, Swarna has kindly created a Google doc [2] to collect meeting minutes and to collect topics that people want to discuss in this forum – so, please add the topics you would like to discuss to the Google doc. Additionally, we would like to record the meetings.

 

So, our call to the community is to join these calls if the topic of Cloud Foundry on top of Kubernetes is of interest for you. Looking forward to talking to you.

 

Thanks,

Julian Friedman (IBM), Simon Moser (IBM), Dieu Cao (Pivotal), Eric Malm (Pivotal), Jeff Hobbs (Suse), Troy Topnik (Suse), Jens Huesken (SAP), Bernd Krannich (SAP)

 

P.S.: This call does not replace but complement the existing CFF SIG Lifecycle Marco Voelz has announced earlier.

 

[1] https://www.cloudfoundry.org/community-calendar/

[2] https://docs.google.com/document/d/1ULNBEjlrNAgn3ko9y8ZJfwI7mw5-oofYdjl-dhkEoDA/edit#

[3] https://lists.cloudfoundry.org/g/cf-bosh/message/2639

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

T +49 6227 7-66220, F +49 6227 78-23923, E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


SIG Meeting: Cloud Foundry for Kubernetes

Krannich, Bernd
 

Hello all,

 

In a set of conversations before, at, and after CF Summit in The Hague, people from IBM, Pivotal, SAP and Suse (cc’d) came to the conclusion that it would be a good idea to suggest a “revival” of the Cloud Foundry for Kubernetes Special Interest Group meetings. The goal is to create an open forum for bringing up and discussing topics around moving Cloud Foundry on top of Kubernetes.

 

The first meeting of the SIG will be on October 15th, 8:30 AM PST and the next instance of the recurring meeting is on October 29th, two weeks later. Please see the Cloud Foundry community calendar [1] for the invites and dial-in. Additionally, Swarna has kindly created a Google doc [2] to collect meeting minutes and to collect topics that people want to discuss in this forum – so, please add the topics you would like to discuss to the Google doc. Additionally, we would like to record the meetings.

 

So, our call to the community is to join these calls if the topic of Cloud Foundry on top of Kubernetes is of interest for you. Looking forward to talking to you.

 

Thanks,

Julian Friedman (IBM), Simon Moser (IBM), Dieu Cao (Pivotal), Eric Malm (Pivotal), Jeff Hobbs (Suse), Troy Topnik (Suse), Jens Huesken (SAP), Bernd Krannich (SAP)

 

P.S.: This call does not replace but complement the existing CFF SIG Lifecycle Marco Voelz has announced earlier.

 

[1] https://www.cloudfoundry.org/community-calendar/

[2] https://docs.google.com/document/d/1ULNBEjlrNAgn3ko9y8ZJfwI7mw5-oofYdjl-dhkEoDA/edit#

[3] https://lists.cloudfoundry.org/g/cf-bosh/message/2639

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

T +49 6227 7-66220, F +49 6227 78-23923, E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Re: [Proposal] Deprecation of the firehose endpoint

Steffen Uhlig
 

Hi Jesse and Loggregator team,

we are using the gRPC endpoint[1] on the Dopplers to export logs and metrics into an internal system. Can you confirm that this endpoint is not affected by this change?

[1] https://github.com/cloudfoundry/loggregator-release/blob/e923f2fb3875d99ed3f8b5c8777bb9ffac0dd52b/jobs/doppler/spec#L21

Best regards / Mit freundlichen Grüßen
 
Steffen
 
-- 
Steffen Uhlig
Senior Software Engineer, IBM Cloud Development
Tel.: +49 7031 16-2199, e-mail: Steffen.Uhlig@...
 
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294


Re: [Proposal] Deprecation of the firehose endpoint

Jesse Weaver
 

Hello, all,

We wanted to follow up on this deprecation timeline.

We still plan to deprecate the v1 firehose, and our target is now the end of the year (the end of December 2019).

Sincerely,
The Loggregator Team


Re: Project Quarks Alpha Release

Dr Nic Williams <drnicwilliams@...>
 

Well done to all the teams involved!

For anyone at SpringOne, a demo of SCF/cf-operator will appear in Matthias and my talk tomorrow at 10:30 in 18AB “Platforms Demystified”

Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic


Project Quarks Alpha Release

Vlad Iovanov <VIovanov@...>
 

Hello everyone,

 

On behalf of the Quarks team, I'd like to introduce Cloud Foundry Operator v0.4.2.

https://github.com/cloudfoundry-incubator/cf-operator/releases/tag/v0.4.2

 

This is our first alpha release. Post CF Summit EU, we gathered feedback and made some bugfixes.

Many thanks to everyone that's been testing and working with us to make this happen.

 

Getting started is really easy, you can try the snippets below. For detailed requirements and advanced usage, please find us on slack (#quarks-dev).

There are many cool things to learn and experiment with, including Eirini.

 

kubectl create namespace scf

 

helm install --namespace cf-operator \

     --name cf-operator \

     --set operator.watchNamespace=scf \

     https://s3.amazonaws.com/cf-operators/release/helm-charts/cf-operator-v0.4.2%2B0.g604925f0.tgz

 

helm install \

    --namespace scf \

    --name scf \

    --set "system_domain=scf.suse.dev" \

    https://scf-v3.s3.amazonaws.com/scf-3.0.0-2f83620.tgz

 

Contributors are welcome!

 

Thanks,

The Quarks team

 


Re: Windows versions supported by UAA #uaa

Dan Beneke
 

Hi Enrique - 

A couple additions.  As UAA is an embedded dependency within CF, you would probably find more documentation about deployment of 'CF on Windows' than you would 'UAA on Windows'.  Additionally, we've considered windows usage in our buildout of the new go-based CLI for UAA.  You'll find a deployment for windows here.

Dan

On Mon, Oct 7, 2019 at 5:49 AM Enrique Cano <enrique.canocarballar@...> wrote:
Thanks for your reply, Daniel.
No concerns, other than Windows doesn't seem to be mentioned much in the documentation. Just wanted to make sure we can run it on Windows, that was all.

Thanks!
Enrique


Re: Windows versions supported by UAA #uaa

Enrique Cano
 

Thanks for your reply, Daniel.
No concerns, other than Windows doesn't seem to be mentioned much in the documentation. Just wanted to make sure we can run it on Windows, that was all.

Thanks!
Enrique


Re: Windows versions supported by UAA #uaa

Daniel Mikusa
 

The UAA server is written in Java so it's quite portable. Is there a specific concern that you have? 

Dan

On Mon, Oct 7, 2019 at 6:13 AM Enrique Cano <enrique.canocarballar@...> wrote:
Hi community

Is UAA supported on Microsoft Windows, and if so, what versions?

Many thanks in advance

Enrique


Windows versions supported by UAA #uaa

Enrique Cano
 

Hi community

Is UAA supported on Microsoft Windows, and if so, what versions?

Many thanks in advance

Enrique


Re: Update to Credhub encryption to use Key Encryption Key (KEK) protocol scheme

Mike Lloyd <mike@...>
 

Credhub team,

 

What does the migration plan for this feature look like? Is the migration from key types a non-breaking change, or will it require all new deployments and keys?

 

Thanks,

 

Mike.

 

From: cf-dev@... <cf-dev@...> On Behalf Of ebastian via Lists.Cloudfoundry.Org
Sent: Thursday, October 3, 2019 2:59 PM
To: cf-dev@...
Subject: [cf-dev] Update to Credhub encryption to use Key Encryption Key (KEK) protocol scheme

 

Hi everyone,

 

The Credhub team is proposing a change to the current encryption scheme. 

Changing the current encryption scheme from Data Encryption Key (DEK) to Key Encryption Key (KEK) would allow for:

  •  
  • increased Credhub security posture 
  •  
  •  
  • simplification of Credhub encryption key rotation
  •  
  •  
  • integration with third-party KMS vendors with a data size limit
  •  

 

Details of the change can be found here.

 

Please feel free to share your thoughts and concerns and reach out with any questions!

 

Thanks,

The Credhub Team

 


Proposal to move Loggregator to new shared-nothing architecture

Jesse Weaver
 

Hello, all,

We propose a new shared-nothing architecture to improve the scalability of syslog drains and to enable whole-platform syslog egress. This allows Loggregator to scale to more drains and logs/metrics per second, moves us to a community-standard log format, and improves the resource efficiency of log and metric egress.

Please see our proposal at https://docs.google.com/document/d/1_Ve4wAkeCC0fIJ1TiAWSfxzNp5zB_Ndoq5UmfUNJtgs/edit?usp=sharing . If you have any feedback, please comment on that document.

Thanks,
The Loggregator Team


Update to Credhub encryption to use Key Encryption Key (KEK) protocol scheme

ebastian@...
 

Hi everyone,


The Credhub team is proposing a change to the current encryption scheme. 

Changing the current encryption scheme from Data Encryption Key (DEK) to Key Encryption Key (KEK) would allow for:

  • increased Credhub security posture 

  • simplification of Credhub encryption key rotation

  • integration with third-party KMS vendors with a data size limit


Details of the change can be found here.


Please feel free to share your thoughts and concerns and reach out with any questions!


Thanks,

The Credhub Team

 


Re: New CLA tool for Cloud Foundry

Chris Clark
 

UPDATE: There will be a slight delay on the full migration - we're working out a couple kinks with the migration process, but should have things sorted out in the next week. We will, of course, keep you all updated when we're going to make the switch. In the meantime... long live Dreddbot!


On Fri, Sep 20, 2019 at 12:24 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


cf-networking-release & silk-release 2.25.0!

Keshav Sharma <ksharma@...>
 


Re: New CLA tool for Cloud Foundry

Eric Malm <emalm@...>
 

That's great news, Chris! Congratulations, and thanks for letting all of us know!

Best,
Eric


On Fri, Sep 20, 2019 at 12:25 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: New CLA tool for Cloud Foundry

Abby Chau
 

Awesome news. Thank you!


On Fri, Sep 20, 2019 at 12:25 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: New CLA tool for Cloud Foundry

Evan Farrar <evanfarrar@...>
 

Woohoo! Good bye, Dredd!

On Fri, Sep 20, 2019 at 12:25 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


New CLA tool for Cloud Foundry

Chris Clark
 
Edited

Hello all,
 
I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.
 
Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 
 
What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  
 
CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. If you are covered by a CCLA - the tool will ask (once) what company you are covered by.  At this point, click "CFF Migration", and it should confirm that you are in one of the whitelisted groups that we've moved over. 

We will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  Once this process is complete, I'll let you all know.  After that
 
Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  
 
I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  
 
Please reach out with any concerns or questions you might have about the new tool, or the migration process!
 
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation

661 - 680 of 9398