1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Changing IP addresses in deployed CF

Jonathan Stockley
 

Hi,

We are using cf-deployment release 1.15.0 in a vSphere environment and are looking at DR strategies.

Up until now, we have implemented DR by replicating the persistent disks to another vSphere configured with the same datastores and network config (i.e. IP addresses in both DCs are the same).

 

We now have to deploy into datacenters that have different IP networks. It has been suggested that we can update the IP addresses in the persistent disks when bringing up the DR site.

 

Is there any information as to where CF stores IP addresses of various components (config files, db tables, etc.) that I could use to determine the effort required to patch everything to use IP addresses in DR environment?

 

Thanks,

Jo
REMINDER: CF CAB call for October live @ CF Summit in Basel, Switzerland on Thursday 3p local time

Michael Maximilien
 

FYI...


No planned agenda. Just chit chat, recap, QAs, and discussions. Grab a drink and join us.

We’ll try to broadcast it live if there is a remote audience. Tune to #cab slack channel for details.

Best,

dr.max
ibm ☁ 
silicon valley, ca
How plugin updates are handled in cloud foundry?

Sigal, Maya
 

Hi,

I went through the following documentation:

https://github.com/cloudfoundry/cli/tree/master/plugin/plugin_examples,

however it couldn’t help.

I would like to know how are a plugin updates are handled in cloud foundry?

For example, if I have some hot fix, and I would like to have my plugin to be  updated by all users  ?

Do they have to issue the command  cf plugins –outdated, are they at least informed about available updates or can the updates be forced?

I couldn’t find this information.

 

Thanks in advance, Maya Sigal

Handing over the cf-resource and autopilot projects

Christopher Brown
 

Hi all,


We (Alex Suraci & Christopher Brown) would like to propose handing the cf-resource and the underlying autopilot CF CLI plugin over to the CF Foundation and the community. The cf-resource is too specialized for the core Concourse distribution and I don’t have time to effectively and responsibly maintain the autopilot plugin anymore.


Both projects could do with some love and a vision for their future. We’d like to move them into one of the Cloud Foundry GitHub organizations (I’m not sure which one makes sense) and find maintainer(s) for them.


Would anyone who has made contributions to these projects in the past or relies on them heavily be interested in becoming a maintainer?


Thanks,

Alex & Christopher
Re: Propose removing --no-start from cf push in CLI v7

Zach Robinson
 

Hi Norm,

That's an interesting possible UX. Part of this process is to gather feedback before making a change and to potentially alter the proposal to better fit everybody's needs.  Thanks for sharing this.
Re: Propose removing --no-start from cf push in CLI v7

Zach Robinson
 

Hi Dr Nic,

Yes this is a proposal to maintain that workflow, but with a slightly different command set. The title is bad.  Should have called it Proposal to replace --no-start.

-Zach
Re: [cf-bosh] BOSH Stemcell Support Policy

Marco Voelz
 

Dear Morgan,

 

I don't have the rights to comment in the attached document, so I guess I'll leave my comments here.

 

We should specifically mention how we're dealing with the case of switching operating systems. We're doing it now by switching from Trusty to Xenial, and we will do it again when we switch from Xenial to Bionic or 20.04 (whatever it will be called).

 

In cases like this, will ne do N and N-1 per operating system version (i.e. N and N-1 on Trusty as well as N and N-1 on Xenial) – at least for some grace period?

 

Thanks and warm regards

Marco

 

From: <cf-bosh@...> on behalf of Morgan Fine <mfine@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Friday, 28. September 2018 at 20:58
To: "cf-dev@..." <cf-dev@...>, "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] BOSH Stemcell Support Policy

 

Hi CF Community,

 

The BOSH team is working to formalize a policy for Linux stemcell support. Up until now, the team has not had a policy on which stemcell lines are officially supported. We'll also be working to make this information available on bosh.io. 

 

Please find the details in the attached document.

 

 

Best,

Morgan Fine

CF BOSH 
Re: Propose removing --no-start from cf push in CLI v7

Norm Abramovitz
 

Hi

It seems to me that you are making the developer experience more painful with your new interface   I wondering why you did not consider using parameters to cf push instead.   The first parameter would be a stop after parameter to stop after a phase.   

--stop-after build|droplet|staging|start

If you want to start at a particular phase versus starting with a build, then have a parameter starting at a phase.

--start-at build|droplet|staging|start

Most developers would still use cf push as it is now and only those people that need the new features will use them.  Also, you maintain the readability of the cli interface.

Now the no-start parameter can be maintained for backward compatibility.



On Thu, Oct 4, 2018 at 1:29 PM Zach Robinson <zrobinson@...> wrote:
Hey all,

We asked for some feedback regarding the use of the --no-start flag some time ago. As a result, we're proposing a change to push in the upcoming CLI v7.  In the linked doc we've described what the change is and why we want to make it.  We'd love to hear any feedback in comments on the doc.

https://docs.google.com/document/d/1OPJSUYXMQMtzZmVdnvwI4NiXE0xp4tuLxO3fhhXtGwI/edit?usp=sharing
Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead



--
Norman Abramovitz
Technical Director
Stark & Wayne, LLC
Re: Propose removing --no-start from cf push in CLI v7

Dr Nic Williams <drnicwilliams@...>
 

I’ve used —no-start to create an new app so I can bind services, then push to start. Is there a different way to do this without —no-start (and before you’ve started creating an optional manifest)

Nic

 

From: 20002216260n behalf of
Sent: Friday, October 5, 2018 4:29 am
To: cf-dev@...
Subject: [cf-dev] Propose removing --no-start from cf push in CLI v7
 
Hey all,

We asked for some feedback regarding the use of the --no-start flag some time ago. As a result, we're proposing a change to push in the upcoming CLI v7.  In the linked doc we've described what the change is and why we want to make it.  We'd love to hear any feedback in comments on the doc.

https://docs.google.com/document/d/1OPJSUYXMQMtzZmVdnvwI4NiXE0xp4tuLxO3fhhXtGwI/edit?usp=sharing
Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead

Propose removing --no-start from cf push in CLI v7

Zach Robinson
 

Hey all,

We asked for some feedback regarding the use of the --no-start flag some time ago. As a result, we're proposing a change to push in the upcoming CLI v7.  In the linked doc we've described what the change is and why we want to make it.  We'd love to hear any feedback in comments on the doc.

https://docs.google.com/document/d/1OPJSUYXMQMtzZmVdnvwI4NiXE0xp4tuLxO3fhhXtGwI/edit?usp=sharing
Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead
Future usage of instance identity credentials

matthias.winzeler@...
 

Hi all

 

I was quite excited when I found out about instance identity credentials (https://docs.cloudfoundry.org/devguide/deploy-apps/instance-identity.html):

Each app gets its own x509 keypair that can be used for mTLS - and it’s even rotated automatically! This looks like a powerful enabler for all kind of future mTLS scenarios.

 

However, it looked like this keypair is currently limited to three use cases:

  • Gorouter to App TLS (route integrity)
  • Interpolation of Credhub refs to env credentials on container start time (outside of app)
  • Java buildpacks automatically watches CF_INSTANCE_CERT/CF_INSTANCE_KEY files, making sure these (changed) keypair land automatically in the apps java truststore/keystore.
    (https://github.com/cloudfoundry/java-buildpack-security-provider)
    This is very interesting, since this basically means all java apps automagically use the keypair in all their https requests, smtps connections, database connections etc.
    Which means – we can use it for our use cases, too!

 

Why I’m interested about this:

  • We’re currently designing a new MySQL service
  • We would like to allow clients to connect with mTLS
  • On binding time, we would basically restrict the TLS client connection to the app that it’s bound to (identified by the app guid in the x509 CN)
  • This would work out of the box with the java buildpack and mysql client – java buildpack security provider would add the keys, and spring cloud connector mysql would set up the usual jdbc connection – great UX!
  • However, apps other than java do not profit from this. They could read the files from CF_INSTANCE_CERT and CF_INSTANCE_KEY (like for example this library does https://downey.io/blog/securing-rails-credentials-cloud-foundry-credhub/).

But: the app does not notice when the keypair is rotated, causing the connection to break after the first rotation.

 

Are there any plans to add support (i.e. automatic watching and insertion) for other buildpacks so that CF_INSTANCE_CERT/CF_INSTANCE_KEY becomes a first class resource for all kind of apps?

 

If someone of the Credhub team is at CF Summit Basel next week I’d be very happy to chat about this!

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd
Re: CC API V3 and CLI v7 Initiative

Abby Chau
 

Hi Guillaume,

Thanks for your email. 

Please feel free to drop by the CF CLI office hours at Summit. Looking forward to speaking. 

Best,

Abby


On Wed, Oct 3, 2018 at 10:28 AM Guillaume Berche <bercheg@...> wrote:
Hi Zach,

Some feedback related to the deprecation of the CC API V2 in favor of V3: 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) so sync the CC API V2 support policy with availability of CC API V3 support in clients is most widely used programming languages.

The terraform-provider-cf [1]  in particular is quite interested in having the CF CLI CC API client being extracted into a distinct repo, and be more developer friendly, see related discussions in [3][4]. Part of the terraform-provider-team will be at basel summit (see related talk at [1b]) and would be eager to exchange with the CF CLI team on this topic, possibly during the CF CLI office hours.

Thanks,

Guillaume.

[3] https://github.com/mevansam/terraform-provider-cf/issues/56#issuecomment-410952359

On Tue, Oct 2, 2018 at 6:46 PM Zach Robinson <zrobinson@...> wrote:

Hello cf-dev,

We are writing to announce a couple of major plans for both the CC API and the CF CLI teams. We've recently formed a new team: the v3 acceleration team.

What?

The goals of the team are to:

  • Complete the v3 CC API and deprecate the v2 CC API

  • Introduce a new major CLI release which will be backed by the v3 CC api

  • Deprecate both the v2 CC API and the v6.x.x CLI in a sustainable, and orderly manner - taking into account support policies and giving as much buffer as possible so that the Community can make the transition seamlessly.

Why?

New API features are currently being developed on the v3 CC API, which introduced new features including running tasks, defining app processes via a Procfile, and granular control of an application lifecycle.

The development teams are happy with the API interface as well as the changes in underlying implementation of the v3 CC API. Given the desire to implement all new features in the v3 CC API, it is now necessary to complete moving the rest of the existing v2 CC API over to v3.

To expose the v3 api to end users, the CLI team implemented v3 prefixed commands in CLI release v6.32.0; and in CLI release v6.38.0, we updated the `cf app` to use the v3 endpoint.


However, whilst working toward this v3 effort, both the CAPI and CLI teams came to the realization that development work for the v3 api, and the CLI's adoption of it, is best done as a dual effort for a number of reasons:

  • in the v3 api, the very definition of an app has changed. Instead of being defined by the instance, in v3, an app is defined by its process. This has implications for how you interact with an app from the CLI perspective: from pushing an app, to scaling it, to setting its health checks - it is now done by process type, not instance type.

  • the feedback process would be greatly enhanced for both products if development work is done in lockstep as both the CC API and the CLI introduces changes and product enhancements to our users

  • we plan on introducing new beta major releases of the CLI which will only be compatible with the latest CC API release, and will not be backwards compatible - we will only support the latest version of the beta release. This allows us to expose new features of the v3 endpoints and to redefine some of the interface in a sustainable manner. Once the beta releases are backed completely by the v3 api, and we've incorporated your feedback sufficiently, we will GA a major release of the CLI.  It's important to note that the v6 CLI will continue to be a separate team, and they will continue to maintain the v6 CLI including releasing bug fixes, CVEs, and a limited number of new features

Please let us know if you have any questions or concerns about this approach; you can find us on slack at #v3-acceleration-team. We are also at CF Summit on October 11th: office hours at 11:15am (Lounge 1, The Foundry for the CF CLI and Lounge 2, The Foundry for CAPI).


Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead
A new approach to forwarding application logs to syslog drains

Johannes Tuchscherer
 

Hi there,

the loggregator team has come across a few cases where in a big cf deployment with over 9k application-bound syslog drains the scalable syslog adapter is reaching its scaling limits (pun intended). 
We spent some time rethinking the problem regarding the forwarding of application logs to syslog drains. We came to the conclusion that the forwarding best happens as close to the origin of the logs as possible. To implement that strategy, we want to introduce some process on the diego cell (maybe integrated in the loggregator agent aka metron agent), that will forward each application log line directly to the configured syslog endpoint. You can read more details in this document:

Please let us know if you have any questions or concerns about this approach.

Thanks,
Johannes
Re: CC API V3 and CLI v7 Initiative

Guillaume Berche
 

Hi Zach,

Some feedback related to the deprecation of the CC API V2 in favor of V3: 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) so sync the CC API V2 support policy with availability of CC API V3 support in clients is most widely used programming languages.

The terraform-provider-cf [1]  in particular is quite interested in having the CF CLI CC API client being extracted into a distinct repo, and be more developer friendly, see related discussions in [3][4]. Part of the terraform-provider-team will be at basel summit (see related talk at [1b]) and would be eager to exchange with the CF CLI team on this topic, possibly during the CF CLI office hours.

Thanks,

Guillaume.

[3] https://github.com/mevansam/terraform-provider-cf/issues/56#issuecomment-410952359

On Tue, Oct 2, 2018 at 6:46 PM Zach Robinson <zrobinson@...> wrote:

Hello cf-dev,

We are writing to announce a couple of major plans for both the CC API and the CF CLI teams. We've recently formed a new team: the v3 acceleration team.

What?

The goals of the team are to:

  • Complete the v3 CC API and deprecate the v2 CC API

  • Introduce a new major CLI release which will be backed by the v3 CC api

  • Deprecate both the v2 CC API and the v6.x.x CLI in a sustainable, and orderly manner - taking into account support policies and giving as much buffer as possible so that the Community can make the transition seamlessly.

Why?

New API features are currently being developed on the v3 CC API, which introduced new features including running tasks, defining app processes via a Procfile, and granular control of an application lifecycle.

The development teams are happy with the API interface as well as the changes in underlying implementation of the v3 CC API. Given the desire to implement all new features in the v3 CC API, it is now necessary to complete moving the rest of the existing v2 CC API over to v3.

To expose the v3 api to end users, the CLI team implemented v3 prefixed commands in CLI release v6.32.0; and in CLI release v6.38.0, we updated the `cf app` to use the v3 endpoint.


However, whilst working toward this v3 effort, both the CAPI and CLI teams came to the realization that development work for the v3 api, and the CLI's adoption of it, is best done as a dual effort for a number of reasons:

  • in the v3 api, the very definition of an app has changed. Instead of being defined by the instance, in v3, an app is defined by its process. This has implications for how you interact with an app from the CLI perspective: from pushing an app, to scaling it, to setting its health checks - it is now done by process type, not instance type.

  • the feedback process would be greatly enhanced for both products if development work is done in lockstep as both the CC API and the CLI introduces changes and product enhancements to our users

  • we plan on introducing new beta major releases of the CLI which will only be compatible with the latest CC API release, and will not be backwards compatible - we will only support the latest version of the beta release. This allows us to expose new features of the v3 endpoints and to redefine some of the interface in a sustainable manner. Once the beta releases are backed completely by the v3 api, and we've incorporated your feedback sufficiently, we will GA a major release of the CLI.  It's important to note that the v6 CLI will continue to be a separate team, and they will continue to maintain the v6 CLI including releasing bug fixes, CVEs, and a limited number of new features

Please let us know if you have any questions or concerns about this approach; you can find us on slack at #v3-acceleration-team. We are also at CF Summit on October 11th: office hours at 11:15am (Lounge 1, The Foundry for the CF CLI and Lounge 2, The Foundry for CAPI).


Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead
403 Forbidden Nginx

mjana@...
 

Hi,

I am getting 403 Forbidden Nginx when I type URL: https://preonboarding.apps.eu1.mindsphere.io/

What should I do now?
Re: CF Application Runtime PMC - CF Loggregator Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

Hello all,

Pivotal is nominating Johannes Tuchscherer for the Loggregator Project Lead in the Application Runtime PMC.

Any other nominations should be sent to me/in reply by end of day October 10th, 2018.

Johannes has been working with Cloud Foundry since 2013 when he joined the Loggregator team in Boulder, CO as an engineer. The last two years he spent in Munich, Germany, where he worked with several companies on different stages of their journey with Cloud Foundry.  After returning to Colorado earlier this year, he joined the Loggregator and Log-Cache team as a support PM pairing with Adam Hevnor to gain context on the projects.
Before working on Cloud Foundry he worked at Pivotal Labs as a full-stack developer.

-Dieu Cao

On Tue, Oct 2, 2018 at 10:55 AM Dieu Cao <dcao@...> wrote:
Hello All,

Adam Hevenor, the Project Lead for the Loggregator team within the Application Runtime PMC, is rotating into a role internal to Pivotal. We thank him for his time serving as the Loggregator Project Lead.

The Loggregator team, primarily located in Denver, Colorado, 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 October 10th, 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
CF PMC Council Chair
CF Application Runtime PMC - CF Loggregator Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

Hello All,

Adam Hevenor, the Project Lead for the Loggregator team within the Application Runtime PMC, is rotating into a role internal to Pivotal. We thank him for his time serving as the Loggregator Project Lead.

The Loggregator team, primarily located in Denver, Colorado, 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 October 10th, 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
CF PMC Council Chair
CC API V3 and CLI v7 Initiative

Zach Robinson
 

Hello cf-dev,

We are writing to announce a couple of major plans for both the CC API and the CF CLI teams. We've recently formed a new team: the v3 acceleration team.

What?

The goals of the team are to:

  • Complete the v3 CC API and deprecate the v2 CC API

  • Introduce a new major CLI release which will be backed by the v3 CC api

  • Deprecate both the v2 CC API and the v6.x.x CLI in a sustainable, and orderly manner - taking into account support policies and giving as much buffer as possible so that the Community can make the transition seamlessly.

Why?

New API features are currently being developed on the v3 CC API, which introduced new features including running tasks, defining app processes via a Procfile, and granular control of an application lifecycle.

The development teams are happy with the API interface as well as the changes in underlying implementation of the v3 CC API. Given the desire to implement all new features in the v3 CC API, it is now necessary to complete moving the rest of the existing v2 CC API over to v3.

To expose the v3 api to end users, the CLI team implemented v3 prefixed commands in CLI release v6.32.0; and in CLI release v6.38.0, we updated the `cf app` to use the v3 endpoint.


However, whilst working toward this v3 effort, both the CAPI and CLI teams came to the realization that development work for the v3 api, and the CLI's adoption of it, is best done as a dual effort for a number of reasons:

  • in the v3 api, the very definition of an app has changed. Instead of being defined by the instance, in v3, an app is defined by its process. This has implications for how you interact with an app from the CLI perspective: from pushing an app, to scaling it, to setting its health checks - it is now done by process type, not instance type.

  • the feedback process would be greatly enhanced for both products if development work is done in lockstep as both the CC API and the CLI introduces changes and product enhancements to our users

  • we plan on introducing new beta major releases of the CLI which will only be compatible with the latest CC API release, and will not be backwards compatible - we will only support the latest version of the beta release. This allows us to expose new features of the v3 endpoints and to redefine some of the interface in a sustainable manner. Once the beta releases are backed completely by the v3 api, and we've incorporated your feedback sufficiently, we will GA a major release of the CLI.  It's important to note that the v6 CLI will continue to be a separate team, and they will continue to maintain the v6 CLI including releasing bug fixes, CVEs, and a limited number of new features

Please let us know if you have any questions or concerns about this approach; you can find us on slack at #v3-acceleration-team. We are also at CF Summit on October 11th: office hours at 11:15am (Lounge 1, The Foundry for the CF CLI and Lounge 2, The Foundry for CAPI).


Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead
Re: BOSH PMC refactoring part 2 – moving CPIs out of incubation

Marco Voelz
 

Der friends of BOSH,

 

We have moved the below CPIs from the cloudfoundry-incubator to the cloudfoundry github organization. The new releases will soon arrive on bosh.io after adapting its configuration [1].

 

For now, bosh.io/releases will still contain both, the releases for cloudfoundry-incubator as well as the releases in cloudfoundry. After a grace period of four weeks, ending November 1st, we will remove the cloudfoundry-incubator based releases from the bosh.io/releases listing for those CPIs [2]. Until then, please adapt any references to bosh.io/releases for the 5 CPIs below.

 

Reach out to me directly or reply to this mail if you have any comments or this grace period won't work for you.

 

Warm regards

Marco

 

[1] https://github.com/bosh-io/releases/pull/58

[2] https://github.com/bosh-io/releases/pull/59

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 23. August 2018 at 11:17
To: "cf-bosh@..." <cf-bosh@...>
Cc: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [CAUTION] [cf-dev] BOSH PMC refactoring part 2 – moving CPIs out of incubation

 

Dear friends of BOSH,

 

The BOSH project management committee (PMC) proposes to promote the most mature and widely used CPIs from incubation to full project status. Specifically, we want to promote these CPIs

  • AWS CPI [1]
  • OpenStack CPI [2]
  • VSphere CPI [3]
  • Google CPI [4]
  • Azure CPI [5]

 

Promoting the projects has some impact on their users, depending on how you consume the CPIs

  • We will move the repositories from the cloudfoundry-incubator to the cloudfoundry organization in github. Github takes care of redirecting from the old repository location to the new one, so all links and references to the old repositories should still work. 
  • References on bosh.io currently include the github organization name [6]. In the past, there have been issues with people consuming outdated releases from bosh.io after they had been renamed or moved – we might need a similar mechanism of redirecting that github provides to avoid that.

 

Please reach out to by replying to this mail or contacting me personally if you have questions, concerns, or comments.

 

Warm regards

Marco

 

PS: cross-posted on cf-developers for greater reach and potential experiences about previous promotions from incubator to full project.

 

 
Re: Not able to Login CFDev using windows 10 Hyper-V #cf

ganeshbabu.rajan@...
 

Where do I see my logs ?
1081 - 1100 of 9388