Date   

Re: What do admins expect to see in "cf marketplace?"

Norm Abramovitz
 

If you take the conservative approach it would be a breaking change. 

We have a tool that validates the CF environment after deployment. In our use case, the service exists with plans x, y, z but plan z is disabled.   As long as we can get enabled and disabled plans in some way. that would be good enough.




On Mon, Mar 25, 2019 at 3:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Norman Abramovitz
Technical Director
Stark & Wayne, LLC




Re: What do admins expect to see in "cf marketplace?"

Oleksii Fedorov
 

Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476


Re: Request for Feedback: "Scaling Cloud Controller" guidance document

Dieu Cao <dcao@...>
 

Woohoo! I can't begin to convey how excited I am about this as a former CAPI PM.

-Dieu

On Fri, Mar 22, 2019 at 10:44 AM Tim Downey <tdowney@...> wrote:
Hello,

The CAPI team has been working on a document to give operators some guidance with regards to knowing when and how to scale their Cloud Controllers (and related jobs in capi-release) based on our team's experience. 

A draft version of the "Scaling Cloud Controller" document can be viewed here:

Our intent is to work with the Docs team and get this added as part of the Running Cloud Foundry operator docs, but first we'd welcome and appreciate any feedback from the CF operator community. Feel free to respond to this post or submit an issue/PR with suggestions for the draft document.

Thanks!
CF CAPI Team


Request for Feedback: "Scaling Cloud Controller" guidance document

Tim Downey
 

Hello,

The CAPI team has been working on a document to give operators some guidance with regards to knowing when and how to scale their Cloud Controllers (and related jobs in capi-release) based on our team's experience. 

A draft version of the "Scaling Cloud Controller" document can be viewed here:

Our intent is to work with the Docs team and get this added as part of the Running Cloud Foundry operator docs, but first we'd welcome and appreciate any feedback from the CF operator community. Feel free to respond to this post or submit an issue/PR with suggestions for the draft document.

Thanks!
CF CAPI Team


istio-release 1.2.0

Wa Gao
 

Hello, 

We have cut istio-release 1.2.0. With this release in addition to weighted routing, we now support envoys sidecars configured by Istio Pilot for app to app communication. We also have support for client-side load balancing, retries and timeouts for app to app communication. We are working on the docs to run the book-info app on CF and will keep you posted. 

The release highlights include the following features. 

  • app developers can rely on the platform to provide timeouts for app to app communication, timeout default is currently set to 15s and not modifiable details
  • istio-release versioning now uses semver versions and not the whole number versions details
  • performance improvement to allow operators to run many apps by temporarily disabling stats logging (reduces envoy RAM consumption) details
  • we have now added a Contributing section to istio-release details
  • fix issue with retries such that application developers can rely on the platform to provide retries for app to app communication details
  • performance and security: only internal routes are published to sidecar envoys and external routes to the envoy gateway details
  • Copilot uses new MCP details
  • Changed pilot to use role~ip~id~dns.domain for the Envoy service node field details
  • operator can set spec property for pilot_log_level details
  • Bump istio to 1.1 in istio-release details
  • developer can see traffic equally distributed when they map an internal route to three apps on the same port details
  • operators can specify the DNS address of the MCP Client Pilot connects to details

 CF-Networking 


Re: [cf-bosh] Removing Support for v1 Style Manifests

Corey Innis <cinnis@...>
 

+100 ... big proponent of making v1 manifests obsolete.

Cheers,
Corey

On Mon, Mar 18, 2019 at 6:29 PM Ronak Banka <ronakbanka.cse@...> wrote:
Great job BOSH team 👏🏻

On Tue, 19 Mar 2019 at 12:36 AM, Morgan Fine <mfine@...> wrote:
Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH


Re: [cf-bosh] Removing Support for v1 Style Manifests

Ronak Banka
 

Great job BOSH team 👏🏻

On Tue, 19 Mar 2019 at 12:36 AM, Morgan Fine <mfine@...> wrote:
Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH


FINAL REMINDER: CAB call for March is next week Wednesday 20th @ 8a Pacific

Michael Maximilien
 

Hi, all,
 
Quick final reminder that the CAB call for March is this coming Wednesday 20th @ 8a Pacific.
 
We will have regular highlights, QAs, as well as two exciting talks:
 
1. YTT: The YAML Templating Tool that simplifies complex configuration management [1] by Dmitriy Kalinin (Pivotal) and Nima Kaviani (IBM)
2. CF Weighted Routing with Istio and Future Road Map [2] by Shubha Anjur Tupil and team from Pivotal
 
All other info in agenda [0]. Zoom soon. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: cf-dev@...
Cc:
Subject: CAB call for March is next week Wednesday 20th @ 8a Pacific
Date: Thu, Mar 14, 2019 8:39 AM
 

Hi, all,

 

Reminder that the CAB call for February is Wednesday March 20th @ 8a PST (next week).

 

We will have our regular PMCs highlights and hopefully two talks / demos:

 

1. “YTT: The YAML Templating Tool that simplifies complex configuration management” [1] by Dmitriy Kalinin (Pivotal) and Nima Kaviani (IBM)

 

2. TBD - please email or slack me if you have something to demo

 

All other info in agenda here [0].

 

Zoom soon. Best,

 

dr.max

ibm ☁ 

silicon valley, ca

 

[0] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI

[1] https://developer.ibm.com/blogs/yaml-templating-tool-to-simplify-complex-configuration-management/

 
 


Removing Support for v1 Style Manifests

Morgan Fine
 

Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH


What do admins expect to see in "cf marketplace?"

Oleksii Fedorov
 

Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team


Re: [Proposal] Deprecation of the firehose endpoint

Johannes Tuchscherer
 

Hello everybody,

after a lot of deliberation and many good conversations, we came to the conclusion that we will go ahead and remove the firehose endpoint in six months. So, in the first release published after September 14th, there will be no more firehose endpoint. Until then, we will continue to help the community to migrate commonly used firehose integrations over to using the new endpoints located on the Reverse Log Proxy.

Just to reiterate the benefit of this effort, this is an important step to lower overhead and complexity for cloud foundry operator. Also, it will bring more adoption to the new endpoints which should be easier to consume and put less stress on the logging system.

Thanks again for everybody who reached out to us either on this list or on Slack or a separate email thread. Your input was very valuable.

Please let me know if you have any questions or concerns,
Johannes 

On Tue, Mar 5, 2019 at 11:52 AM Johannes Tuchscherer <jtuchscherer@...> wrote:
Hi Neil,

Thanks for the feedback. We actually created PRs for both, firehose-exporter[0] and to firehose-to-syslog[1]. We will continue working with the maintainers to get these pulled in. 

Best,
Johannes


On Tue, Mar 5, 2019 at 11:26 AM Neil MacDougall <neil.macdougall@...> wrote:
Johannes,

A 6 month deprecation window works for Stratos - that should be fine for us to update.

If you can work with the firehose-exporter project to get that updated and off the firehose within the next 2 or 3 months, that would be super helpful and give us time to integrate and test, assuming its a drop-in replacement for the current firehose based version.

Many thanks,

Neil

On 25 Feb 2019, at 23:51, Johannes Tuchscherer <jtuchscherer@...> wrote:

Hi everybody,

thanks for the continuous stream of feedback. We are definitely going to support the firehose-exporter and firehose-to-syslog projects off the firehose to the RLP. The stories in our backlog are coming up soon. Stanislav, do you think that looking at what we did with the firehose-to-syslog project would help you to migrate the kafka-firehose-nozzle?

Also, based on the feedback I have received so far I am open to increasing the deprecation window to 6 months. Would that be acceptable?

Thanks,
Johannes

On Sun, Feb 24, 2019 at 4:22 PM Stanislav German-Evtushenko <s.germanevtushenko@...> wrote:
Hi Johannes,

We are heavy users of loggregator and we have the same concerns as others in the thread.

We use loggregator for:
- storing all application logs for 6 month (regulations requirement) using kafka-firehose-nozzle
- getting all platform metrics for monitoring purposes using kafka-firehose-nozzle
- getting all applications metrics to provide monitoring dashboard using kafka-firehose-nozzle and cf-metrics-refinery (see https://cloudfoundry.slack.com/messages/C6WFZ5K0F/p1531268612000101)

Another concern is autoscaler (https://github.com/cloudfoundry-incubator/app-autoscaler-release). It is relying on loggregator and I haven't seen any updates on moving out of it yet.

Best regards,
Stanislav




CAB call for March is next week Wednesday 20th @ 8a Pacific

Michael Maximilien
 

Hi, all,


Reminder that the CAB call for February is Wednesday March 20th @ 8a PST (next week).

 

We will have our regular PMCs highlights and hopefully two talks / demos:

 

1. “YTT: The YAML Templating Tool that simplifies complex configuration management” [1] by Dmitriy Kalinin (Pivotal) and Nima Kaviani (IBM)


2. TBD - please email or slack me if you have something to demo

 

All other info in agenda here [0].

 

Zoom soon. Best,

 

dr.max

ibm ☁ 

silicon valley, ca

 

[0] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI

[1] https://developer.ibm.com/blogs/yaml-templating-tool-to-simplify-complex-configuration-management/



Announcement: Regular BOSH PMC meetings

Marco Voelz
 

[cross-posting lists for visibility]

 

Dear Friends of BOSH,

 

We are about to have our first BOSH PMC meeting!

 

When?

Thursday, March 21st, 8AM Pacific Time

Afterwards: Every third Thursday of the month in the same timeslot.

 

Where?

http://zoom.bosh.io

 

What is this all about?

Similarly to the existing PMC meetings, the BOSH PMC meeting is for announcements, updates, and outlook for all active projects within the BOSH PMC [1]. After a meeting, you can find the meeting minutes in pmc-notes/bosh on github [2]. If you want to see topics discussed at the meeting, we appreciate a heads-up a few days before the meeting, either via mail on cf-bosh@... or by making a pull request to the agenda document.

 

According to the Cloud Foundry Foundation's Governance documents, all companies with at least one full-time contributor on an active project get a vote to be issued by a representative. Others can join, but not vote on decisions, such as incubating new projects or promoting a project from incubation to active.

For more information on the organization within a Cloud Foundry PMC, please refer to the official Cloud Foundry Foundation Governance Documents [3].

 

Warm regards

Marco

 

[1] https://docs.google.com/a/pivotal.io/spreadsheets/d/1hg0EA3aB9wiCq8SgCU90ft4qrHvczsUjK0W_31APWxM

[2] https://github.com/cloudfoundry/pmc-notes/tree/master/Bosh

[3] https://www.cloudfoundry.org/wp-content/uploads/2015/09/CFF_Development_Governance.pdf


Unconference: Reminder, and CFT (Call For Trivia)

Daniel Jones
 

Hi folks,

A reminder that the CF Summit Unconference is happening on Monday April 1st (no joke!) at 6PM local time. There'll be a few talks, a lot of open spaces, free beer and food.

The Cloud Foundry Pub Quiz will also be making its North American debut, after a couple of successful instances at CF Summit Europe.

This does however leave me with the herculean task of having to dig up even more Cloud Foundry trivia to make questions out of. Last time I scraped the barrel so hard that I ended up with splinters (slivers, for my American chums). You'd be amazed at the things I now know about clouds and foundries. Did you know that a peen hammer is a thing?

I'd be really grateful if any of you can help me with content for the quiz. If you know any obscure history or trivia about Cloud Foundry, I'd be very thankful to read it. If you've been caught out by a 'gotcha', or found a common misconception about how CF and ecosystem tools work, I'd love to know.

In return I can offer the thanks of a moustachioed man, free hugs, a beverage of your choice, and/or the chance of having a question you know the answer to in the quiz and thus an unfair competitive advantage.

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


routing-release 0.187.0

Aidan Obley <aobley@...>
 

We have cut routing-release 0.187.0.

Release Highlights

  • golang version bumped to 1.11.5
  • cf-tcp-router supports truly seamless reloads details
  • Fix url parsing for forwarded url after route-service pass details
  • ms_since_last_registry_update metric will emit -1 when no routes have been created details
  • cf-tcp-router, route-registrar, and routing-api log human-readable RFC3339 timestamps details
  • Operator can configure a manifest property routing_api.sqldb.skip_hostname_validation to skip hostname verification when routing-api communicates with a mysql server that does not provide a valid hostname in its certificate details

Manifest Property Changes

0.186.0 0.187.0 Default Value
did not exist routing_api.sqldb.skip_hostname_validation false

Regards,
The Networking Program


Notice: Default Node.js version will change from 6.x to 10.x after 2019-04-11

Elliott Shanks
 

The default version of Node.js in the Node.js buildpack will change from the latest 6.x version to the latest 10.x version in the first release of the Node.js buildpack after April 11, 2019. Due to the end of upstream support for Node.js 6.x in April, all buildpack users should ensure that their apps run on a minimum buildpack supported version of Node.js 10.x or later.

For more information about Node.js 10.x or LTS timelines for 10.x, refer to: https://github.com/nodejs/Release

For more information about supported Node.js versions in the node.js buildpack, refer to: https://buildpacks.cloudfoundry.org/#/buildpacks

Thanks,

Elliott Shanks, Buildpacks PM


NOTICE: [nodejs-buildpack] End of Node.js 6.x support in buildpack after 2019-04-11

Elliott Shanks
 

The first release of the Node.js buildpack after April 11, 2019 will no longer include any versions of Node.js 6.x. These Node.js versions are no longer supported upstream [1]. Please migrate your Node.js apps to supported versions of Node.js before that time.


Note: The default version of Node.js in the buildpack will be changed from Node.js 6.x to Node.js 10.x at this time.


[1] https://github.com/nodejs/Release


Thanks,

Elliott Shanks, CF Buildpacks PM


Seeking Nominations: Community Awards

Swarna Podila
 

Dear Cloud Foundry Community,
It is that time of Summit again where we seek your help to nominate yourself or your peers for the Community Awards that will be presented at Cloud Foundry Summit in Philadelphia next month.

This year, the nomination categories are:
  • The Quiet Achiever
  • The Advocate
  • The Coolest User Story
More details on each of these categories can be found in this blog [1] and the nomination form can be found here [2].

Nominations close at 11:59 PM on March 14, 2019.  If you have any questions, please do not hesitate to contact me via email or slack.

Thank you,
Swarna.


-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.



Re: Announcement: CC API v2 Deprecation Plan

Guillaume Berche
 

+1, this was suggested few years ago, see https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/46 for related exchanges.

I however believe that most of the complexity and associated effort in using the CC API resides in implementing workflows of API calls implementing user facing use-cases (i.e. CF CLI commands). Therefore clients may need to complement low level API facilities with high-level facilities, such as cf-java-client [1]'s cloudfoundry-operations which complements it's low-level cloudfoundry-client.


Guillaume.


On Tue, Mar 5, 2019 at 7:59 PM Mike Lloyd <mike@...> wrote:
Recently I had a use case to use CAPI for exporting some app information, and I struggled a bit here and there to both find a client as well as build one myself for v2. I think what could be really interesting, and thinking out loud, would be an OpenAPI 3.0 definition for v3. I think that would really help client maintainers (maybe now but definitely in the future) make the migration a bit easier for multi-language projects. I briefly looked to see if an API spec existed, but I didn't see anything.

Looking forward, having an API spec for CAPI would be very helpful even past the migration, then clients can be very easily constructed in any language.

Respectfully,

Mike Lloyd
t: @mxplusc

From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via Lists.Cloudfoundry.Org <bercheg=gmail.com@...>
Sent: Tuesday, March 5, 2019 10:13 AM
To: cf-dev
Subject: Re: [cf-dev] Announcement: CC API v2 Deprecation Plan
 
Hi Greg,

I'd like to renew related feedback provided last october on the subject at https://lists.cloudfoundry.org/g/cf-dev/topic/26659245#8303

There are many tooling out there that currently rely on the CC API V2 (such as UIs, service brokers, provisionning tools such as terraform-provider-cf or SAP MTA...). These tooling usually leverage CC API clients [2]. Ways to reduce impacts for such tooling would be to work with client maintainers (both official, experimental and unsupported) to sync the CC API V2 deprecation with availability of CC API V3 support in clients from most widely used programming languages.

In particular, regarding the go-lang client, we had a related exchange with the CLI team at cf summit, and a related issue https://github.com/cloudfoundry/cli/issues/1481 tracks this feedback, which seems to have received positive community interest. It would be useful to hear feedback from the CLI or VAT teams on this suggestion.

Thanks,

Guillaume.

On Wed, Feb 13, 2019 at 11:34 PM Greg Cobb <gcobb@...> wrote:
Greetings cf-dev!

The V3 Acceleration Team has been hard at work expanding the CC v3 API to cover resources that were previously only available on the v2 API. We are now ready to announce our CC V2 API Deprecation Plan.

As per the plan, we will announce the start of the v2 deprecation window at a future date. We recognize that transitioning from the v2 API will be an involved process for some clients, so we recommend starting now for resources that are available on the v3 API. 

Please feel free to comment on the document, respond to this email, or message us in the #v3-acceleration-team channel on the Cloud Foundry Slack if you have any questions.

In the meantime, we are still soliciting feedback on the remaining v3 API proposals and the v3 API in general. We would like to give a shout out to the Stratos team for their in-depth notes about their experiences using v3.

Thanks!
V3 Acceleration Team


Re: Announcement: CC API v2 Deprecation Plan

Mike Lloyd <mike@...>
 

Recently I had a use case to use CAPI for exporting some app information, and I struggled a bit here and there to both find a client as well as build one myself for v2. I think what could be really interesting, and thinking out loud, would be an OpenAPI 3.0 definition for v3. I think that would really help client maintainers (maybe now but definitely in the future) make the migration a bit easier for multi-language projects. I briefly looked to see if an API spec existed, but I didn't see anything.

Looking forward, having an API spec for CAPI would be very helpful even past the migration, then clients can be very easily constructed in any language.

Respectfully,

Mike Lloyd
t: @mxplusc


From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via Lists.Cloudfoundry.Org <bercheg=gmail.com@...>
Sent: Tuesday, March 5, 2019 10:13 AM
To: cf-dev
Subject: Re: [cf-dev] Announcement: CC API v2 Deprecation Plan
 
Hi Greg,

I'd like to renew related feedback provided last october on the subject at https://lists.cloudfoundry.org/g/cf-dev/topic/26659245#8303

There are many tooling out there that currently rely on the CC API V2 (such as UIs, service brokers, provisionning tools such as terraform-provider-cf or SAP MTA...). These tooling usually leverage CC API clients [2]. Ways to reduce impacts for such tooling would be to work with client maintainers (both official, experimental and unsupported) to sync the CC API V2 deprecation with availability of CC API V3 support in clients from most widely used programming languages.

In particular, regarding the go-lang client, we had a related exchange with the CLI team at cf summit, and a related issue https://github.com/cloudfoundry/cli/issues/1481 tracks this feedback, which seems to have received positive community interest. It would be useful to hear feedback from the CLI or VAT teams on this suggestion.

Thanks,

Guillaume.

On Wed, Feb 13, 2019 at 11:34 PM Greg Cobb <gcobb@...> wrote:
Greetings cf-dev!

The V3 Acceleration Team has been hard at work expanding the CC v3 API to cover resources that were previously only available on the v2 API. We are now ready to announce our CC V2 API Deprecation Plan.

As per the plan, we will announce the start of the v2 deprecation window at a future date. We recognize that transitioning from the v2 API will be an involved process for some clients, so we recommend starting now for resources that are available on the v3 API. 

Please feel free to comment on the document, respond to this email, or message us in the #v3-acceleration-team channel on the Cloud Foundry Slack if you have any questions.

In the meantime, we are still soliciting feedback on the remaining v3 API proposals and the v3 API in general. We would like to give a shout out to the Stratos team for their in-depth notes about their experiences using v3.

Thanks!
V3 Acceleration Team