1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Jesse Alford <jalford@...>
 

Changing branches breaks a lot of tooling, docs, and expectations.

If you're going to do it - which to be clear I think we should in this case -
it is better to move to what you'd prefer,
rather than make multiple such breaks.

I agree that `main` is a fine default and matches what Github will be migrating to.
If "default branch, plus whatever expectations you might bring with you about such a branch"
is what you want to communicate with your branch name, switch to `main`.

If "the place that active development should be pushed/merged to" and,
optionally,
"the place that deliberately released code should be pulled from"
is what you want to communicate, maybe use that pattern.

If you want to say something else with your branch names,
this is an opportunity to communicate.

Anyway. I support changes away from `master`,
but think we don't need to coordinate further on the matter.

From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <collinsjo@...>
Sent: Friday, June 26, 2020 9:58 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
 
I support this change.

Josh Collins - CF CLI PM
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

Josh Collins
 

I support this change.

Josh Collins - CF CLI PM

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

Daniel Jones
 

Cripes - by which I meant "any future branch name changes". Not any future code changes. That'd be a bit extreme.

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


On Fri, 26 Jun 2020 at 15:20, Daniel Jones via lists.cloudfoundry.org <daniel.jones=engineerbetter.com@...> wrote:
+1 for switching to "main", and for postponing any possible further changes until after that's done.

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


On Thu, 25 Jun 2020 at 20:23, Troy Topnik <troy.topnik@...> wrote:
I spoke to Jan Dubois about the 'main' vs. 'release' consideration, and he found this PR:
https://github.com/gitgitgadget/git/pull/655
which indicates that the new default branch name for `git init` will be 'main' (if/when the PR is merged).

This seems to be fairly strong argument to use 'main' as the default branch name.

I'll raise this with the Extensions PMC project leads and recommend switching to 'main'.

TT


--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Daniel Jones
 

+1 for switching to "main", and for postponing any possible further changes until after that's done.

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


On Thu, 25 Jun 2020 at 20:23, Troy Topnik <troy.topnik@...> wrote:
I spoke to Jan Dubois about the 'main' vs. 'release' consideration, and he found this PR:
https://github.com/gitgitgadget/git/pull/655
which indicates that the new default branch name for `git init` will be 'main' (if/when the PR is merged).

This seems to be fairly strong argument to use 'main' as the default branch name.

I'll raise this with the Extensions PMC project leads and recommend switching to 'main'.

TT


--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Troy Topnik
 

I spoke to Jan Dubois about the 'main' vs. 'release' consideration, and he found this PR:
https://github.com/gitgitgadget/git/pull/655
which indicates that the new default branch name for `git init` will be 'main' (if/when the PR is merged).

This seems to be fairly strong argument to use 'main' as the default branch name.

I'll raise this with the Extensions PMC project leads and recommend switching to 'main'.

TT


--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
Re: After Summit questions

Stephen Levine <slevine@...>
 

>  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]

In a way, BOSH did handle patching the container base images. When deploying a new CF rootfs (e.g., cflinuxfs3), rolling the BOSH VMs would update the container base images for every app with security patches. New cell VMs would come up with a patched version of cflinuxfs3, then old ones would go down.

For CF4K8s, this will be handled by kpack, which uses CNB (buildpacks.io) image rebasing functionality to swap the bottom OS layers of the deployed container images directly on the registry.
This results in the new container base images being distributed to each K8s node exactly once per base image update, after the first rebased image is deployed.
Then all the other images deployed on the node will "snap around" to point at the newly available base.
(This is a safe operation, because ABI compatibility is preserved when security patches are applied to the new base images -- just like in the CF model.)

From: cf-dev@... <cf-dev@...> on behalf of Krannich, Bernd <bernd.krannich@...>
Sent: Thursday, June 25, 2020 2:57 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] After Summit questions
 

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

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
321 - 340 of 9387