Hello cf-dev,

In order to provide a better user experience, the Cloud Foundry CLI team is considering changing the   cf app app-name  key-value and table display information. Towards this effort, we are asking the community to complete a short survey. 

Actions: Please fill out this short survey [1] to help us understand how you use the cf app app-name command display, and your thoughts on changing the display to default to the V3-app version of the command. The survey will close by end of day, June 15th. 

Thanks in advance for your time and participation.

Best,

Abby Chau

CF Product Manager - CLI

[1] https://goo.gl/forms/fbAnwZNj0sGF34Nz2

Thanks for taking the time to read through it.

There was no specific consideration around API similarity in general.  It just seemed to make sense for this specific use case. Kube has a nice partitioning of different types of data -- labels vs annotations -- that matched up well with what we have heard regarding what folks would use metadata for. It also made sense to consider for these specific APIs since a large reason for metadata is third party system integration.  I've spoken with several folks that are building systems that manipulate objects in both systems, so having low cognitive overhead for cross-platform integration felt like a good path to pursue.

On Fri, Jun 8, 2018 at 2:15 AM David McClure <dmcclure@...> wrote:

I read through this yesterday and didn't have any specific comments to leave in-line, but I am happy to see this surface now as I know it's come up in a number of settings in the past.  I also thought it was interesting to see the open, implicit acknowledgement of seeking inspiration of convergence with the analogous feature set in Kubernetes. This feels like a healthy thing to see continuing to happen in this community, but I'm also curious to know whether there's any more to it that is worth sharing in this particular case.

Aside from meeting user expectations because they may end up using similar features on either CF or Kubernetes, is there any reason or background in the thinking around aiming to have these APIs or experiences  be more or less similar to each other?

On Thu, Jun 7, 2018 at 10:46 AM Zach Robinson <zrobinson@...> wrote:

Hey all,

The CAPI team would like to share a proposal to apply metadata to API resources.  Please have a look and add comments for any questions or concerns.

https://docs.google.com/document/d/1Ebko_wNu4wWLnAdHg6wmydEMTx_IdwYnb4Ys0mxVmM4/edit?usp=sharing

Thanks!
-Zach, CAPI Project Lead

I read through this yesterday and didn't have any specific comments to leave in-line, but I am happy to see this surface now as I know it's come up in a number of settings in the past.  I also thought it was interesting to see the open, implicit acknowledgement of seeking inspiration of convergence with the analogous feature set in Kubernetes. This feels like a healthy thing to see continuing to happen in this community, but I'm also curious to know whether there's any more to it that is worth sharing in this particular case.

Aside from meeting user expectations because they may end up using similar features on either CF or Kubernetes, is there any reason or background in the thinking around aiming to have these APIs or experiences  be more or less similar to each other?

On Thu, Jun 7, 2018 at 10:46 AM Zach Robinson <zrobinson@...> wrote:

Hey all,

The CAPI team would like to share a proposal to apply metadata to API resources.  Please have a look and add comments for any questions or concerns.

https://docs.google.com/document/d/1Ebko_wNu4wWLnAdHg6wmydEMTx_IdwYnb4Ys0mxVmM4/edit?usp=sharing

Thanks!
-Zach, CAPI Project Lead

Our community has done a phenomenal job of electing the co-chairs for Summit EU in Basel.  Please take a look at the co-chairs at https://www.cloudfoundry.org/blog/announcing-2018-cloud-foundry-eu-summit-track-co-chairs-cfp-extension/.

The deadline to submit your speaking proposals is tomorrow, June 8th at 11.59pm US Pacific time.

Have a question before submitting your proposal?  Post it on #summit channel on slack and/or tag @cfp-help.

Submitted your proposal already but not sure how to edit it?  Email me directly or send me a slack private message.

Hey all,

The CAPI team would like to share a proposal to apply metadata to API resources.  Please have a look and add comments for any questions or concerns.

https://docs.google.com/document/d/1Ebko_wNu4wWLnAdHg6wmydEMTx_IdwYnb4Ys0mxVmM4/edit?usp=sharing

Thanks!
-Zach, CAPI Project Lead

I understand that UAA can run against MySQL and Postgres as the backend database, and Oracle was considered in the past but was discarded due to the enterprise licensing model (https://github.com/cloudfoundry/uaa/issues/291).
My question is whether there is a way to develop support for Oracle (or any other database) without having to integrate the code within the UAA repo. In other words, is there a way to externalise the components to support a different database and then make it work alongside UAA's war file?

Thanks

Enrique

Hi Abby,

Going forward is there something on roadmap to use ops files for cf CLI too, like we do for Bosh CLI or yaml patch?

Use case can be CI/CD pipelines where part of manifest can be injected for different environment.

Thanks

Ronak

On Thu, 31 May 2018 at 7:37 AM, Abby Chau <achau@...> wrote:

Hi Benjamin,

Thanks for reaching out; we will update the documentation for clarification. The partial value use case, for example, is a manifest.yml with the following:

- route: ((host)).example.com

and a variable.yml file which invokes the value by passing in the hostname:

host: test

When you push with the manifest and variable file, the route test.example.com will be created. Hope that makes sense. 

Best,

Abby

On Wed, May 30, 2018 at 7:30 AM, Benjamin Gandon <benjamin@...> wrote:

Hi Abby,

In the documentation for variable substitution, when it’s said:

Template variables can also be used as partial values, such as in:

It’s quite unclear what is meant by “partial values”, and the example doesn’t bring an illustration to this. Indeed, correct me if I’m wrong but this second example looks the same as the first one, because using --vars-file <(cat secrets.yml) should be quite the same as writing --vars-file secrets.yml.

Maybe “partial values” was a way to say that multiple --vars-file arguments can be used?

Benjamin

Le 30 mai 2018 à 03:17, Abby Chau <achau@...> a écrit :

Hi all,

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

Highlights include:

• Variable substitution - (replaces inheritance) which allows app developers to create app manifests with values shared across all applicable environments in combination with references to environment-specific differences defined in separate files
  
• Now the CLI reads username and password from environment variables
  
• If you are using a API version older than 2.69.0, a warning displays asking you to update your API version - as the CLI no longer supports versions older than 2.69.0
  

Bug Fixes:

• Fixes a bug whereby X-Cf-Warnings were not being unescaped when displayed to user
  
• When using CF_TRACE=1, passwords are now sanitized
  

Let us know if you have any comments or feedback, thanks!

Best,

Abby Chau

Product Manager, CF CLI

Bosh system metrics can not filter based on deployment (or any other criteria).

We haven't heard about this use case yet but it does sound interesting. If filtering were an option, would you have one deployment of CF with no filter enabled to receive metrics from deployments for non-cf releases (e.g. postgres, redis, et cetera)?

In terms of security, there are no deployment-level permissions on the forwarder client: any consumer that successfully connects to the bosh-system-metrics-server has access to the entire stream. Filtering could occur on either end (director or forwarder), but either way, all metrics will be accessible to any deployment.

It would be relatively straight-forward to fork and add a deployment filter option to the code (1).

1. This is where the bosh-system-metrics-forwarder receives metrics from the bosh-system-metrics-server: https://github.com/cloudfoundry/bosh-system-metrics-forwarder-release/blob/master/src/github.com/pivotal-cf/bosh-system-metrics-forwarder/pkg/ingress/ingress.go#L182