Date   
Re: cf-deployment 3.0

Franks, Geoff
 

How long will 1.x, and 2.x cf-deployments be maintained with security patches? Without that, it sounds like there’s potential for a lot of organizations to be faced with breaking changes and instability every time they upgrade (if upgrade cycles internally take a month or two, and major versions are coming out as often or more), not to mention the difficulties of jumping multiple major versions at once.

 

From: <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, July 3, 2018 at 6:16 PM
To: cf-eng <cf-eng@...>, cf-pm <cf-pm@...>, "cf-dev@..." <cf-dev@...>, CF Dev <cf-dev-eng@...>
Subject: [External] [cf-dev] cf-deployment 3.0

 

Hey Y'all,

 

Cf-deployment 3.0 is around the corner. 

We're going to go 3.0 in 2-3 weeks.

 

We released cf-deployment 2.0 on June 18th and included 'breaking' changes.

 

Breaking changes in the context of cf-d are changes which would require special attention from operators for the deployment to succeed. Executing the same bosh deploy command/args run used in the previous deployment may fail depending on which ops files and features operators had deployed with in the past.

 

Going forward, we'd like to introduce a more regular (~monthly) cadence to major point releases of cf-deployment.

 

The goal is two-fold and in-order-of-importance:

  1. provide a reliable mechanism for cf component teams to integrate and release major  changes
  2. mitigate fear of major point releases in the minds of operators/cf-consumers

 

As of today, we've got one PR that includes breaking changes and I'm putting out a call to y'all.

If you've got what you'd consider to be a breaking change that warrants going out in a major point release of cf-deployment, please submit your PRs and reach out to the RelInt team as soon as you're able to so we can come up to speed and support you!

 

Cheers,

 

Josh

 

 

 

 

 

Re: New PM for CF AutoScaler project [Re: PM Vacancy for Auto-Scaler]

Marco Nicosia
 

Welcome to the project, Bo!


On Thu, Jul 5, 2018 at 07:38 Michael Maximilien <maxim@...> wrote:
Hi, all,

Please welcome Bo Yang (on cc:) of IBM as PM for CF App AutoScaler Extensions project [0].


You can keep up with the project’s monthly drumbeat as well as other CF Extensions updates here [1].


Welcome Bo, I look forward to working with you.


Best,




On Jun 25, 2018, at 1:02 PM, Michael Maximilien <maxim@...> wrote:

Hi, all,

We have a PM vacancy for the AutoScaler project and the team has nominated Bo Yang from IBM (one of the lead engineers for the initial project) as replacement.

Please suggest any other nominations before July 2nd. We will decide after if a vote is necessary.

Thanks for your time. Best,

dr.max
ibm ☁ 
silicon valley, ca


--
You received this message because you are subscribed to the Google Groups "PMC Council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pmc-council+unsubscribe@....
To post to this group, send email to pmc-council@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/pmc-council/OFCD4858D1.8DFC287A-ON002582B7.006E06D5-1529956907534%40notes.na.collabserv.com.

--
--
  Marco Nicosia
  Product Manager
  Pivotal Software, Inc.
  c: 650-796-2948

Service Plan Descriptions

Alexander Blease <ablease@...>
 

Hi Everyone,


The Services API team is thinking about limiting the size of service plan descriptions to 10,000 characters, upon registering a service broker in Cloud Foundry. We would be keen to hear from people who have specific use cases for descriptions that are longer than 10,000 chars.


If we imposed this limit, would you strongly object to this change, and why?


If you have thoughts, queries, concerns, please contact us on the #sapi channel on the Cloud Foundry Slack, or respond directly to this email.


Cheers,


Alex + Niki



cf-deployment transition to Xenial stemcell

Josh Collins
 

CF-Deployment default to Ubuntu 16.04 (Xenial Xerus) BOSH stemcells in late-Fall/early-Winter 2018.


Canonical will stop providing security updates for the current Ubuntu 14.04 (Trusty Tahr), the current cf-deployment default, in April 2019 per their official support lifecycle policy.


CF-Deployment plans to transition to the fully-supported Xenial stemcell lines well before April 2019 and we’ll need each component team to validate the Xenial stemcell against their components before making the switch.


If each component's features are confirmed compatible before the end of September 2018, we should be able to hit our intended target for the transition.


CF-D/Xenial Status to-date:

  • The CF-Deployment Release Integration team (RelInt) began testing Xenial in cf-deployment via experimental ops files on June 8th 2018 (in cf-deployment release v1.40.0).
  • From June 8th forward, RelInt has been running cf-acceptance-tests (CATs) against our experimental pipeline with Xenial enabled.
  • We have observed no discernible effect on the CATs failure rate before/after transitioning to Xenial.


This message is a gentle invitation to begin/continue validating your component against Xenial.


Note that RelInt validates releases via CATs. The scope of CATs is purposely limited to validating core cf workflows.

The stability of cf-deployment releases assumes each component team executes a much deeper level of component-specific testing before integrating into cf-deployment.

For this reason, we don't/won't recommend using Xenial for production installs of cf-deployment nor make Xenial default in CF-D until each component team has validated that all its supported features are compatible with the Xenial stemcell.


We've proven Xenial can be run in a pipeline and CATs will pass so now's the time.

Please do due diligence and let us know when you've completed your validation.


And as always, please feel free to reach out to RelInt with any questions, issues, comments or suggestions you may have.

Thanks so much!

Josh Collins
Release Integration PM

Re: CF Application Runtime PMC - CF Networking Project Lead Call for Nominations

Dieu Cao
 

Hello all,

Pivotal is nominating Preethi Varambally for the CF Networking Project Lead in the Application Runtime PMC.

Any other nominations should be sent to me/in reply by end of day July 3rd, 2018.

Preethi previously worked as a technical product owner and business analyst at a GIS company on a customer facing web application. Here, along with managing the product, she also worked on designing application layer data flow architecture for efficiently getting data from various source systems.

Prior to this, she worked as an engineer, building data tracking and reporting tools using MVC framework and gradually moved to a product owner role managing a team of onshore and offshore engineers.

Preethi holds a Masters degree in Computer Science from University of Texas, Dallas. 

-Dieu Cao

On Mon, Jul 2, 2018 at 11:45 AM Dieu Cao <dcao@...> wrote:
Hello All,

Usha Ramachandran, the Project Lead for the CF Networking team within the Application Runtime PMC, is rotating into a role internal to Pivotal. We thank her for her time serving as the CF Networking Project Lead.

The CF Networking team, split between San Francisco and Santa Monica, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member.

Please send nominations to me/in reply to this posting by end of day July 11th, 2018.

If you have any questions about the role/process, please let me know.
These are described in the CFF governance documents. [1]

-Dieu Cao

CF Application Runtime PMC Lead

Xenial stemcells now available: migration plan

Frédéric Desbiens
 

Hi everyone.


My name is Frédéric. I joined the BOSH team as a product manager recently, and work from Pivotal's Toronto office. Nice to meet you all!


A few weeks ago, the BOSH team introduced a new stemcell line based on Ubuntu 16.04 (Xenial Xerus) on bosh.io. For the time being, this line will be maintained in parallel with the previous ones, based on Ubuntu 14.04 (Trusty Tahr).


Canonical will provide security updates for Trusty until April 2019 per their official support lifecycle policy. Because Canonical will no longer provide security updates for Trusty after April 2019, we strongly recommend users start migrating towards the Xenial-based stemcell line now.


The BOSH team will continue to support the current 3586.x line of Trusty-based stemcells with upstream security patches until the CFAR migration to Xenial is complete. We do not plan on releasing any new major versions of Trusty-based stemcells, unless consumers have a specific request for a new major, and instead will focus on Xenial going forward.


We are currently evaluating when we will retire the Trusty-based stemcells, and are looking for feedback from the community about technical blockers that could impede the adoption of Xenial stemcells. If you are a release author, please take the time to verify your software on Xenial-based stemcells at the earliest opportunity. As a reminder, operators using cf-deployment must keep in mind that the repository will switch to Xenial-based stemcells well before April 2019 and should plan accordingly (more details on this can be found here).


    Frédéric Desbiens
    Product Manager | Pivotal Cloud Foundry BOSH

Re: [cf-bosh] Xenial stemcells now available: migration plan

Dr Nic Williams
 

Frédéric, when will Xenial stemcells move from X to X.Y version numbering with less regular updates of the major version X? This will help compiled releases to not have to update as often.

Nic

 


From: 30461002200n behalf of
Sent: Wednesday, July 11, 2018 7:02 am
To: cf-bosh@...; cf-dev@...
Subject: [cf-bosh] Xenial stemcells now available: migration plan
 

Hi everyone.


My name is Frédéric. I joined the BOSH team as a product manager recently, and work from Pivotal's Toronto office. Nice to meet you all!


A few weeks ago, the BOSH team introduced a new stemcell line based on Ubuntu 16.04 (Xenial Xerus) on bosh.io. For the time being, this line will be maintained in parallel with the previous ones, based on Ubuntu 14.04 (Trusty Tahr).


Canonical will provide security updates for Trusty until April 2019 per their official support lifecycle policy. Because Canonical will no longer provide security updates for Trusty after April 2019, we strongly recommend users start migrating towards the Xenial-based stemcell line now.


The BOSH team will continue to support the current 3586.x line of Trusty-based stemcells with upstream security patches until the CFAR migration to Xenial is complete. We do not plan on releasing any new major versions of Trusty-based stemcells, unless consumers have a specific request for a new major, and instead will focus on Xenial going forward.


We are currently evaluating when we will retire the Trusty-based stemcells, and are looking for feedback from the community about technical blockers that could impede the adoption of Xenial stemcells. If you are a release author, please take the time to verify your software on Xenial-based stemcells at the earliest opportunity. As a reminder, operators using cf-deployment must keep in mind that the repository will switch to Xenial-based stemcells well before April 2019 and should plan accordingly (more details on this can be found here).


    Frédéric Desbiens
    Product Manager | Pivotal Cloud Foundry BOSH

Feedback requested: More than one service possible with the same name

Jennifer Spinney
 

Hi cf-dev,


As part of the work to support different service brokers being able to provide services and service plans with the same name (See “Improving Service Access in Cloud Foundry” [1]), we came across an Cloud Controller API change we’d like to make that has the potential to be disruptive to current clients, depending what assumptions they’re making.

The list services endpoint (i.e., GET /v2/services) allows a client to specify a service name as a query parameter (i.e., GET /v2/services?q=label:<service-name>). This endpoint always returns an array, even though today that array can only consist of 1 or 0 elements, since service names are globally unique across the entire platform.


In the future we plan to allow different services to have the same name, as long as the services are being provided by different brokers, which leads to the possibility of this request returning an array with two or more elements.

Our concern is that some clients might be currently relying on the fact that today’s response, while an array, can only respond with at most one service. Hence if two (or more) services are being returned such a client might pick the first one without realizing it might be the wrong service.


We’d like to know if anyone is using this endpoint in that way and whether they’d be affected by this query now possibly returning more than one service in the returned array.

Thanks,
Services API (SAPI) Team


Re: cf-deployment 3.0

Josh Collins
 

The Release Integration team hasn't provided security releases in the past -- for neither cf-release nor cf-deployment -- and doing so would be burdensome and impede the evolution of cf-deployment. Therefore, we're not currently planning to start providing security patches. But we appreciate the feedback and will keep an eye on the problem.

Because the RelInt team's primary goal is to support the CF Foundation engineering teams and their ability to validate their commits in CI, we need to focus more on keeping up-to-date with their changes. We want to set a release cadence that's aligned with, and ideally increases, the velocity of the teams. Take a look at the what happened with container networking when they wanted to ship 2.0...

Thanks for reaching out Geoff!

Re: Clarification regarding Custom roles in CF

Christopher Brown
 

Hi there,

Thank you for the feedback!

Unfortunately it's not currently possible to customize the existing roles or add new roles to the system. However, we (the CF Permissions team) are working on adding these features at the moment. You can read more about the project in our incubation proposal. Progress has been slower than we had hoped but we're advancing and are looking for a better way to expose this progress to the community so that folks can follow along. I'll post an update once we have something to show.

Please let me know if you have any other questions.

Thanks and all the best,
Christopher
CF Permissions PM


On Thu, Jun 28, 2018 at 12:41 AM Raghav, Prashant <prashant.raghav@...> wrote:
Hi Team,
We would need clarification regarding custom roles on Cloud foundry.
 
Our use case is as follows:
 
Relevant permissions:
  1. deploy applications
  2. (re)start/stop applications
  3. access application logs
  4. bind cf services to applications
  1. market place services, e.g. MySQL
  2. user-provided services, e.. for storing access credentials of external services on AWS
  1. create/update cf services, e.g. set access credentials
  2. view cf service settings via the cf command line interface, e.g. see unencrypted passwords
Defining roles and permissions is tightly integrated with the intended work processes.
In a DevOps I would suggest the following:
  • Role DevOp
  • permissions 1, 2, 3, 4
  • Role Admin
  • permissions 5, 6
 
 
Could you please provide solution for such kind of issues.
 
Thanks & Regards, 
Prashant Raghav
B&PS-IN-CLD 
Atos India Pvt. Ltd, 
Embassy Tech zone,  
MIDC - Phase II Block 1.5, 
Hinjewadi, Pune. 
Email : prashant.raghav@... 
 
 
 
 

CAB call for July is Wednesday 07/18 @ 8a PST or 11a EST

Michael Maximilien
 

FYI...


Please remember to join the Zoom call [0] Wednesday July 18th at 8a Pacific for QAs, highlights, and two presentations:


1. Project Shield v8 Updates by James Hunt of Stark & Wayne [1] 


2. CF-Extensions Project Service Fabrik Updates by Ashish Jain of SAP  [2] and [3]


Zoom soon. Best,



Re: cf-deployment 3.0

Marco Voelz
 

Dear Josh,

 

You are correct, in the past the RelInt team hasn't provided security releases. Instead, the credo was to go forward with the regular releases to also get the newest security fixes. This, however, was only easily possible because *the newer version did not introduce breaking changes with potentially big impact at the same time*.

 

I understand your mission of helping other teams increase their velocity. Maintaining multiple branches with fixes is certainly not fun, and I agree that it makes sense to try to avoid this if possible. I'm not sure I get the container networking 2.0 reference, though. Could you elaborate a bit more on this and how it is related to the current discussion?

 

Thanks and warm regards

Marco

 

From: <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 11. July 2018 at 20:43
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] cf-deployment 3.0

 

The Release Integration team hasn't provided security releases in the past -- for neither cf-release nor cf-deployment -- and doing so would be burdensome and impede the evolution of cf-deployment. Therefore, we're not currently planning to start providing security patches. But we appreciate the feedback and will keep an eye on the problem.


Because the RelInt team's primary goal is to support the CF Foundation engineering teams and their ability to validate their commits in CI, we need to focus more on keeping up-to-date with their changes. We want to set a release cadence that's aligned with, and ideally increases, the velocity of the teams. Take a look at the what happened with container networking when they wanted to ship 2.0...

Thanks for reaching out Geoff!

Re: BlockHeads Broker - Proposal for Incubation in the Extensions

Michael Maximilien
 

Hi, all,

It’s been about one month since this proposal has been submitted. I don’t see any pending unresolved issues or comments.

Therefore, according to our process [0] and Nima’s request to move a vote, I am giving everyone a last opportunity for comments until EOD Wednesday 07/18. 

This is also the day of CAB call in case you want to chat with him, myself, or others who attend the call in person.

After 07/18, assuming no comments, we will move for a vote.

Best,

Max


On Wed, Jun 20, 2018 at 9:57 AM Nima <nkavian@...> wrote:
Hello all,
 
Following the presentation of the BlockHeads broker at today's CAB call, here comes the proposal for its inclusion as a new CF Extensions project.
 
 
BlockHead is a service broker that integrates with Cloud Foundry / Kubernetes and enables management of blockchain nodes and deployment of smart contracts. You can check our blog post below for more information
 
 
Project Name: BlockHeads Service Broker

Proposed Project Lead: Nima Kaviani (IBM)

Proposed Contributors: Swetha Repakula (IBM), Jonathan Berkhahn (IBM), Morgan Bauer (IBM), Nima Kaviani (IBM)

 
Feel free to contact me in case of any questions / thoughts / feedback.
 
bests,
Nima

--
dr.max Sent from my iPhone http://maximilien.org

Re: [cf-bosh] Incubation proposal: CF Containerization

Dmitriy Kalinin <dkalinin@...>
 

Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




Feature Narrative / Proposal: Let's fix* CPU Sharing and Metrics in CF!

Julz Friedman
 

Hi cf-dev-

Here is a feature narrative. The feature narrative is called "Let's Fix CPU Sharing and Metrics in CF" (but actually it's just a proposal to make them quite a lot better). More information about the feature narrative is contained in the feature narrative. Please enjoy the feature narrative.

Comments, feedback, suggestions, and questions very welcome and appreciated!


Thanks,
Julz

Deprecate route-sync from CFCR to CFAR

Oleksandr Slynko
 

Hi, cf-dev

Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment.
We haven't added any changes to this feature for one year and plan to remove it in next release. It will greatly reduce the burden on the team.

If someone uses it, please contact us via email or Slack (#cfcr).

Thanks,
Oleksandr

Re: Deprecate route-sync from CFCR to CFAR

arghya sadhu
 

Hi Oleksandr,

What alternative do we have if we want to use kubectl with tls

Thanks,
Arghya

On Fri, Jul 13, 2018, 3:01 PM <oslynko@...> wrote:
Hi, cf-dev

Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment.
We haven't added any changes to this feature for one year and plan to remove it in next release. It will greatly reduce the burden on the team.

If someone uses it, please contact us via email or Slack (#cfcr).

Thanks,
Oleksandr

Re: Deprecate route-sync from CFCR to CFAR

Gabriel Rosenhouse
 

Also: I suspect that the CFCR route-sync feature has a dangerous interaction with CFAR Cloud Controller, if both CFCR and CFAR are sharing a TCP Routing API.  CFAR Cloud Controller creates and uses a TCP Router Group for itself, and expects to completely own that router group.  My reading of the CFCR code is that route-sync will happily discover and use that Router Group as-is.  The CFAR Routing API has no mechanism to prevent this collision, or to prevent the two clients from reserving the same TCP port for different backends.  I think that the result will be that ingress to that TCP Router Port will get load balanced to both the CFAR App and the CFCR Service.  This is likely not what the user intends.

On Fri, Jul 13, 2018 at 4:14 AM, arghya sadhu <arghya88@...> wrote:
Hi Oleksandr,

What alternative do we have if we want to use kubectl with tls

Thanks,
Arghya

On Fri, Jul 13, 2018, 3:01 PM <oslynko@...> wrote:
Hi, cf-dev

Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment.
We haven't added any changes to this feature for one year and plan to remove it in next release. It will greatly reduce the burden on the team.

If someone uses it, please contact us via email or Slack (#cfcr).

Thanks,
Oleksandr


Re: Deprecate route-sync from CFCR to CFAR

Shannon Coen
 

That issue could be addressed by having CFCR use a different router group, which is part of the solution we have proposed here: https://docs.google.com/document/d/1RXu-o44zxwrU5gKqsghT86hXKwgPrPpSk6-TWSTlrBs/edit

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


On Fri, Jul 13, 2018 at 11:47 AM Gabriel Rosenhouse <grosenhouse@...> wrote:
Also: I suspect that the CFCR route-sync feature has a dangerous interaction with CFAR Cloud Controller, if both CFCR and CFAR are sharing a TCP Routing API.  CFAR Cloud Controller creates and uses a TCP Router Group for itself, and expects to completely own that router group.  My reading of the CFCR code is that route-sync will happily discover and use that Router Group as-is.  The CFAR Routing API has no mechanism to prevent this collision, or to prevent the two clients from reserving the same TCP port for different backends.  I think that the result will be that ingress to that TCP Router Port will get load balanced to both the CFAR App and the CFCR Service.  This is likely not what the user intends.

On Fri, Jul 13, 2018 at 4:14 AM, arghya sadhu <arghya88@...> wrote:
Hi Oleksandr,

What alternative do we have if we want to use kubectl with tls

Thanks,
Arghya

On Fri, Jul 13, 2018, 3:01 PM <oslynko@...> wrote:
Hi, cf-dev

Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment.
We haven't added any changes to this feature for one year and plan to remove it in next release. It will greatly reduce the burden on the team.

If someone uses it, please contact us via email or Slack (#cfcr).

Thanks,
Oleksandr


Re: cf-deployment 3.0

Josh Collins
 

Hi Marco,

I'm happy to provide more context on the container networking 2.0 reference.
The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0. 
RelInt deferred the container networking team's PR for a few weeks due to competing priorities including multiple CVE's fixes.
During the deferral time, a few other PRs were submitted which included breaking changes.
These additional changes took much more time to integrate and validate than anticipated and in the end, the container networking team's 2.0 release was published in cf-d about 5 weeks after it was ready to go.
The introduction of a regular cadence aims to mitigate this type of delay in the future. Had we had one at the time, the networking team would have timed it's PR to align and we would have been poised to accept and publish it quickly.
We believe this will help teams confidently plan for, communicate about, and negotiate integrating their releases into cf-deployment.
And hopefully enable the RelInt team to integrate and ship major releases more seamlessly.

This is an evolving process so we'll see how things roll in the coming months and make adjustments where it makes sense to do so. 
I appreciate and welcome any and all feedback along the way.

Thanks very much,

Josh