Date   

Re: Windows versions supported by UAA #uaa

Daniel Mikusa
 

The UAA server is written in Java so it's quite portable. Is there a specific concern that you have? 

Dan

On Mon, Oct 7, 2019 at 6:13 AM Enrique Cano <enrique.canocarballar@...> wrote:
Hi community

Is UAA supported on Microsoft Windows, and if so, what versions?

Many thanks in advance

Enrique


Windows versions supported by UAA #uaa

Enrique Cano
 

Hi community

Is UAA supported on Microsoft Windows, and if so, what versions?

Many thanks in advance

Enrique


Re: Update to Credhub encryption to use Key Encryption Key (KEK) protocol scheme

Mike Lloyd <mike@...>
 

Credhub team,

 

What does the migration plan for this feature look like? Is the migration from key types a non-breaking change, or will it require all new deployments and keys?

 

Thanks,

 

Mike.

 

From: cf-dev@... <cf-dev@...> On Behalf Of ebastian via Lists.Cloudfoundry.Org
Sent: Thursday, October 3, 2019 2:59 PM
To: cf-dev@...
Subject: [cf-dev] Update to Credhub encryption to use Key Encryption Key (KEK) protocol scheme

 

Hi everyone,

 

The Credhub team is proposing a change to the current encryption scheme. 

Changing the current encryption scheme from Data Encryption Key (DEK) to Key Encryption Key (KEK) would allow for:

  •  
  • increased Credhub security posture 
  •  
  •  
  • simplification of Credhub encryption key rotation
  •  
  •  
  • integration with third-party KMS vendors with a data size limit
  •  

 

Details of the change can be found here.

 

Please feel free to share your thoughts and concerns and reach out with any questions!

 

Thanks,

The Credhub Team

 


Proposal to move Loggregator to new shared-nothing architecture

Jesse Weaver
 

Hello, all,

We propose a new shared-nothing architecture to improve the scalability of syslog drains and to enable whole-platform syslog egress. This allows Loggregator to scale to more drains and logs/metrics per second, moves us to a community-standard log format, and improves the resource efficiency of log and metric egress.

Please see our proposal at https://docs.google.com/document/d/1_Ve4wAkeCC0fIJ1TiAWSfxzNp5zB_Ndoq5UmfUNJtgs/edit?usp=sharing . If you have any feedback, please comment on that document.

Thanks,
The Loggregator Team


Update to Credhub encryption to use Key Encryption Key (KEK) protocol scheme

ebastian@...
 

Hi everyone,


The Credhub team is proposing a change to the current encryption scheme. 

Changing the current encryption scheme from Data Encryption Key (DEK) to Key Encryption Key (KEK) would allow for:

  • increased Credhub security posture 

  • simplification of Credhub encryption key rotation

  • integration with third-party KMS vendors with a data size limit


Details of the change can be found here.


Please feel free to share your thoughts and concerns and reach out with any questions!


Thanks,

The Credhub Team

 


Re: New CLA tool for Cloud Foundry

Chris Clark
 

UPDATE: There will be a slight delay on the full migration - we're working out a couple kinks with the migration process, but should have things sorted out in the next week. We will, of course, keep you all updated when we're going to make the switch. In the meantime... long live Dreddbot!


On Fri, Sep 20, 2019 at 12:24 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


cf-networking-release & silk-release 2.25.0!

Keshav Sharma <ksharma@...>
 


Re: New CLA tool for Cloud Foundry

Eric Malm <emalm@...>
 

That's great news, Chris! Congratulations, and thanks for letting all of us know!

Best,
Eric


On Fri, Sep 20, 2019 at 12:25 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: New CLA tool for Cloud Foundry

Abby Chau
 

Awesome news. Thank you!


On Fri, Sep 20, 2019 at 12:25 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: New CLA tool for Cloud Foundry

Evan Farrar <evanfarrar@...>
 

Woohoo! Good bye, Dredd!

On Fri, Sep 20, 2019 at 12:25 AM Chris Clark <cclark@...> wrote:
Hello all,

I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.

Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 

What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  

CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. However - we will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  

Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  

I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  

Please reach out with any concerns or questions you might have about the new tool, or the migration process!

Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


New CLA tool for Cloud Foundry

Chris Clark
 
Edited

Hello all,
 
I am very pleased to announce that Cloud Foundry will be adopting a streamlined, more user-friendly system for CLAs. No more PDFs! We'll be adopting the new EasyCLA tool that the Linux Foundation has developed, and deprecating our long-serving, trusty dreddbot.
 
Migration date: Wednesday, October 2nd. We'll be migrating some repositories next week to test things out a bit, but this tool has already been successfully adopted by multiple large open source projects, so this is just an extra precaution. 
 
What does this mean for you: Probably nothing. If you're a contributor who is covered by an existing CLA, you will not have to resign, and you will likely never notice the difference. If you're a maintainer of a project, you should no longer see noticeable delays in pull requests being approved for new contributors. If you're a new contributor, you'll find a newer, streamlined process for signing a CLA and submitting your first pull request.  
 
CCLAs: We're migrating over all of the whitelisted orgs and employees covered by CCLAs, so this migration won't cause anyone to have to re-sign. If you are covered by a CCLA - the tool will ask (once) what company you are covered by.  At this point, click "CFF Migration", and it should confirm that you are in one of the whitelisted groups that we've moved over. 

We will be doing a bit of housecleaning with our CCLAs in the next few weeks to make sure everything is current, so I may be reaching out to various companies regarding this. The EasyCLA tool allows for CCLA signees to manage their designated employees by whitelisting a Github org (as most have already been doing with Cloud Foundry), or, if you prefer, by having a list of designated employees that you can access and change manually.  Once this process is complete, I'll let you all know.  After that
 
Want to learn more about the EasyCLA tool? Here's a short presentation.  Here's the source code, and associated docs.  
 
I would like to thank the LF for building us this seemingly excellent tool, and the dreddbot and its maintainers at the cf-toolsmiths team for years of faithful service.  
 
Please reach out with any concerns or questions you might have about the new tool, or the migration process!
 
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


CAB call for September scheduled for tomorrow is CANCELED

Michael Maximilien
 

fyi...
 
As is the tradition we already had it during CF Summit in The Hague, The Netherlands last week.
 
 
Zoom with you next month on 10/16/2019. If you have something you want to present please contact me ASAP (here or slack).
 
Best,

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


Re: [cf-bosh] BOSH OpenStack CPI: planned end of maintenance by end of 2019

Morgan Fine
 

Hi All,

Pivotal plans to take over support of the Openstack CPI at the end of 2019 when our SAP friends move away from it. I believe closer to the end of the year we would like to pair to make sure the transition is successful.

Additionally, if there are other companies teams out there that are interested in helping to support it, we'd be more than happy to collaborate on it.

Best,
Morgan

On Fri, Aug 23, 2019 at 2:25 AM Marco Voelz <marco.voelz@...> wrote:

Hi everyone, hi Daniel,

 

Thanks for the interest in the BOSH OpenStack CPI, I'm happy to give you some perspective on what we had been doing in the past and what the current status is.

 

* We've automated pretty much everything in terms of regular maintenance. This includes updates of the dependencies like rubygems [1], and consumption of the ruby-release in bosh packages [2]. We have automated the update of ruby-release itself, such that ruby, rubygems, etc are automatically updated.

* All PRs are tested against the supported set of OpenStack APIs by using the cf-openstack-validator to run a base set of API interactions with OpenStack [3]. We're using OpenLab [4] to provide virtualized OpenStack environments for us. Adding a new one is only a few lines of yml [5]

* New versions of bosh, a stemcell, or the cpi are automatically tested in a pipeline using BATs and e2e tests. While this pipeline currently runs against an SAP provided OpenStack, it is easy to set this up against a different OpenStack

* There are very few issues open (currently 7 issues and 3 of those are feature requests)

* There isn't really left-over work for now: Our backlog contains 37 open stories tagged with 'cpi' [6]. Quite a few are crossed out (we decided not to do them, but keep them for future reference to document decisions), or even about different CPIs like AWS and GCP.

* The biggest pain point in the past have been fog-openstack and excon. Updates of these two libraries are always a gamble, they don't seem to be well-tested and introduced quite some annoyances over the last few years. One example is how the individual OpenStack projects adopted microversions in their APIs and how fog-openstack selects which version to use. More recently, this didn't have much impact – it mostly matters when you're trying to use functionality that isn't present below a certain microversion or has been removed starting from a version.

* We have been trying to support the community with their OpenStack issues in #openstack and #bosh on CF Slack. Interrupts don't come on a daily basis, but there is a need for looking at community questions.

* We tried to improve the ecosystem with projects like cf-openstack-validator [9], better OpenStack support in bbl [10], and .tf templates for OpenStack [11]. Also maintaining the OpenStack part of the docs on bosh.io

 

Overall, I guess the amount of work you would need to put into the OpenStack CPI depends on what you're trying to do with it. My guess is that a pair of engineers is sufficient to address some of the more recent feature requests and keep the system alive and healthy.

 

Let me know if you need more information to get a feeling for what it means to take over this work. I'm happy to talk about individual aspects some more, if it helps.

 

Warm regards

Marco

 

[1] https://github.com/cloudfoundry/bosh-openstack-cpi-release/pull/212

[2] https://github.com/cloudfoundry/bosh-openstack-cpi-release/pull/207

[3] https://github.com/cloudfoundry/bosh-openstack-cpi-release/pull/212#issuecomment-518850649

[4] https://openlabtesting.org/

[5] https://github.com/cloudfoundry/bosh-openstack-cpi-release/commit/3c613ad99c574bcf741a796de9c1c9557480c5c5

[6] https://www.pivotaltracker.com/n/projects/1456570/search?q=label%3A%22cpi%22

[7] https://github.com/cloudfoundry/bosh-openstack-cpi-release/issues/186

[8] https://github.com/cloudfoundry/bosh-openstack-cpi-release/issues/211

[9] https://github.com/cloudfoundry-incubator/cf-openstack-validator

[10] https://github.com/cloudfoundry/bosh-bootloader/pull/431

[11] https://github.com/cloudfoundry-incubator/bosh-openstack-environment-templates

 

 

 

 

From: <cf-bosh@...> on behalf of Daniel Jones <daniel.jones@...>
Reply to: "cf-bosh@..." <cf-bosh@...>
Date: Thursday, 22. August 2019 at 15:52
To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh@...>
Cc: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-bosh] BOSH OpenStack CPI: planned end of maintenance by end of 2019

 

Hi all,

 

I should imagine there must be enough very large consumers of the OpenStack CPI to make it commercially viable for a small team to be funded that could maintain it, were all said consumers to pull together and contribute what I should imagine would be a small sliver of their total CF expenditure.

 

If any OpenStack CPI users want to talk to EngineerBetter about funded development, we'd be happy to have that conversation as we're doing some similar EOL work for other CF projects. 

 

Similarly, if our chums at Anynines, Altoros, S&W, GrapeUp, EVoila, GStack, Armakuni, Novatec or others want to work together on this, we'd be open to that. I can also imagine that some chunk of Pivotal's revenue depends on this CPI, so perhaps some of our teal friends might be interested too? It could be like one of those Marvel films (that I don't watch) where we all team up to vanquish the evil villain of abandoned software. 

 

Marco - how many pairs were working on these streams of work, and do you have a feel for the balance of vital maintenance, tech debt, new features, and quality-of-life improvements in the backlog?


Regards,

Daniel 'Deejay' Jones - CTO

+44 (0)79 8000 9153

EngineerBetter Ltd - More than cloud platform specialists

 

 

On Wed, 21 Aug 2019 at 09:38, Marco Voelz <marco.voelz@...> wrote:

Dear Friends of OpenStack,

 

Since 2015, the BOSH OpenStack CPI [1] is maintained by the BOSH team Europe at SAP. Historically, this made sense, because SAP was a large user of OpenStack, but in the meantime our focus as a company has shifted.

 

Consequently, we would like to announce that our team at SAP will stop maintaining the BOSH OpenStack CPI and a few related projects like CF OpenStack validator [2] and bosh-openstack-environment-templates [3] *by the end of 2019*. Already starting right now, we are stopping feature work on the BOSH OpenStack CPI. From 2020 on, we will not release any new versions of the CPI, be it for fixing CVEs, ensuring support of new OpenStack versions, or other reasons.

 

If there is anybody in the community with interest to continue maintenance and development of the BOSH OpenStack CPI and potentially the related projects as well, we're happy to transfer the ownership of projects and CI pipelines. If no maintainer is found for a project,  the regular course of action would be to move it to the cloudfoundry-attic organization.

 

If this is a topic you'd like to talk about, please reach out to us by replying to this mail or contacting me directly.

 

Warm regards

Marco

 

[1] https://github.com/cloudfoundry/bosh-openstack-cpi-release

[2] https://github.com/cloudfoundry-incubator/cf-openstack-validator

[3] https://github.com/cloudfoundry-incubator/bosh-openstack-environment-templates


REQUEST for REVIEW - Scope for CF-Deployment v12.0

Saikiran Yerram
 

Happy Friday everyone,

I want to share and gather feedback on the proposed scope of the next major release of cf-deployment v12.0 version.

This Google doc describes the high-level changes.


Anyone with the link above can review and comment. Please take some time to peruse it and comment directly within the doc when you have a moment.

You can reach us at CloudFoundry slack channels #cf-deployment, #release-integration

Regards,

--
Saikiran Yerram


Re: [cf-ambassadors] Cloud Foundry Community Awards: Nominations close Aug 31

Swarna Podila
 

Thank you everyone that has sent in nominations so far.  Please note that the deadline is Aug 31, 11:59PM US Pacific.  Please send your nominations before that. 

Thank you,
Swarna. 
 

On Tue, Aug 27, 2019 at 13:46 Swarna Podila via Lists.Cloudfoundry.Org <spodila=cloudfoundry.org@...> wrote:
Hi Everyone,
It is that time of Cloud Foundry Summits where I nudge you all to nominate yourself or your peers, your organization or a peer's organization for the Community Awards.


TL;DR: there are four categories:
  • Committed Contributor, 
  • Effective Influencer, 
  • Ecosystem Driver, and 
  • Coolest User Story.  
Nomination form is at https://forms.gle/fGdTbqoEeRWvb1YW7

Nominations close on Aug 31 11:59PM US Pacific and awards will be presented to the recipients on the keynote stage on Sep 11, 2019 in The Hague.

Feel free to ping me directly if you have questions.

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

--
-- Swarna Podila
Senior Director, Community | Cloud Foundry Foundation
spodila@...
@skpodila


routing-release 0.191.0

Aidan Obley <aobley@...>
 

Hello cf-dev!

We have shipped routing-release 0.191.0

Release Highlights

  • GoRouter supports indicator protocol to self-declare and self-document the monitoring and alerting behavior details
  • Fixed goroutine leak when WebSocket Requests timed out: cloudfoundry/routing-release #153 details
  • Fixed a bug that caused a disabled routing-api job to update the api VM on deploy: cloudfoundry/routing-release #155 details
  • Update go version to 1.12.9

Regards,
The Networking Program


Cloud Foundry Community Awards: Nominations close Aug 31

Swarna Podila
 

Hi Everyone,
It is that time of Cloud Foundry Summits where I nudge you all to nominate yourself or your peers, your organization or a peer's organization for the Community Awards.


TL;DR: there are four categories:
  • Committed Contributor, 
  • Effective Influencer, 
  • Ecosystem Driver, and 
  • Coolest User Story.  
Nomination form is at https://forms.gle/fGdTbqoEeRWvb1YW7

Nominations close on Aug 31 11:59PM US Pacific and awards will be presented to the recipients on the keynote stage on Sep 11, 2019 in The Hague.

Feel free to ping me directly if you have questions.

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


CF CLI v6.46.1 Released

Alexander Berezovsky
 

Hey everyone,

The CF CLI team released cf CLI v6.46.1 ; please see release notes for full details.

Highlights Include

Deprecation of --hostname--no-hostname-d--route-path on cf push

The cf CLI team reached out to the Community back in December 2017 to gather feedback about domains and hostnames app manifest properties. Based on feedback, in cf CLI release v6.34.0, the team moved forward with deprecating domains and hostnames properties in the app manifest in favor of the routes attribute.

At the time, the flag options to override the manifest properties were not deprecated. This release deprecates the flag options on cf push:

  • --hostname
  • --no-hostname
  • -d for domain
  • --route-path

When any of the above flag options are passed to cf push, a deprecation warning appears in output text. story

We are seeking feedback on this for the cf7 beta CLI. Please add feedback and comments if you have any concerns.

Update-One Is Generally Available

The SAPI and Services Enablement Team are GA'ing the Update-One Feature in this release. story

  • Adds a --force flag to update-service to support automation workflows story
  • Adds a helpful message if an upgrade is not available story

Bugs

  • Fixes an issue where update-user-provided-service can unset existing
    credentials associated with a service even when the -p flags is not specified story

Plugin Updates

  • Adds cf-security-entitlement plugin story
  • Updates top plugin to v0.9.4 story
  • Updates cf-puppeteer to 1.1.1 story
  • Updates html5-plugin to 1.3.0 story
  • Updates open plugin to v1.2.2 story
Thanks,
CF CLI Team


Re: cf7 beta CLI is available

Eric Malm <emalm@...>
 

Congratulations, Abby and the rest of the CLI and v3 Acceleration teams! That's a great accomplishment!

Best,
Eric


On Thu, Aug 22, 2019 at 6:05 PM Marco Nicosia <mnicosia@...> wrote:
Congratulations on making it to this milestone, VAT and CLI teams!

I know a lot of hours and work have gone into this, so this is a very special release.

I’m very excited for the coming feedback. I know that there’s still a lot of work to go, but really glad for it to be in the hands of real people!

On Thu, Aug 22, 2019 at 1:37 PM Tim Downey <tdowney@...> wrote:
Congratulations on shipping the beta V7 cf CLI! 🎉

Can't wait to start using it! 😎

On Thu, Aug 22, 2019 at 1:04 PM Abby Chau <achau@...> wrote:
Hi everyone,

We are excited to announce that the cf7 beta CLI is available and can be found on the cf CLI's release page. The V3 Acceleration Team (VAT formed to accelerate the development of the cf7 beta CLI and the backing v3 CC API) have been working hard on this first publicly consumable cf7 beta release. 

Please read the release notes and official documentation about new features on cf7, which commands we've converted to call the v3 API, and details about the differences between v6 and v7 cf CLIs.

A publicly consumable cf7 beta CLI triggers Phase 1 of the v6 Deprecation Plan, which stipulates that the majority of feature work will now be added to cf7 CLI only. v6 will continue to be fully supported, see the v6 Deprecation Plan for more information. 

Please reach out if you have feedback or questions. For cf7 CLI feedback, please open a GitHub issue, or reach out directly on Cloud Foundry Slack - we hang out at #v3-acceleration-team or #cli. 

Best,

V3 Acceleration and cf CLI teams

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


cfdev start Timed out waiting for the VM: rpc error

MatthiasLakaemper@...
 

Hi,
 
i have problems, starting cfdev.
 
System:      Windows 10 Enterprise via VMWare-Workstation with Virtualize Intel VT-x/'EPT or AMD-V/RVI -> enabled
cf version:   cf.exe version 6.46.0+29d6257f1.2019-07-09
i am using: pcfdev-v1.2.0-windows.tgz
 
any help is appreciated.
 
Regards, Matthias
 
-----Start-Protocol---------------------------------------------------------
cf dev start -f C:\Develop\CloudFoundry\pdfdev/pcfdev-v1.2.0-windows.tgz
 
cf dev start -f C:\Develop\CloudFoundry\pdfdev/pcfdev-v1.2.0-windows.tgz
Downloading Resources...
Progress: |====================>| 100.0%
Setting State...
 
Pivotal Telemetry
...
Are you ok with PCF Dev periodically capturing anonymized telemetry [y/N]?
 
y
Creating the VM...
Starting VPNKit...
Starting the VM...
Waiting for the VM...
FAILED
cf dev start: Timed out waiting for the VM: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:9999: connectex: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte."