1. Cf-Dev
  2. Messages

Expanded

Topics Messages
   Date   
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Marco Voelz
 

Hi everyone,

 

I really appreciate this effort, thanks Dieu for bringing this up! From reading this thread I get the understanding that we're now already discussing what the best name for the bfkam (branch formally known as master) would be, given each team's specific interpretation and usage of that very branch.

 

While I'm all for discussions to reach a reasonable consensus, this already starts to look a lot like bikeshedding to me: We're talking about personal and team preferences, tailored to specific needs and usage. Given that for years noone bothered to look at the name more closely to consider renaming it to something different than 'master', I'm hoping that we can cut this discussion short and find a quick agreement on what the new name should be. Ideally across all CFF projects, at least within a PMC.

 

I'm voting +1 on 'main' for now, to reach this agreement more quickly. I'd be fine if any other name makes it as well, if that matters.

 

Thanks and warm regards

Marco

 

From: <cf-dev@...> on behalf of Jan Dubois <JDubois@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 25. June 2020 at 06:53
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos

 

I too agree with Jesse that in repos where you have `master` and `develop` branches, renaming `master` to `release` is more clear than using `main`.

 

For repos that have just a single trunk branch I have a slight personal preference for `latest`, as it mirrors the tag typically used to identify the latest build of a container image.

 

`main` also still has a connotation of being superior to the others (additional/auxiliary/supplemental/subordinate/???), which `latest` doesn't, imho.

 

"I've tested against the `latest` branch, and the issue is still reproducible" sounds descriptive to me.

 

Just using `develop` as the only branch could work too. E.g. UAA only uses `develop` and hasn't pushed to `master` since 2018, so you could just delete their `master` and nobody would notice... :)

 

Cheers,

-Jan



On Jun 24, 2020, at 11:33 AM, Caroline Taymor via lists.cloudfoundry.org <taymorc=vmware.com@...> wrote:

 

I agree with Jesse. Renaming from `master` is a great idea which I strongly support. `main` is similar but more inclusive, but perhaps we can take the opportunity to increase the semantic meaning of the branch names.

Caroline

 

From: <cf-dev@...> on behalf of Jesse Alford <jalford@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, June 24, 2020 at 11:11 AM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos

 

Could we consider using `develop` (and/or, where appropriate, `release` and version-specific branches) instead?

 

In addition to being problematic, `master` is confusing, as it means different things in different processes.

 

`develop`/`release` makes it clear what branch you're supposed to push/merge to.

 

As an example, `cf-deployment` currently has `develop` and `master`, with `master` being effectively a release branch - all releases are ff-only merges tagged on `master` with a version number. `main` would be less clear than `release` in this case - and, I suspect, in many others.

From: cf-dev@... <cf-dev@...> on behalf of Lee Porte via lists.cloudfoundry.org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Wednesday, June 24, 2020 12:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos

 

Hi all, 

 

I am also in support of this change after enquiring on slack.

 

Cheers

 

L

 

On Tue, 23 Jun 2020 at 23:06, Dieu Cao <dieuc@...> wrote:

Hey all,

I would like to propose that the cloud foundry projects rename the primary branch on allhttps://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.

I believe some project teams independently have plans to invest in making this change.

Thoughts? Feedback?

-Dieu


 

-- 

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

‪020 3920 6036

07785 449292

 
Re: After Summit questions

Krannich, Bernd
 

Hi Ross,

 

I haven’t tried Fargate myself (and I don’t know if this has been tried/is supported for CF on Kubernetes), but running CF on top of Kubernetes, “patching” might refer to two separate layers:

 

  1. Patching the Cloud Foundry “software” itself: Similar to cf-deployment, what you’ll get with both kubecf and cf-for-k8s is new versions of Cloud Foundry. Primarily, these are container images containing the “new bits” (plus some declarative way [like plain YAML files, Helm templates, kapp templates, depending on your distro] describing to Kubernetes how these container images will be run exactly). These “new bits” are essentially the combination of what used to be the BOSH stemcell and the BOSH releases packaged on top. In order to either update the OS distribution CF is using in its container images or to update the version of components, new container images will need to be built/provided and rolled out to your Kubernetes cluster (both kubecf as well as cf-for-k8s provide ways to do this with kubecf being more close to what people are used to from the BOSH world).
  2. Patching the host OS the Kubernetes nodes are running on: If you are using a managed Kubernetes offering, your Kubernetes provider will have some means to ensure that your Kubernetes node host OS can be kept up-to-date (I believe in Fargate this process is even more hidden from you because AFAIK Fargate doesn’t even make the concept of separate hosts visible to users, but I might be wrong here). Likewise, if you deploy and manage the Kubernetes cluster yourself, you’ll need to ensure that the OS your Kubernetes nodes (and the Kubernetes control plane which in managed offerings is something your provider takes care of) are running on is kept up-to-date. This type of patching is outside the realm of Cloud Foundry itself (whereas in a BOSH world where CF jobs were running on the VM itself, as opposed to “inside containers on a VM”, BOSH did indeed take care of that part [but then also there wasn’t the task to keep the container OS distro up-to-date – see #1]).

 

Hope this helps more than it creates confusion. I realize things have gotten more complex on this front and probably what I wrote can be explained in a more accessible way (my bad). 😉

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of "ross.kovelman via lists.cloudfoundry.org" <ross.kovelman=merck.com@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 25. June 2020 at 03:45
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] After Summit questions

 

Hi all,
After the first day of the summit, while very interesting, it left me and my teammates with a question. With no Bosh, since Bosh is for VMs, how will patching be done, especially when you use CF on a service like Fargate?

Thanks in advance for any answers you might have.
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Jan Dubois <JDubois@...>
 

I too agree with Jesse that in repos where you have `master` and `develop` branches, renaming `master` to `release` is more clear than using `main`.

For repos that have just a single trunk branch I have a slight personal preference for `latest`, as it mirrors the tag typically used to identify the latest build of a container image.

`main` also still has a connotation of being superior to the others (additional/auxiliary/supplemental/subordinate/???), which `latest` doesn't, imho.

"I've tested against the `latest` branch, and the issue is still reproducible" sounds descriptive to me.

Just using `develop` as the only branch could work too. E.g. UAA only uses `develop` and hasn't pushed to `master` since 2018, so you could just delete their `master` and nobody would notice... :)

Cheers,
-Jan

On Jun 24, 2020, at 11:33 AM, Caroline Taymor via lists.cloudfoundry.org <taymorc=vmware.com@...> wrote:

I agree with Jesse. Renaming from `master` is a great idea which I strongly support. `main` is similar but more inclusive, but perhaps we can take the opportunity to increase the semantic meaning of the branch names.
Caroline
 
From: <cf-dev@...> on behalf of Jesse Alford <jalford@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, June 24, 2020 at 11:11 AM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
Could we consider using `develop` (and/or, where appropriate, `release` and version-specific branches) instead?
 
In addition to being problematic, `master` is confusing, as it means different things in different processes.
 
`develop`/`release` makes it clear what branch you're supposed to push/merge to.
 
As an example, `cf-deployment` currently has `develop` and `master`, with `master` being effectively a release branch - all releases are ff-only merges tagged on `master` with a version number. `main` would be less clear than `release` in this case - and, I suspect, in many others.
From: cf-dev@... <cf-dev@...> on behalf of Lee Porte via lists.cloudfoundry.org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Wednesday, June 24, 2020 12:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
Hi all, 
 
I am also in support of this change after enquiring on slack.
 
Cheers
 
L
 
On Tue, 23 Jun 2020 at 23:06, Dieu Cao <dieuc@...> wrote:
Hey all,
I would like to propose that the cloud foundry projects rename the primary branch on allhttps://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.
I believe some project teams independently have plans to invest in making this change.
Thoughts? Feedback?
-Dieu

 
-- 
Lee Porte
Reliability Engineer 
GOV.UK PaaS Team
‪020 3920 6036
07785 449292
After Summit questions

ross.kovelman@...
 

Hi all,
After the first day of the summit, while very interesting, it left me and my teammates with a question. With no Bosh, since Bosh is for VMs, how will patching be done, especially when you use CF on a service like Fargate?

Thanks in advance for any answers you might have.
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Caroline Taymor <taymorc@...>
 

I agree with Jesse. Renaming from `master` is a great idea which I strongly support. `main` is similar but more inclusive, but perhaps we can take the opportunity to increase the semantic meaning of the branch names.

Caroline

 

From: <cf-dev@...> on behalf of Jesse Alford <jalford@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, June 24, 2020 at 11:11 AM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos

 

Could we consider using `develop` (and/or, where appropriate, `release` and version-specific branches) instead?

 

In addition to being problematic, `master` is confusing, as it means different things in different processes.

 

`develop`/`release` makes it clear what branch you're supposed to push/merge to.

 

As an example, `cf-deployment` currently has `develop` and `master`, with `master` being effectively a release branch - all releases are ff-only merges tagged on `master` with a version number. `main` would be less clear than `release` in this case - and, I suspect, in many others.

From: cf-dev@... <cf-dev@...> on behalf of Lee Porte via lists.cloudfoundry.org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Wednesday, June 24, 2020 12:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos

 

Hi all,

 

I am also in support of this change after enquiring on slack.

 

Cheers

 

L

 

On Tue, 23 Jun 2020 at 23:06, Dieu Cao <dieuc@...> wrote:

Hey all,

I would like to propose that the cloud foundry projects rename the primary branch on all https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.

I believe some project teams independently have plans to invest in making this change.

Thoughts? Feedback?

-Dieu


 

--

Lee Porte

Reliability Engineer 

GOV.UK PaaS Team

‪020 3920 6036

07785 449292
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Jesse Alford <jalford@...>
 

Could we consider using `develop` (and/or, where appropriate, `release` and version-specific branches) instead?

In addition to being problematic, `master` is confusing, as it means different things in different processes.

`develop`/`release` makes it clear what branch you're supposed to push/merge to.

As an example, `cf-deployment` currently has `develop` and `master`, with `master` being effectively a release branch - all releases are ff-only merges tagged on `master` with a version number. `main` would be less clear than `release` in this case - and, I suspect, in many others.

From: cf-dev@... <cf-dev@...> on behalf of Lee Porte via lists.cloudfoundry.org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Wednesday, June 24, 2020 12:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
Hi all,

I am also in support of this change after enquiring on slack.

Cheers

L

On Tue, 23 Jun 2020 at 23:06, Dieu Cao <dieuc@...> wrote:
Hey all,
I would like to propose that the cloud foundry projects rename the primary branch on all https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.
I believe some project teams independently have plans to invest in making this change.
Thoughts? Feedback?
-Dieu



--
Lee Porte
Reliability Engineer 
GOV.UK PaaS Team
‪020 3920 6036‬
07785 449292
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Shannon Coen <scoen@...>
 

Speaking for the CF Networking team, we're supportive.

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 Lee Porte via lists.cloudfoundry.org <lee.porte=digital.cabinet-office.gov.uk@...>
Sent: Wednesday, June 24, 2020 12:22 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
Hi all,

I am also in support of this change after enquiring on slack.

Cheers

L

On Tue, 23 Jun 2020 at 23:06, Dieu Cao <dieuc@...> wrote:
Hey all,
I would like to propose that the cloud foundry projects rename the primary branch on all https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.
I believe some project teams independently have plans to invest in making this change.
Thoughts? Feedback?
-Dieu



--
Lee Porte
Reliability Engineer 
GOV.UK PaaS Team
‪020 3920 6036‬
07785 449292
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Lee Porte
 

Hi all,

I am also in support of this change after enquiring on slack.

Cheers

L

On Tue, 23 Jun 2020 at 23:06, Dieu Cao <dieuc@...> wrote:
Hey all,
I would like to propose that the cloud foundry projects rename the primary branch on all https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.
I believe some project teams independently have plans to invest in making this change.
Thoughts? Feedback?
-Dieu



--
Lee Porte
Reliability Engineer 
GOV.UK PaaS Team
‪020 3920 6036‬
07785 449292
Re: Proposal to retire the Perm project in the App Runtime PMC

Eric Malm
 

Hi, everyone,

The App Runtime PMC approved the proposal to retire the Perm project at today's PMC meeting. The corresponding project repositories are now located in the CF attic; see https://github.com/cloudfoundry-attic?q=perm for the full list.

Thanks,
Eric

From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Tuesday, June 23, 2020 9:28 AM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
 
Hi Eric,

Thanks for the clarifications!

Regards,

Guillaume.

Le mar. 23 juin 2020 à 17:08, Eric Malm <emalm@...> a écrit :
Hi, Guillaume,

I was referring to identity concepts and protocols (such as OAuth, OIDC, RBAC, and SPIFFE) generally when I mentioned evolution within the identity space. I don't believe there are any specific proposals in the community yet about how to proceed with the next round of Perm-like work.

I certainly expect that part of working out useful ways to separate and to refine the authorization roles in Cloud Controller will be to ensure backwards compatibility with the existing CF CLI and CC API authentication and authorization workflows, and that app developers in particular would be insulated from the details of K8s RBAC, OPA, or other systems that may implement these identity and auth capabilities. Platform operators would likely have more direct exposure to those details, though, to the extent that they would be responsible for deploying those systems, administering them, and connecting them to an external identity provider.

Thanks,
Eric 
From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Wednesday, June 17, 2020 12:42 PM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
 
Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Eric Malm
 

I'm also in support of this change and would be happy to coordinate with the App Runtime project teams to apply it across their repositories.

Best,
Eric

From: cf-dev@... <cf-dev@...> on behalf of Alex Ley via lists.cloudfoundry.org <aley=vmware.com@...>
Sent: Tuesday, June 23, 2020 3:30 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
I support this change. 
From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Tuesday, June 23, 2020 11:21:12 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
I agree.

Dr Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Alex Ley <aley@...>
 

I support this change. 

From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Tuesday, June 23, 2020 11:21:12 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
I agree.

Dr Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Dr Nic Williams <drnicwilliams@...>
 

I agree.

Dr Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Proposal to Rename the Primary Branch on all Cloud Foundry repos

Dieu Cao <dieuc@...>
 

Hey all,
I would like to propose that the cloud foundry projects rename the primary branch on all https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.
I believe some project teams independently have plans to invest in making this change.
Thoughts? Feedback?
-Dieu
Re: Proposal to retire the Perm project in the App Runtime PMC

Guillaume Berche
 

Hi Eric,

Thanks for the clarifications!

Regards,

Guillaume.

Le mar. 23 juin 2020 à 17:08, Eric Malm <emalm@...> a écrit :
Hi, Guillaume,

I was referring to identity concepts and protocols (such as OAuth, OIDC, RBAC, and SPIFFE) generally when I mentioned evolution within the identity space. I don't believe there are any specific proposals in the community yet about how to proceed with the next round of Perm-like work.

I certainly expect that part of working out useful ways to separate and to refine the authorization roles in Cloud Controller will be to ensure backwards compatibility with the existing CF CLI and CC API authentication and authorization workflows, and that app developers in particular would be insulated from the details of K8s RBAC, OPA, or other systems that may implement these identity and auth capabilities. Platform operators would likely have more direct exposure to those details, though, to the extent that they would be responsible for deploying those systems, administering them, and connecting them to an external identity provider.

Thanks,
Eric 
From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Wednesday, June 17, 2020 12:42 PM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
 
Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Re: Proposal to retire the Perm project in the App Runtime PMC

Eric Malm
 

Hi, Guillaume,

I was referring to identity concepts and protocols (such as OAuth, OIDC, RBAC, and SPIFFE) generally when I mentioned evolution within the identity space. I don't believe there are any specific proposals in the community yet about how to proceed with the next round of Perm-like work.

I certainly expect that part of working out useful ways to separate and to refine the authorization roles in Cloud Controller will be to ensure backwards compatibility with the existing CF CLI and CC API authentication and authorization workflows, and that app developers in particular would be insulated from the details of K8s RBAC, OPA, or other systems that may implement these identity and auth capabilities. Platform operators would likely have more direct exposure to those details, though, to the extent that they would be responsible for deploying those systems, administering them, and connecting them to an external identity provider.

Thanks,
Eric 

From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Wednesday, June 17, 2020 12:42 PM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
 
Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Martijn de Boer
 

 
I assume the reverse proxy functionality between apps would not work when mutual TLS with X.509 certificates is in place. In this case the certificate (forwarded as header) would be filtered out.
 
Gesendet: Dienstag, 16. Juni 2020 um 09:39 Uhr
Von: "Marco Voelz" <marco.voelz@...>
An: "cf-dev@..." <cf-dev@...>
Betreff: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Great, thanks for the clarification!

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 11. June 2020 at 02:46
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Jonathan is correct. 

 

This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).

 

And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).

 

In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!

 

From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Marco,

 

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

 

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

 

HTH,

Jonathan

 

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

 
Updated Password policy will be changed to configurations added in uaa.yml file after restarting uaa tomcat. #cf #uaa

shilpa kulkarni
 

Hi All,

I have used update identity provider api(https://docs.cloudfoundry.org/api/uaa/version/74.21.0/index.html#update) to update the password policy.
It worked for me. But if I restart my uaa tomcat then the password policy will be changed to configurations added in uaa.yml. Why the settings will change?Can anyone please provide solution for this?

Thanks & Regards
Shilpa Kulkarni
Re: Customize the Email content of password reset request #cf #uaa

shilpa kulkarni
 

I got to know to change the email content of password reset request. In the uaa tomcat in the templates\mail\reset_password.html file I have customized the content. But I want to pass username in the email content but not getting the username. Can anyone please help me in resolving the issue?
Re: BOSH PMC: Quarks Project Lead call for Nominations

Vlad Iovanov
 

Hi, everyone,

 

SUSE is nominating Mario Manno for the Quarks Project Lead in the BOSH PMC.

 

Mario works as an open-source developer in the platform department at SUSE.

He joined the Cloud Foundry Foundation as a committer in 2017.

He now works on project Quarks to create Kubernetes controllers for Cloud Foundry.

 

Thanks,

Vlad Iovanov

 

From: Marco Voelz via lists.cloudfoundry.org
Sent: Thursday, June 18, 2020 9:52 AM
To: cf-bosh@...; cf-dev@...
Subject: [cf-bosh] BOSH PMC: Quarks Project Lead call for Nominations

 

Hi everyone,

 

Vlad Iovanov, the lead for the Quarks project within the BOSH PMC, is stepping down from the project, to focus on KubeCF and responsibilities internal to SUSE. We thank him for his service.

 

The Quarks team now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on June 25th.

 

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead

 

E17E0EFE1BEF4601BB8AB3B48E1EC35E.png

Re: [CAUTION] [cf-dev] BOSH PMC: Quarks Project Lead call for Nominations

Marco Voelz
 

Hi everyone,

 

SUSE is nominating Mario Manno for the Quarks Project Lead in the BOSH PMC.

Mario works as an open-source developer in the platform department at SUSE.

He joined the Cloudfoundry Foundation as a committer in 2017.

He now works on project Quarks to create Kubernetes controllers for Cloudfoundry.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 18. June 2020 at 08:54
To: "cf-bosh@..." <cf-bosh@...>, "cf-dev@..." <cf-dev@...>
Subject: [CAUTION] [cf-dev] BOSH PMC: Quarks Project Lead call for Nominations

 

Hi everyone,

 

Vlad Iovanov, the lead for the Quarks project within the BOSH PMC, is stepping down from the project, to focus on KubeCF and responsibilities internal to SUSE. We thank him for his service.

 

The Quarks team now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on June 25th.

 

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead
381 - 400 of 9441