Date   
Re: CF CLI v6.37.0 Released Today: Variable Substitution

Abby Chau
 

Hi Ronak,

We don't currently have that prioritised currently for the CF CLI, but please create a github issue for visibility and future consideration.

Thanks,

Abby


On Thu, May 31, 2018 at 11:44 PM, Ronak Banka <ronakbanka.cse@...> wrote:
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



(action requested) Changing CF App Display

Abby Chau
 

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

Re: Is anyone successfully using IPSec along with Windows Server 2016 (1709)?

Aaron Huber
 

After further testing with both the 1709 and 1803 versions of Windows Server 2016 it does appear that the WinNAT component being used by the Host Network Service in Windows does not play well with IPSec.  We've confirmed with both the open source Cloud Foundry and commercial PCF deployments that traffic to the containers stops working once IPSec is enabled.  We've also tested using out-of-the-box installations of both 1709 and 1803 with Docker for Windows and can replicate the same results - traffic to a container over the NAT connection to an exposed port stops working as soon as IPSec is enabled.

If anyone has successfully been able to get this working, please reply with any details.  In the mean time we'll be trying to reach out to Microsoft to confirm if this is a bug that can be fixed or if this is working as intended.

Aaron

Database support for UAA

Enrique Cano
 

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

Re: Proposed BOSH logging interface

Carlo Alberto Ferraris
 

Jesse,
sorry for the late reply. One thing we normally add to our internal bosh releases - something that is especially useful for the control/drain scripts, but that we do almost for every single process, is the ability to add a timestamp to each line and the PID of the process generating the logs. It would be very neat if the logging interface had an (opt-in?) provision to handle this so that release authors don't have to do it manually.

Re: Database support for UAA

Filip Hanik
 

hi Enrique,

UAA used to ship with Oracle compatibility back in 2012. Licensing issues can be overcome from a shipping standpoint since UAA only needs to ship with the JDBC library
What became problematic for the UAA was test driven development and continuous integration. Having actual Oracle database instances running in multiple environments.

The different databases have three components in UAA

1. The configuration - including some DB specific components to modify the JDBC URL on the fly [1] [2]
2. The migration scripts [3][4]

This can definitely be extracted to make it externally configurable to an already compiled version of the UAA. 
Such functionality does not exist today, it would have to be added through a contribution with accompanying tests.


On Wed, Jun 6, 2018 at 10:01 AM, <enrique.canocarballar@...> wrote:
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


CF Summit EU: CFP Deadline

Swarna Podila
 

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.

Proposal: Metadata for API resources

Zach Robinson
 

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

Re: Proposal: Metadata for API resources

David McClure
 

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

Re: CF Summit EU: CFP Deadline

Sara Elshahawy
 

Hi Swarna,

Thanks for the email. Actually I was wondering how to edit my proposal after submitting it, I would like to add few more points. Hope you can help!

Best Regards,
Sara 

Sr. TPM | Cloud Foundry | Dublin



On Thu, Jun 7, 2018 at 6:51 PM Swarna Podila <spodila@...> wrote:
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.

Re: Proposal: Metadata for API resources

Zach Robinson
 

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

Re: Proposal: Metadata for API resources

David McClure
 

Cool, that makes a lot of sense. Thanks for filling in that gap in my understanding.


On Fri, Jun 8, 2018 at 11:25 AM Zach Robinson <zrobinson@...> wrote:
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

Re: Proposal: Metadata for API resources

Stephan Merker
 

+1

 

We had to introduce a number of workarounds / extra book keeping to keep track for e.g. ‘system applications’, orgs belonging to the installation and not to customers, orgs requiring exceptions from quota handling etc.

Annotations are the natural place to store such information.

 

Best regards,

Stephan

 

From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Zach Robinson
Sent: Donnerstag, 7. Juni 2018 19:46
To: cf-dev@...
Subject: [cf-dev] Proposal: Metadata for API resources

 

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

Re: (action requested) Changing CF App Display

Abby Chau
 

Hello cf-dev,

Thanks to those who have taken the short survey; we very much appreciate your feedback. If you haven't had a chance to take the survey, please take a look and give us your feedback on the cf app display.

Best,

Abby


On Tue, Jun 5, 2018 at 6:49 PM, Abby Chau <achau@...> wrote:
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


#advocacy on CF Slack #advocacy

Swarna Podila
 

Let us use #advocacy channel to share information on upcoming industry events, "call for paper" deadlines, and other speaking opportunities that might be of interest for y'all.

Feedback request: Proposed changes to capi-release nfs_server.share_path

Tim Downey
 

Hello all,

Recently on the CAPI team we've been updating our BOSH jobs to run within BPM. BPM is opinionated with regards to which directories can be mounted within its containerized jobs. This means that in order to properly support NFS, we will need to update the default nfs_server.share_path to be located within the "/var/vcap/data" directory on Cloud Controller BOSH instances.

The nfs_server.share_path value is currently configurable across several jobs within capi-release, but we are considering removing this configurability in order to ensure that the NFS volume is mounted in the proper location.

We are wondering what the impact of this change would be and are interested in hearing from anyone who is currently setting nfs_server.share_path to a location other than the default path of "/var/vcap/nfs".

In summary: 
  • at a minimum we will need to change the default value of nfs_server.share_path to support BPM in capi-release
  • we are also proposing that we make it no longer configurable to ensure that jobs running within BPM have access to the NFS mount
Thanks!
Tim Downey and Elena Sharma
CAPI team members

Feedback request - Polyglot service discovery for container networking

Preethi Varambally
 

Hi,


The CF Networking team is working towards making Polyglot service discovery GA [1]. As part of this, operators can configure their own internal domains and we envision the following 2 scenarios.


Fresh install

- Operators use the CC APIs to configure internal domains

- Operators also have to configure a BOSH property "internal_domains" on the BOSH DNS adaptor job with the same internal domains


Upgrade from experimental service discovery

- apps.internal is already seeded into the cloud controller. No action is needed.

- Operators have to configure the BOSH property "internal_domains" on the BOSH DNS adaptor job to [apps.internal] to avoid downtime for apps using service discovery


If you are using the experimental feature, we would like to hear from you about any questions or concerns you may have on the upgrade process above.



Thanks,

CF Networking team



CAB call for June is Wednesday 06/20 @ 8a PST or 11a EST

Michael Maximilien
 

FYI...


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


1. CF Stratos UI update and demo of latest version by Neil MacDougall of SuSe [1] 


2. Project Blockheads: Ethereum Smart Contract Open Service Broker for CF and Kube by Nima Kaviani of IBM (winner of the CF Summit -Boston Hackathon)  [2] 


Zoom soon. Best,



Buildpack Cache

Stephan Merker
 

Hi,

 

is there documentation available that describes how the buildpack cache works?

 

I found the following info:

https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html

“The Task downloads buildpacks and the app’s buildpack cache, if present.”

 

https://github.com/cloudfoundry/java-buildpack/blob/master/docs/extending-caches.md

 

I wonder how often the buildpacks and artifacts like JVM, Tomcat etc. are downloaded and how they are cached? Is this cache per app, per diego cell, CF global?

I’m talking about the default online buildpacks.

 

Thanks,

Stephan

 

Re: Is anyone successfully using IPSec along with Windows Server 2016 (1709)?

Aaron Huber
 

Just to close on this Microsoft has confirmed that this is expected for now, using IPSec along with WinNAT is not supported in 1709, 1803, or the upcoming Windows Server 2019.  They are considering it for inclusion in a future release but there is no timeline.  For now there is no way to encrypt the traffic between the gorouter and the containers on Windows which will prevent us (and others I'm sure) from moving off of Windows Server 2012 R2 for legacy .NET apps.  Hopefully Envoy will be working on Windows soon (https://github.com/envoyproxy/envoy/issues/129) so we can remove the IPSec dependency.

Aaron