Date   

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

 


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


BOSH PMC: Quarks Project Lead call for Nominations

Marco Voelz
 

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


Re: Proposal to retire the Perm project in the App Runtime PMC

Guillaume Berche
 

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


Update on the GA of cf CLI V7

Josh Collins <collinsjo@...>
 

Good Afternoon, Good Morning, and Good Evening,


We'd like to share a quick update regarding the GA of the v7 CLI. We're confident in the v7 GA and although the original target date hasn’t changed, we've made a few adjustments to how we’ll approach GA that you should be aware of.


TL;DR

  • We expect version 7.0.0 to release on or before June 22nd

  • The 7.0.0 release should have no impact to existing systems/workflows that rely on the v6 cf CLI

  • Thank you!


For those interested in more detail...

The following milestones are no longer considered pre-requisites for the GA of the v7 CLI (rationales for each is provided further below):


  1. Providing the package management infrastructure to support pinning to the v6 version of the CLI

  2. Getting the v7 CLI running in all of Release Integration's CF-Deployment CI pipelines


Rationales for the removal of  the following milestones:

  1. Providing the package management infrastructure to support pinning to the v6 version of the CLI:
    The v7 CLI depends on the latest CAPI release (v1.95.0), which the vast majority of foundations running in the wild will not have deployed yet.

    We’ve decided to publish the v7 GA to the various package managers we support in the same manner as we have been publishing the v7 betas.  Folks already consuming the v7 beta via a package manager should be updated to 7.0.0 the next time they update. Please note that the binary name of the cf CLI 7.0.0 will be `cf`, as opposed to the beta binary name `cf7`.

    This is intended to minimize disruption to the community and afford the CLI team the time we need to work through the discovered complexities of package management.

    As a result, staying on the major version of the CLI that you are currently consuming from package managers will not require special intervention (with the exception of those who are consuming the beta v7).

    For those who must do so, our Downloads section of the CLI README will be updated with instructions on how to switch back and forth between the v7 and v6 CLIs.

  2. Getting the v7 CLI running in all of the Release Integration team’s (RelInt’s) CF-Deployment CI pipelines:
    The purpose of RelInt's pipelines is to validate the stability of a particular combination of the component releases specified in the CF-Deployment manifest. In the context of RelInt's pipelines, the CLI is used as a vehicle to exercise the platform, and when their pipelines run green, a release of CF-Deployment can be published.

    While this milestone provides valuable information, it's not primarily a validation of the CLI itself. The pipelines that the CLI team manage test the CLI exhaustively.  When our pipelines run green, we can confidently release a version of CLI, including the GA of v7.

    That said, we've worked with the Release Integration team to get a copy of one of their pipelines running with the v7 CLI release candidate against a branch of cf-acceptance-tests with modifications necessary to run it.

    This helps us build confidence that the coming migration of all of the Release Integration team's pipelines will be relatively smooth.


We appreciate any efforts you take to share this information with others in the community and look forward to the GA of the cf CLI!


For more information and/or questions about the v7 CLI, please visit Cloud Foundry docs, message us on slack, or visit our github.


Thanks so very much,


The CLI Team



321 - 340 of 9378