Date   

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. 


A new major cf-acceptance tests (CATS) release v6.0.0 is available

Saikiran Yerram
 

Hello CF friends,

The new major release v6.0.0 of Cloud Foundry acceptance tests (CATS) now works with cf CLI v7. As you may be aware, the cf CLI team recently release the much-awaited v7 CLI that unlocks new app developer workflows for users who require granular control of their apps and other advanced deployment strategies. You can check out more @ https://docs.cloudfoundry.org/cf-cli/v7.html.

With this release, CATS will NO longer support running with cf CLI v6 and going forward it will only support running with cf CLI v7. If you're running CATS in your pipelines, we recommend you update your cf CLI to v7 or pin to an older version of CATS < v6.0.0.

It would have not been possible without the hard work of folks on the cf CLI team, V3 Acceleration Team, and Release Integration to come together and make this happen. 

-- Sai



Re: Isolation Segments

Daniel Jones
 

Assuming that the inputs are the same (same app code, same buildpack) then I would have thought that it's the environment that's different?

It might be worth asking on Garden channel in Cloud Foundry Slack - those folks are generally very helpful, and know a lot about the containerisation implementation that is used in the staging process.

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Thu, 16 Jul 2020 at 21:05, ross.kovelman via lists.cloudfoundry.org <ross.kovelman=merck.com@...> wrote:
Not that I can see, although we also do frequent "repaves" and we also somewhat recently did an upgrade to a newer version.  I'd like to think if it was a Diego cell it would have been destroyed and or rebuilt at one of those junctures?


Re: Isolation Segments

ross.kovelman@...
 

Not that I can see, although we also do frequent "repaves" and we also somewhat recently did an upgrade to a newer version.  I'd like to think if it was a Diego cell it would have been destroyed and or rebuilt at one of those junctures?

261 - 280 of 9377