1. Cf-Dev
  2. Messages

Expanded

Topics Messages
   Date   
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
Re: Some supporting UAA projects moving to the attic

Dr Nic Williams <drnicwilliams@...>
 

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
Some supporting UAA projects moving to the attic

Jeremy Morony
 

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:
- https://github.com/cloudfoundry/uaa-singular
- https://github.com/cloudfoundry/omniauth-uaa-oauth2
- https://github.com/cloudfoundry/cf-uaa-lib
- https://github.com/cloudfoundry/identity-tools

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.
Office Hours: CF K8s Networking

Shannon Coen
 

Hello CF enthusiasts,

The CF-K8s Networking team is hosting office hours today at 10am PDT. Join us if you have any questions, or just if you're curious about the future of Cloud Foundry.

Meeting information can be found on the Cloud Foundry Community Calendar: https://www.cloudfoundry.org/community-calendar/


Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272


Routing Release 0.204.0

Amelia Downs
 

Hi cf-dev, 


Routing Release version 0.204.0 is now available for your consuming pleasure!


Release Highlights
  • Feature: Change gorouter default branch from “master” to “main”. Fixes gorouter issue #269.
  • Feature: Change gorouter “master” branch to be called “release”. Fixes routing-release issue #171.
  • Feature: Improve performance for TCP Router. Now it does not reload the HAProxy unnecessarily.
  • Feature: Improve websocket error handling.


Regards,

CF for VMs Networking Team (we, know, it's a mouthful)
Cloud Foundry for Kubernetes (cf-for-k8s) 0.5.0 release is available

Saikiran Yerram
 

Hello CF friends,

We, the cf-for-k8s RelInt team, are excited to announce the availability of cf-for-k8s 0.5.0 release. The most notable feature is the support for the external database. The feature will allow Platform engineers to use cf-for-k8s with an external Postgres database service. The cf-for-k8s team is thankful for the contribution from SAP and is looking forward to future contributions of similar impactful features.

Thank you from cf-for-k8s RelInt team,
Re: Deploying UAA for external users #uaa #cf

Shetty, Viraj S [CTR]
 

Thanks Jonathan. I will take a look at that.  
Re: Office Hours: CF on K8s Networking

Shannon Coen
 

We're ending the call early today on account of low (no) attendance. We'll host again in two weeks!

The CFF calendar can be found at https://www.cloudfoundry.org/community-calendar/.


Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272


From: cf-dev@... <cf-dev@...> on behalf of Dieu Cao via lists.cloudfoundry.org <dieuc=vmware.com@...>
Sent: Tuesday, July 14, 2020 2:23 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Office Hours: CF on K8s Networking
 
Awesome! Very excited that there'll be this new forum where folks can get engaged.

-Dieu
From: cf-dev@... <cf-dev@...> on behalf of Shannon Coen via lists.cloudfoundry.org <scoen=vmware.com@...>
Sent: Tuesday, July 14, 2020 12:37 PM
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] Office Hours: CF on K8s Networking
 
Hello CFF friends,

The CF on K8s Networking team will be hosting OSS office hours bi-weekly beginning next Wednesday, July 22. We've added the event to the CFF community calendar: https://www.cloudfoundry.org/community-calendar/.

We're working toward delivering all the same outcomes within the problem domains of traffic management and security achieved in CF for VMs, for all data paths (ingress, egress, and app-to-app), plus those that have been long requested and not yet realized. We welcome your questions, comments, collaboration, and contribution!

Best,

Shannon Coen (He/Him)
Manager, Product Management
scoen@...
875 Howard Street 5th Floor, San Francisco CA 94103
Mobile: +1.415.640.0272


Re: Deploying UAA for external users #uaa #cf

Jonathan Matthews <contact+cfdev@...>
 

On Tue, 21 Jul 2020 at 14:07, Shetty, Viraj S [CTR] via lists.cloudfoundry.org <vshetty=fdic.gov@...> wrote:
Thanks Enrique. We are deploying UAA in cloud.gov for our agency and it will be used by applications deployed in cloud.gov for our agency. I can add a nginx proxy in front but I think I should be able to filter IP addresses with spring or in the web.xml

Just in case this is useful to you, I suggest taking a look at the CF (hence probably also cloud.gov) feature called “Route Services”. 

Using this platform feature would allow you to deploy a vanilla UAA and decouple it (as an app) from its layer 4 / layer 7 protection.

Nginx can be used as a WAF in that topology, as can Haproxy or anything else reverse-proxy-ish. 

Personally, I’d chose that over relying on a block-/allow-list feature in the UAA itself, where you’d be dependent both on the feature’s presence and its correctness with no regressions over time. 

My 2¢ :-)

Jonathan
--
Jonathan Matthews
https://jpluscplusm.com
Re: Deploying UAA for external users #uaa #cf

Shetty, Viraj S [CTR]
 

Thanks Enrique. We are deploying UAA in cloud.gov for our agency and it will be used by applications deployed in cloud.gov for our agency. I can add a nginx proxy in front but I think I should be able to filter IP addresses with spring or in the web.xml. I can also probably check all the URLs used for a authentication_code or client_credentials flow using chrome and then whitelist only those. However, I am trying to see if this list is documented anywhere that I can simply use it. 

Thanks,
Viraj 
Re: Deploying UAA for external users #uaa #cf

Enrique Cano
 

I would expect you place a well hardened reverse proxy in front of your UAA, and that is what you use to control what is exposed to the outside world and what is not?

Regards

Enrique
Deploying UAA for external users #uaa #cf

Shetty, Viraj S [CTR]
 

We want to deploy UAA for external users of the organization. This UAA deployment would only be used by external users and so some of the URLs would have to be exposed to the internet. But I want a large part of the UAA api urls like /identityzones, /groups, /users etc to not be exposed to the internet (this is for extra security). The only URLs that really need to be exposed are the ones which is useful for the OAuth 2 flows for external users. I can use the IP filtering mechanism to remove access to these URLs. Can I do this in the uaa.yml file and if so - is there a known set of URLs which are normally exposed in these conditions? I would rather whitelist a set of URLs. Any help is appreciated. 
321 - 340 of 9440