1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Seeking track co-chair nominations for Cloud Foundry EU Summit

Paige O'Connor <poconnor@...>
 

Cloud Foundry Community,

The co-chair nomination form for Cloud Foundry Summit Europe is now available!

Cloud Foundry Summits are successful, educational, and valuable to our community, because our track co-chair volunteers strive to bring as many high quality talks to Summit as they possibly can. We thank all those folks who have helped in making Summit tracks valuable to our community.

It is now time for you to step up and nominate yourself or your peer to be a co-chair. The deadline for nominations is September 1, 2020 at 11:59 PST.  Chris wrote a post to help answer any questions you may have about being a co-chair, but please feel free to reach out if there is any additional question.

Get nominating today!

Thanks,
Paige 

Paige O'Connor | Executive Administrator
Cloud Foundry Foundation

Cloud Foundry Summit Europe 2020 CFP Co-Chair Nomination Form

Paige O'Connor <poconnor@...>
 

Google Forms
Cloud Foundry Community, Nominate yourself or your peers to be a track co-chair for Cloud Foundry Summit EU. I've invited you to fill out a form:
Cloud Foundry Summit Europe 2020 CFP Co-Chair Nomination Form
Cloud Foundry is looking to the community to nominate Co-Chairs to help curate content for Cloud Foundry Summit Europe 2020. Please nominate people that you feel would represent the greater Cloud Foundry community's interest and are leaders in the community. The community will vote on the nominated co-chairs to select the final co-chairs September 2 - September 8, 2020. Final co-chairs will be announced on Thursday, September 10.

Please add your nominee’s name next to the category they are best suited to Co-Chair along with their company and contact information (email, slack/twitter username) if available. You may submit nominations for multiple categories. If you would like to submit multiple people for the same category, you will need to submit a secondary form.

Nominations close on Tuesday, September 1 at 11:59pm PST.
Fill out form
Create your own Google Form
Cloud Foundry for Kubernetes (cf-for-k8s) v0.6.0 release is out

Saikiran Yerram
 

Hello CF community,

We shipped a new alpha release v0.6.0 of cf-for-k8s. Some key highlights are below. 

We love contributions, so please reach out to us in the #cf-for-k8s channel, you can also create bugs and feature requests. Also, take a look at our project roadmap in cf-for-k8s project and upcoming releases.

Key highlights

  • Platform engineers and App developers will notice auto-patching of app workloads when the foundation is upgraded to a new stack version. App developers no longer have to re-push the app source to patch their app workload with the CVE fixes in the base image!!
  • Platform engineers can now expect all traffic to/from components that are denied by default and components will require explicit policies to allow ingress/egress traffic #262.
  • Platform engineers can expect all sensitive information such as passwords, cert keys are stored in Kubernetes native secrets #225, #226, #227, #228, #229, #230, #330.
  • Platform engineers and App developers can see available buildpacks via cf buildpacks #101.
  • App developers can select a buildpack with cf push APP_NAME -b [buildpack-name] #340.
    • Note, you can currently only select known buildpacks that are available in cf-for-k8s and not custom builpacks
  • Platform engineers can expect every component gets their own unique UAA client password #233.
  • Platform engineers can expect simplification of the cf-for-k8s configuration interface. You can see a list of allowable properties in config/values/00-values.yml
    • All overlays in config-optional are now managed by properties defined in config/values/00-values.yml.
    • Long term, cf-for-k8s will use YTT schema to define a more strict schema with semver versioning scheme.
    • Note: Platform engineers are still expected to provide properties in config/values/20-secrets-config-values.yml until cf-for-k8s replaces it with server-side secret generation using Quarks.
  • Platform engineers can expect by default all external HTTP traffic to CF API and application workloads to redirect to HTTPS unless they set gateway.https_only to false. Note, internal traffic between system components is encrypted by default by Istio.
  • Platform engineers can now control the creation of load balancer in Kubernetes using the new flag enable_load_balancer. This is helpful when you want to install locally or if want to wire your foundation to a pre-existing load-balancer.
  • Platform engineers can expect upgrades to wait until Postgres (stateful sets) are upgraded #206.
  • Platform engineers can observe application ingress latency contributed by the platform and network (more here)
cf-k8s-networking v0.4.0

Keshav Sharma
 

Hi cf-dev,

cf-k8s-networking v0.4.0 has been cut!

Release Highlights

  • Platform Engineers can confirm that cf-k8s by default only accepts encrypted requests and can be configured to receive requests on port-80 details
  • Platform Engineers can discover docs that describe how to use gateway access logs to observe application ingress latency contributed by platform and network details
  • Platform Engineers can discover docs that describe ingress load balancing topology in cf-for-k8s details
  • Platform Engineers can follow docs to discover that Istio is not a supported API in cf-for-k8s details

CF-K8s-Networking
​
Cloud Foundry Summit Europe 2020 is live!

Chip Childers <cchilders@...>
 

Hi All, 
Cloud Foundry Summit Europe 2020 is officially live! 

The Summit will be held online over two half-days on Wednesday, October 21st and Thursday, October 22nd on Central European Summer Time, with each date devoted to a key Cloud Foundry audience: developers (users) and contributors, respectively. Summit will include a networking space to facilitate a virtual version of face-to-face networking and digital booths sponsored by vendors for attendees to explore. 

Read the full press release here: 


You can register here for free using this code: CFEU20CONT

If you are interested in sponsoring Summit, please download the Sponsorship Prospectus. Sponsorship deadline is Friday, October 2.

We look forward to "seeing" you all at Summit!


Chip Childers
Executive Director
Cloud Foundry Foundation

Invitation to join the cf CLI feedback group

Josh Collins
 

Good Morning, Good Afternoon and Good Evening Everyone,

I hope this note finds you safe and sane and feeling good.
I've got a question and a call to action below...

Do you or someone you know have experience with (and opinions about) the cf CLI?
If so, I'd like to offer you or your colleagues an opportunity to directly access and provide feedback to the engineers and product managers responsible for the cf CLI.

The cf CLI team has been heads down on the v7 GA for a long time.
Now that we've launched the v7 cf CLI, the team is going to refocus direction and priority based on the experience and perspective of our users.

To that end, we’re building an influential, collaborative, yet casual and open, user feedback group called The CF CLI App-Dev Collective.
People who want to join the group can register their interest here (https://forms.gle/8Z12s3WAnzUyiSEb8).

Here's what the cf CLI team hopes to get out of this:
- gather direct feedback from cf CLI users
- validate proposed solutions

What you could get out of this:
- influence the direction of the cf CLI
- learn from experienced cf CLI users and developers

CF CLI App-Dev Collective participants may:
- communicate directly with cf CLI product and engineering staff
- help identify pain points and discuss priorities
- brainstorm solutions 
- discuss proofs of concept prior to implementation
- gain early access to a sandbox environment running the edge version of CAPI where beta CLI features can be exercised

Please know this group is casual and members can choose their level of engagement.

If you're interested, please register here.

And of course, if you’ve got questions, please reach out to Josh Collins (Product Manager for the cf CLI) via email, in the #cli channel in CloudFoundry Slack, or by direct message (@jcollins).

Thanks,

Josh Collins and the cf CLI Team
Routing release 0.206.0

Josh Russett
 

Hi cf-dev!

 

Routing release 0.206.0 is now available.

 

Release Highlights

  • Gorouter does not automatically send a `VCAP_ID` cookie, even when the app does not set the JSESSION id explicitly on the response. (See Issue #178)
  • Gorouter aliases `/healthz` → `/health` (See Issue #175)

 

Breaking Change

  • Application developers can no longer successfully deploy a reverse-proxy with support for sticky sessions (See re-opened Issue #170)

 

Regards,

CloudFoundry Networking Program
CF-Networking and Silk Release 2.33.0 now available

Josh Russett
 

Hi cf-dev,

 

CF-Networking release 2.33.0 and Silk release 2.33.0 are now both available.

 

CF-Networking Release Highlights:

  • cf-networking-release acceptance tests programmatically determine version of CF cli present and then use cf cli v6 or v7 function signatures as necessary.
  • Tested with silk-release v2.33.0

 

Silk Release Highlights:

  • Tested with cf-networking-release v2.33.0

 

 

Regards,

CF for VMs Networking Team
Re: Client secret rotation in UAA #uaa #cf

Shetty, Viraj S [CTR]
 

What I have found is that when I set the secret, add a secret or delete the secret later for a UAA client- the lastmodified field of the client does not get updated. Ideally, there should be a timestamp for the secret modification, so that it can be found out if a secret needs to be rotated. This would be helpful in agencies where there are policies on credentials rotation. At the very least, I think the last modifiied field should be updated on secret modification. I am at 74.14.0 UAA version. 

Thanks,
Viraj 
Client secret rotation in UAA #uaa #cf

Shetty, Viraj S [CTR]
 

Hi All, 

I am trying to create an automation script which will rotate the client secret every 30 days. I am trying to see if there is an API in UAA which will give me the timestamp of when the last time secret was changed for a client.  The retrieve client API does not seem to provide that information. I think the lastmodified field on retrieve client API is the last timestamp when any of the attributes of the client changed. Is this field (timestamp when secret was changed) available in UAA? If not, then I would probably just run the automation script every 90 days and force the secret rotation for all clients. 

Any help is appreciated 

Thanks,
Viraj 
Re: Some supporting UAA projects moving to the attic

Troy Topnik
 

Happy to have these two projects in the Extensions PMC. It seems an appropriate place, and the repos themselves don't have to move. I don't know the answer to the question about who's using cf-uaa-lib.

I'm not yet up to speed on the cf-extensions bot (https://github.com/cloudfoundry-incubator/cf-extensions) and I'm not 100% sure that process is still being followed. In any case, I'll sync with Nic if there are any further formalities required.

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
Re: Some supporting UAA projects moving to the attic

Chip Childers <cchilders@...>
 

This is a great outcome. The point that Dieu raised about anyone in the community being able to step in to become the maintainer of a CFF project when an existing project's committers want to move the code to the attic is exactly the right way for everyone to think about how the community should be operating!

The TL;DR part is above... below is more background for future situations. Feel free to ignore this part if you don't care about questions if intellectual property management.

Dieu's point about moving a project out of the CFF managed orgs is important. The CFF itself as a non-profit corporation is here for the entire community's benefit primarily as a place to share intellectual property (amongst other functions). In order to protect the community, our bylaws require that the board of directors approve any asset transfers (which includes intellectual property, like copyrights). In practice this has meant that we have avoided moving repos from a CFF managed GH org to any other GH org. This has, in the past, resulted in a move to the attic and then a fork from that attic copy for the code to evolve elsewhere.

In digging deeper into that scenario, there is (were we to ever want to do something like move a repo to a non-CFF org) an approach we *can* use that would allow issue / PR history to be retained. Essentially, the CFF won't "dispose" of the copyright held on the collective work (this is the term used when a CLA assigns rights to contributions, then an org copyrights the whole codebase). However, we license that collective work to the public via the ASLv2. In doing so, we are licensing forks to use and modify the code in any way a person or company would want. That means someone can fork a CFF project and continue development in a new direction. To make this easier in cases where we might want to help that fork become the canonical home of the code long term, we can (1) modify the CFF version's NOTICE file to note an end date to the CFF copyright, (2) fork the repo into the attic (so that we have a retained copy), and then (3) *move* the repo to the intended target (which lets a non-CFF community continue work).

Things do get much more complex when a project has a name, which is considered a trademark. I won't get into that scenario here though... that's for another time.

All that said, no reason to not continue developing the repos in question as CFF projects if there is someone willing to do so.

Thanks Dr. Nic!

Chip Childers
Executive Director
Cloud Foundry Foundation



On Wed, Aug 12, 2020 9:55 PM, Dr Nic Williams drnicwilliams@... wrote:

Correct; I don’t need the repos to be moved.

On Thu, 13 Aug 2020 at 7:48 am, Dieu Cao <dieuc@...> wrote:














Hi,











Just wanted to clarify that I believe as far as CF repo lifecycle, we can't simply transfer repos over to the cff-community github org.




Chip, can you confirm/deny that?




In this scenario, I'd like to propose an alternative, that if Dr. Nic, or someone else is interested in taking over maintenance of these repos, that we work through how to do that in the context of the CFF canonical repos and processes, perhaps in the extensions

PMC.











Assuming that's correct, Dr. Nic, would you be interested in being a maintainer for those repos in that context?











-Dieu






From: cf-dev@... <cf-dev@...> on behalf of Jeremy Morony via lists.cloudfoundry.org <jmorony=vmware.com@...>


Sent: Tuesday, August 11, 2020 6:15 PM



To: cf-dev@... <cf-dev@...>


Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic


 










Moving cf-uaa-lib & omniauth-uaa-oauth2 into the community org sounds good. Thank you for offering to maintain these

repos, Nic.





I have reached out to the teams that rely on cf-uaa-lib. They do still rely on it, but they didn't express any concerns with the proposed move.





I think we can orchestrate this move sooner than the 11/1 date I originally proposed. How about 9/4? This will allow any other community members a chance to voice any opinions.





Thanks!





  Jeremy.






From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams via lists.cloudfoundry.org <drnicwilliams=gmail.com@...>


Sent: Wednesday, August 5, 2020 2:05 PM


To: cf-dev@... <cf-dev@...>


Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic

 








Can you please move the middle two Ruby client libraries into cf community org instead of the attic; and make me a rubygem owner so I can cut gem releases in future?









I am the last maintainer of omniauth; and I think I had some unmerged PRs for cf-uaa-lib that I’ll merge and release.







I thought ccng (and perhaps bosh director) was using cf-uaa-lib — did they move to another library or still using it?







Nic







On Thu, 6 Aug 2020 at 5:31 am, Jeremy Morony <jmorony@...> wrote:


















































Hello!






















The UAA team has been taking inventory of the projects it maintains. We've decided to end support for a few of those projects:

























































We plan on moving these projects into the attic on 11/1/2020. If anybody in the community is interested in maintaining one of these projects, please reach out and let's talk.

























Thanks!

























  The UAA team.


























































--
















Dr Nic Williams


Stark & Wayne LLC






+61 437 276 076


twitter @drnic
































--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: Some supporting UAA projects moving to the attic

Dr Nic Williams <drnicwilliams@...>
 

Correct; I don’t need the repos to be moved.

On Thu, 13 Aug 2020 at 7:48 am, Dieu Cao <dieuc@...> wrote:














Hi,











Just wanted to clarify that I believe as far as CF repo lifecycle, we can't simply transfer repos over to the cff-community github org.




Chip, can you confirm/deny that?




In this scenario, I'd like to propose an alternative, that if Dr. Nic, or someone else is interested in taking over maintenance of these repos, that we work through how to do that in the context of the CFF canonical repos and processes, perhaps in the extensions

PMC.











Assuming that's correct, Dr. Nic, would you be interested in being a maintainer for those repos in that context?











-Dieu






From: cf-dev@... <cf-dev@...> on behalf of Jeremy Morony via lists.cloudfoundry.org <jmorony=vmware.com@...>


Sent: Tuesday, August 11, 2020 6:15 PM



To: cf-dev@... <cf-dev@...>


Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic


 










Moving cf-uaa-lib & omniauth-uaa-oauth2 into the community org sounds good. Thank you for offering to maintain these

repos, Nic.





I have reached out to the teams that rely on cf-uaa-lib. They do still rely on it, but they didn't express any concerns with the proposed move.





I think we can orchestrate this move sooner than the 11/1 date I originally proposed. How about 9/4? This will allow any other community members a chance to voice any opinions.





Thanks!





  Jeremy.






From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams via lists.cloudfoundry.org <drnicwilliams=gmail.com@...>


Sent: Wednesday, August 5, 2020 2:05 PM


To: cf-dev@... <cf-dev@...>


Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic

 








Can you please move the middle two Ruby client libraries into cf community org instead of the attic; and make me a rubygem owner so I can cut gem releases in future?









I am the last maintainer of omniauth; and I think I had some unmerged PRs for cf-uaa-lib that I’ll merge and release.







I thought ccng (and perhaps bosh director) was using cf-uaa-lib — did they move to another library or still using it?







Nic







On Thu, 6 Aug 2020 at 5:31 am, Jeremy Morony <jmorony@...> wrote:


















































Hello!






















The UAA team has been taking inventory of the projects it maintains. We've decided to end support for a few of those projects:

























































We plan on moving these projects into the attic on 11/1/2020. If anybody in the community is interested in maintaining one of these projects, please reach out and let's talk.

























Thanks!

























  The UAA team.


























































--
















Dr Nic Williams


Stark & Wayne LLC






+61 437 276 076


twitter @drnic
































--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: Some supporting UAA projects moving to the attic

Dieu Cao
 

Hi,

Just wanted to clarify that I believe as far as CF repo lifecycle, we can't simply transfer repos over to the cff-community github org.
Chip, can you confirm/deny that?
In this scenario, I'd like to propose an alternative, that if Dr. Nic, or someone else is interested in taking over maintenance of these repos, that we work through how to do that in the context of the CFF canonical repos and processes, perhaps in the extensions PMC.

Assuming that's correct, Dr. Nic, would you be interested in being a maintainer for those repos in that context?

-Dieu

From: cf-dev@... <cf-dev@...> on behalf of Jeremy Morony via lists.cloudfoundry.org <jmorony=vmware.com@...>
Sent: Tuesday, August 11, 2020 6:15 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic
 
Moving cf-uaa-lib & omniauth-uaa-oauth2 into the community org sounds good. Thank you for offering to maintain these repos, Nic.

I have reached out to the teams that rely on cf-uaa-lib. They do still rely on it, but they didn't express any concerns with the proposed move.

I think we can orchestrate this move sooner than the 11/1 date I originally proposed. How about 9/4? This will allow any other community members a chance to voice any opinions.

Thanks!

  Jeremy.
From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams via lists.cloudfoundry.org <drnicwilliams=gmail.com@...>
Sent: Wednesday, August 5, 2020 2:05 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic
 
Can you please move the middle two Ruby client libraries into cf community org instead of the attic; and make me a rubygem owner so I can cut gem releases in future?

I am the last maintainer of omniauth; and I think I had some unmerged PRs for cf-uaa-lib that I’ll merge and release.

I thought ccng (and perhaps bosh director) was using cf-uaa-lib — did they move to another library or still using it?

Nic

On Thu, 6 Aug 2020 at 5:31 am, Jeremy Morony <jmorony@...> wrote:














Hello!






The UAA team has been taking inventory of the projects it maintains. We've decided to end support for a few of those projects:















We plan on moving these projects into the attic on 11/1/2020. If anybody in the community is interested in maintaining one of these projects, please reach out and let's talk.







Thanks!







  The UAA team.














--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: Some supporting UAA projects moving to the attic

Jeremy Morony
 

Moving cf-uaa-lib & omniauth-uaa-oauth2 into the community org sounds good. Thank you for offering to maintain these repos, Nic.

I have reached out to the teams that rely on cf-uaa-lib. They do still rely on it, but they didn't express any concerns with the proposed move.

I think we can orchestrate this move sooner than the 11/1 date I originally proposed. How about 9/4? This will allow any other community members a chance to voice any opinions.

Thanks!

  Jeremy.

From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams via lists.cloudfoundry.org <drnicwilliams=gmail.com@...>
Sent: Wednesday, August 5, 2020 2:05 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Some supporting UAA projects moving to the attic
 
Can you please move the middle two Ruby client libraries into cf community org instead of the attic; and make me a rubygem owner so I can cut gem releases in future?

I am the last maintainer of omniauth; and I think I had some unmerged PRs for cf-uaa-lib that I’ll merge and release.

I thought ccng (and perhaps bosh director) was using cf-uaa-lib — did they move to another library or still using it?

Nic

On Thu, 6 Aug 2020 at 5:31 am, Jeremy Morony <jmorony@...> wrote:














Hello!






The UAA team has been taking inventory of the projects it maintains. We've decided to end support for a few of those projects:















We plan on moving these projects into the attic on 11/1/2020. If anybody in the community is interested in maintaining one of these projects, please reach out and let's talk.







Thanks!







  The UAA team.














--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Cancellation of deprecation of Loggregator V1 Firehose

Jesse Weaver <wjesse@...>
 

We in the Logging and Metrics team have decided to cancel the deprecation of the Loggregator V1 Firehose.

We had previously planned to deprecate the V1 then the V2 Firehose in favor of more modern, scalable APIs with more sustainable support paths (namely, logs over syslog and metrics over Prometheus endpoints). Difficulties encountered by downstream integrators, and concerns that have come up about the performance of the version of the V2 Firehose API accessible to outside integrations (1), have postponed the deprecation timeline significantly. This, combined with a shift in priority towards work on cf-for-k8s, has led us to believe that deprecation of the V1 Firehose is no longer the best path for operators, integrations, or ourselves.
cf CLI v7.0.2 is now available

Josh Collins
 

Good Day to You All,

The cf CLI team has released  v7.0.2 of the  cf CLI (this is a belated announcement as I was OOTO last week).

Highlights: 

  • Bug fix: login failed against foundations that use alternative login paths other than UAA
  • Bug fix: double encode name parameters in requests to CAPI #1938
  • Bug fix: allow spaces in app names #1966
  • Deletion: remove leftover v3-zdt- commands that should have been removed in the initial GA

Contributors: James Palmer, Nick Webb, Jenna Goldstrich, Alexander Berezovsky, Steve Taylor, Josh Collins, George Blue, Belinda Liu, Reid Mitchell, Sarah Weinstein

Note: The minimum version of the CC API this CF CLI release is compatible with is CC API v3.85.0. See our minimum supported version policy for more information.


Please see the release notes for more details and links to binaries and packages.

And as always, we really would love to hear from you so please feel free to respond to this email or find us in the Cloud Foundry Slack #cli channel any time.


Thank you very much,

The cf CLI and V3 Acceleration teams
Routing Release 0.205.0

Amelia Downs
 

Hi cf-dev, 


Routing Release 0.205.0 is now available for your consuming pleasure!


Release Highlights
  • Bug Fix: End user now gets a 502 TLS Handshake error after 10s of waiting for an unresponsive backend to complete a TLS handshake. The gorouter then prunes the bad backend and retries. Fixes this github issue.

  • Bump to golang 1.14.7


Regards,

CF for VMs Networking Team (we, know, it's a mouthful)
CF-Networking and Silk Release 2.32.0 now available

Josh Russett
 

Hi cf-dev,

 

CF-Networking release 2.32.0 and Silk release 2.32.0 are now both available.

 

CF-Networking Release Highlights:

  • cf-networking-release acceptance tests use cf cli v7
  • Tested with silk-release v2.32.0

 

Silk Release Highlights:

  • Tested with cf-networking-release v2.32.0

 

 

Regards,

CF for VMs Networking Team
cf-k8s-networking v0.3.0

Keshav Sharma <sharmake@...>
 

Hi cf-dev, 

CF-K8s-Networking-Release v0.3.0 has been cut!

Release Highlights


CF-K8s-Networking
301 - 320 of 9431