1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: CF Application Runtime PMC - Release Integration Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

Hello all,

Pivotal is nominating Josh Collins for the Release Integration Project Lead in the Application Runtime PMC.  He is currently serving as Interim Project Lead for the Release Integration team.

Any other nominations should be sent to me/in reply by end of day July 3rd, 2018.

Josh was previously the director of product management for a personalized products company and subsequently he managed the A/B testing and optimization efforts for a B2C career development company. Early in his career, Josh worked with a team of three to design and launch the flagship product of what is now a successful company in the backup and disaster recovery space. 

In a previous life, Josh worked for the Berkeley Unified School District as a middle-school teacher and supplemented his income selling foraged wild mushrooms to local restaurants in Berkeley and Oakland. While working as a teacher he ran the school's computer lab and began his journey into networking, graphic design,  web development and beyond. His early successes moonlighting on tech gigs changed his trajectory and ultimately leading to his current employment at  Pivotal.

Josh joined Pivotal R&D in March 2017.

Josh holds a BA in Art from the University of California, Santa Cruz and an MA in Education from University Washington Seattle.

-Dieu Cao


On Mon, Jun 25, 2018 at 3:15 PM Dieu Cao <dcao@...> wrote:
Hello All,

David Sabeti, the Project Lead for the Release Integration team within the Application Runtime PMC, is transitioning back to engineering. We thank him for his time serving as the Release Integration Project Lead.

The Release Integration team, primarily located in San Francisco, 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 July 3rd, 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
Re: CF Application Runtime PMC - Release Integration Project Lead Call for Nominations

Michael Maximilien
 

Hi, Dieu, David, and teams,

Let me personally (and on behalf of IBM’s CF team) thank David Sabeti for an outstanding job transitioning us all to cf-deployment.

In the process, also making CF releases, in general, easier to manage and deploy.

Well done and look forward to having him in other engineering roles.

Best,

Max

On Mon, Jun 25, 2018 at 5:15 PM Dieu Cao <dcao@...> wrote:
Hello All,

David Sabeti, the Project Lead for the Release Integration team within the Application Runtime PMC, is transitioning back to engineering. We thank him for his time serving as the Release Integration Project Lead.

The Release Integration team, primarily located in San Francisco, 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 July 3rd, 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

--
dr.max Sent from my iPhone http://maximilien.org
Feedback request - Polyglot service discovery for C2C networking

Preethi Varambally
 

Hi,


Polyglot service discovery has been available since early 2018. This feature provides DNS-based service discovery that lets apps find each others’ internal addresses. If you are using this feature, please fill out this form [1] to let us know your feedback on the feature.


[1] https://docs.google.com/forms/d/e/1FAIpQLSfOMI8YmO9HL5mnF30V38_yDjYMKtFOfdipr_Q51qKR_uQtTA/viewform?c=0&w=1


Thanks,

CF Networking team
CF Application Runtime PMC - Release Integration Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

Hello All,

David Sabeti, the Project Lead for the Release Integration team within the Application Runtime PMC, is transitioning back to engineering. We thank him for his time serving as the Release Integration Project Lead.

The Release Integration team, primarily located in San Francisco, 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 July 3rd, 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
PM Vacancy for Auto-Scaler

Michael Maximilien
 

Hi, all,

We have a PM vacancy for the AutoScaler project and the team has nominated Bo Yang from IBM (one of the lead engineers for the initial project) as replacement.

Please suggest any other nominations before July 2nd. We will decide after if a vote is necessary.

Thanks for your time. Best,

dr.max
ibm ☁ 
silicon valley, ca
Action Required: Deprecating the built-in garden aufs filesystem driver ("garden-shed")

Julz Friedman
 

Hi cf-developnauts!

I wanted to quickly remind y'all, and seek any remaining feedback, about our plans to deprecate the garden-shed filesystem driver in an upcoming garden release. 

We previously communicated about this here [0], the tl;dr is we have a new filesystem driver implementation, named grootfs, which has been running in production for a while now. At the start of the year we made this the default in garden [1], with an opt-out property to temporarily re-enable the old implementation, in case of problems. It's now coming up on 6 months later.

As far as we know - and this is where you come in! - all remaining bugs, issues and blockers requiring people to opt out of the new driver are resolved, and we are therefore planning to remove the deprecated garden-shed driver, and corresponding config option, in an upcoming garden release. 

ACTION REQUIRED: If you were opting-out of grootfs for any reason, please urgently try again and report any bugs or blockers to us (via GitHub issues, #garden slack, or Tracker) so we can fix them! As of right now we believe everyone is fine for us to delete garden-shed, and we plan to do that soon unless we hear otherwise!

Thanks!
Julz, on behalf of the gardenandgroot team,
Re: (action requested) cf app display changes

Abby Chau
 

Here is the link to the survey: https://goo.gl/forms/5lHCbAIEiQf03G1g2. Thanks!

On Fri, Jun 22, 2018 at 9:36 AM, Abby Chau <achau@...> wrote:
Hi everyone,

The CF CLI team sent out a two minute survey recently to gather feedback on changes [1] to the `cf app` display summary information. Please have your say on how the `cf app` summary will change in a future release. Thanks!

Best,

Abby Chau and the CLI team
CF Product Manager, CF CLI


[1]  Based on your feedback recently, we've decided to change the `cf app` to default to the v3 app endpoint. What this means is: 
  • users on CC API 3.27.0 or higher, the `cf app app-name` display will change in an upcoming CF CLI release - how the display will change is largely based on your feedback above 
  • for users on CC API 3.27.0 or lower, you will continue to see the current `cf app app-name` display; you will not see the new v3 display unless you upgrade to CC API 3.27.0 or higher (and you have the latest version of the CF CLI)
(action requested) cf app display changes

Abby Chau
 

Hi everyone,

The CF CLI team sent out a two minute survey recently to gather feedback on changes [1] to the `cf app` display summary information. Please have your say on how the `cf app` summary will change in a future release. Thanks!

Best,

Abby Chau and the CLI team
CF Product Manager, CF CLI


[1]  Based on your feedback recently, we've decided to change the `cf app` to default to the v3 app endpoint. What this means is: 
  • users on CC API 3.27.0 or higher, the `cf app app-name` display will change in an upcoming CF CLI release - how the display will change is largely based on your feedback above 
  • for users on CC API 3.27.0 or lower, you will continue to see the current `cf app app-name` display; you will not see the new v3 display unless you upgrade to CC API 3.27.0 or higher (and you have the latest version of the CF CLI)
Re: Quick (2 min) survey for the Cloud Foundry Community!

Brandon Hudlemeyer
 



On Wed, Jun 20, 2018, 4:33 PM Chris Clark <cclark@...> wrote:
***note, if you are a dedicated Cloud Foundry committer, this is identical to a survey we sent out to you in January.  If you completed that survey, you can ignore this***

- Do you work on Cloud Foundry?
- Have you submitted a pull request or an issue to a Cloud Foundry project?
- Have you written, edited or updated cf-docs?
- Have you participated in a discussion that materialized into a project/update?
- Have you helped champion Cloud Foundry at a Meetup, CF Summit, or an industry event?
- Have you shared your enthusiasm and inspired folks to join the Cloud Foundry community?
Answered Yes to any of the above? Then please take this survey and help us measure our community’s diversity.

Thank you!

- The Cloud Foundry Foundation
Quick (2 min) survey for the Cloud Foundry Community!

Chris Clark
 

***note, if you are a dedicated Cloud Foundry committer, this is identical to a survey we sent out to you in January.  If you completed that survey, you can ignore this***

- Do you work on Cloud Foundry?
- Have you submitted a pull request or an issue to a Cloud Foundry project?
- Have you written, edited or updated cf-docs?
- Have you participated in a discussion that materialized into a project/update?
- Have you helped champion Cloud Foundry at a Meetup, CF Summit, or an industry event?
- Have you shared your enthusiasm and inspired folks to join the Cloud Foundry community?
Answered Yes to any of the above? Then please take this survey and help us measure our community’s diversity.

Thank you!

- The Cloud Foundry Foundation
Re: (action requested) Changing CF App Display

Abby Chau
 

Hi all,

We've analyzed the `cf app` survey results; thanks again to those who responded. Here's our findings and actions steps:

Based on your feedback, we have decided to change `cf app` to default to the v3 app endpoint:
  • what this means is that for users on CC API 3.27.0 or higher, the `cf app app-name` display will change in an upcoming CF CLI release 
  • for users on CC API 3.27.0 or lower, you will continue to see the current `cf app app-name` display; you will not see the new v3 display unless you upgrade to CC API 3.27.0 or higher (and you have the latest version of the CF CLI)
Survey Results

Please see the image below for results of the survey. Only 6.3% of respondents said they would strongly object to changing the current `cf app app-name` display to default to the v3 app endpoint. 

Next Steps:
  • the v3 app endpoint treats processes as a first class citizen, and as such we want to display this in the most user-friendly way possible. As such, the CLI team is soliciting feedback on changing the UX design of the `cf app appname` to take advantage of v3 capabilities: Please complete this very short survey if you want to vote on the new UX. Voting ends on Tuesday, June . 26th. 
Feedback

If you have questions or concerns, please contact us on the #cli channel on Cloud Foundry Slack. Alternatively, respond directly to this email.

Please do not hesitate to reach out if you have any feedback or questions. Thanks again. 

Best, 

Abby Chau and the CLI team
CF Product Manager, CF CLI


app_display_results.png
​



On Mon, Jun 11, 2018 at 9:49 AM Abby Chau <achau@...> wrote:
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
Querying across microservices in CF

Pierce Lamb <richard.pierce.lamb@...>
 

I've found that while microservices tend to increase dev productivity by allowing devs to work independently, they also tend lead devs into having independent state across microservices; e.g. each microservice has it's own database

In theory, then, a query across microservices would be challenging. One could encounter data interdependence issues across microservices. Further, querying across microservices using joins and aggregations could require complex application level code to realize.

Does anyone encounter problems with querying across microservices in CF today? And if so how do they solve these problems?
planned end of life for cloudfoundry-incubator/cephfs-bosh-release

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

Hi Folks,

Due to lack of popular demand, we plan to move https://github.com/cloudfoundry-incubator/cephfs-bosh-release into the cloudfoundry-attic org, unhook it from our CI pipelines, and cease further maintenance.  If you have been secretly using this software, please contact us in the next week by replying to this email or finding us on the #persi channel on https://cloudfoundry.slack.com to let us know your use cases.  Unless we’ve heard from someone in the next two weeks, we’ll move it to the attic.

Thanks much,
-Julian
BlockHeads Broker - Proposal for Incubation in the Extensions

Nima
 

Hello all,
 
Following the presentation of the BlockHeads broker at today's CAB call, here comes the proposal for its inclusion as a new CF Extensions project.
 
 
BlockHead is a service broker that integrates with Cloud Foundry / Kubernetes and enables management of blockchain nodes and deployment of smart contracts. You can check our blog post below for more information
 
 
Project Name: BlockHeads Service Broker

Proposed Project Lead: Nima Kaviani (IBM)

Proposed Contributors: Swetha Repakula (IBM), Jonathan Berkhahn (IBM), Morgan Bauer (IBM), Nima Kaviani (IBM)

 
Feel free to contact me in case of any questions / thoughts / feedback.
 
bests,
Nima
Re: cf restart-app-instance and environment variables #cf

Preetam Palwe
 

Thanks Zach for confirmation.

Fine - I think the only way to achieve what I want to achieve is to use B-G deployment. 

Lastly - It will be interesting when rolling update will be supported in cf restart with zero downtime as per your proposal. When will that gets released tentatively?

Thanks!
Re: Buildpack Cache

Stephen Levine
 

The buildpack cache in CF is always per-app and foundation-wide. It can only be erased by deleting the app or dropping all cache artifacts on the platform.

The system buildpacks are cached on the cell, and if you use an offline buildpack with dependencies included, the buildpack will generally not need to download those dependencies. Therefore, they won't get cached in the app's buildpack cache (but other things might still be).


On Tue, Jun 19, 2018 at 11:04 AM Stephan Merker <stephan.merker@...> wrote:
> This means that there are larger system policies about whether it's cached per-cell, per-foundation, etc.

Do you mean with "larger system policies" the usage of online vs. offline buildpacks? Or are there configuration parameters in e.g. the CC  or Diego to configure the caching policy?
In other words: what is the global buildpack artifact caching policy for a standard https://github.com/cloudfoundry/cf-deployment/releases/tag/v1.40.0

Best regards,
Stephan

-----Original Message-----
From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Ben Hale
Sent: Montag, 18. Juni 2018 20:23
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Buildpack Cache

> Different buildpacks use this cache for different things. Ben Hale (CCd) may have more details about how the Java buildpack handles caching. In general, the purpose of the cache is to speed up build time and/or reduce data transfer during staging.

The Java Buildpack treats the Buildpack cache as an opaque directory.  This means that there are larger system policies about whether it's cached per-cell, per-foundation, etc. but from the perspective of the Java Buildpack, there is only a directory that may or may not contain cached artifacts.

All artifacts that the Java Buildpack might download are cached upon retrieval.  So if you are using an online buildpack and download a JVM, we'll only download once per buildpack-cache (again, the system-wide policies are what really govern how often this happens) and store it for future staging.  In addition to the artifact itself, we also store the `Last-Modified` timestamp and the `ETag` if either of these is returned when the artifact is downloaded.  For all subsequent uses of an artifact, the buildpack first attempts a download with `If-Modified-Since` and `If-None-Match`.  If all goes well (i.e. the artifact hasn't changed on the server), a `304 Not Modified` response will be returned and we know that our cached copies are safe for use and they'll be served up to the application without and bytes downloaded.

Cache hits are called out as part of staging output:

```
-----> Java Buildpack v4.12 (offline) | https://github.com/cloudfoundry/java-buildpack.git#5dca820
-----> Downloading Jvmkill Agent 1.12.0_RELEASE from https://java-buildpack.cloudfoundry.org/jvmkill/trusty/x86_64/jvmkill-1.12.0_RELEASE.so (found in cache)
-----> Downloading Open Jdk JRE 1.8.0_172 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_172.tar.gz (found in cache)
       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.1s)
       JVM DNS caching disabled in lieu of BOSH DNS caching
-----> Downloading Open JDK Like Memory Calculator 3.13.0_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-3.13.0_RELEASE.tar.gz (found in cache)
       Loaded Classes: 16818, Threads: 250
-----> Downloading Client Certificate Mapper 1.6.0_RELEASE from https://java-buildpack.cloudfoundry.org/client-certificate-mapper/client-certificate-mapper-1.6.0_RELEASE.jar (found in cache)
-----> Downloading Container Security Provider 1.13.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-security-provider/container-security-provider-1.13.0_RELEASE.jar (found in cache)
-----> Downloading Spring Auto Reconfiguration 2.4.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-2.4.0_RELEASE.jar (found in cache)
```

versus:

```
-----> Java Buildpack 222ce62 | https://github.com/cloudfoundry/java-buildpack.git#222ce62
-----> Downloading Jvmkill Agent 1.14.0_RELEASE from https://java-buildpack.cloudfoundry.org/jvmkill/trusty/x86_64/jvmkill-1.14.0_RELEASE.so (0.0s)
-----> Downloading Open Jdk JRE 1.8.0_172 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_172.tar.gz (0.9s)
       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.4s)
       JVM DNS caching disabled in lieu of BOSH DNS caching
-----> Downloading Open JDK Like Memory Calculator 3.13.0_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-3.13.0_RELEASE.tar.gz (0.0s)
       Loaded Classes: 16818, Threads: 250
-----> Downloading Client Certificate Mapper 1.6.0_RELEASE from https://java-buildpack.cloudfoundry.org/client-certificate-mapper/client-certificate-mapper-1.6.0_RELEASE.jar (0.0s)
-----> Downloading Container Security Provider 1.14.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-security-provider/container-security-provider-1.14.0_RELEASE.jar (0.0s)
-----> Downloading Spring Auto Reconfiguration 2.4.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-2.4.0_RELEASE.jar (0.0s)
```


-Ben Hale
Cloud Foundry Java Experience
Re: cf restart-app-instance and environment variables #cf

Zach Robinson
 

Hey Preetam

There's not any work to get 'cf restart-app-instance` to update env vars and there is not a way to clone an app.

The current canonical method for updating an app's config, is to perform a blue-green deployment https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html

There is also work in flight to implement rolling updates of applications that will allow 'cf restart' to update environment variables for an app based on this proposal https://docs.google.com/document/d/116I_mOWjZcPeIbUvvsh-jAcwpoE_mGPD_SkCel5xXuU/edit#

-Zach
CAPI Project Lead


On Tue, Jun 19, 2018 at 6:54 AM Preetam Palwe <preetam.palwe@...> wrote:
Thanks Dan - It's a reasonable guess!

Following link has some explanation about why it has not worked on Diego - (The documentation of cf restart-app-instance should have this mentioned.)
https://github.com/cloudfoundry/cli/issues/777 

As per above link - Diego team has done some work to propogate env var changes during restart-app-instance. Does anyone here know more about it?
Is there any way to get env vars reflected using cf restart-app-instance or any other means without downtime?

On other hand I also thought about using copy-source but that command require the target app to exist. Can we clone the app?

Appreciate any help on this - Many Thanks !
~Preetam
Re: Buildpack Cache

Stephan Merker
 

This means that there are larger system policies about whether it's cached per-cell, per-foundation, etc.
Do you mean with "larger system policies" the usage of online vs. offline buildpacks? Or are there configuration parameters in e.g. the CC or Diego to configure the caching policy?
In other words: what is the global buildpack artifact caching policy for a standard https://github.com/cloudfoundry/cf-deployment/releases/tag/v1.40.0

Best regards,
Stephan

-----Original Message-----
From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Ben Hale
Sent: Montag, 18. Juni 2018 20:23
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Buildpack Cache

Different buildpacks use this cache for different things. Ben Hale (CCd) may have more details about how the Java buildpack handles caching. In general, the purpose of the cache is to speed up build time and/or reduce data transfer during staging.
The Java Buildpack treats the Buildpack cache as an opaque directory. This means that there are larger system policies about whether it's cached per-cell, per-foundation, etc. but from the perspective of the Java Buildpack, there is only a directory that may or may not contain cached artifacts.

All artifacts that the Java Buildpack might download are cached upon retrieval. So if you are using an online buildpack and download a JVM, we'll only download once per buildpack-cache (again, the system-wide policies are what really govern how often this happens) and store it for future staging. In addition to the artifact itself, we also store the `Last-Modified` timestamp and the `ETag` if either of these is returned when the artifact is downloaded. For all subsequent uses of an artifact, the buildpack first attempts a download with `If-Modified-Since` and `If-None-Match`. If all goes well (i.e. the artifact hasn't changed on the server), a `304 Not Modified` response will be returned and we know that our cached copies are safe for use and they'll be served up to the application without and bytes downloaded.

Cache hits are called out as part of staging output:

```
-----> Java Buildpack v4.12 (offline) | https://github.com/cloudfoundry/java-buildpack.git#5dca820
-----> Downloading Jvmkill Agent 1.12.0_RELEASE from https://java-buildpack.cloudfoundry.org/jvmkill/trusty/x86_64/jvmkill-1.12.0_RELEASE.so (found in cache)
-----> Downloading Open Jdk JRE 1.8.0_172 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_172.tar.gz (found in cache)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.1s)
JVM DNS caching disabled in lieu of BOSH DNS caching
-----> Downloading Open JDK Like Memory Calculator 3.13.0_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-3.13.0_RELEASE.tar.gz (found in cache)
Loaded Classes: 16818, Threads: 250
-----> Downloading Client Certificate Mapper 1.6.0_RELEASE from https://java-buildpack.cloudfoundry.org/client-certificate-mapper/client-certificate-mapper-1.6.0_RELEASE.jar (found in cache)
-----> Downloading Container Security Provider 1.13.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-security-provider/container-security-provider-1.13.0_RELEASE.jar (found in cache)
-----> Downloading Spring Auto Reconfiguration 2.4.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-2.4.0_RELEASE.jar (found in cache)
```

versus:

```
-----> Java Buildpack 222ce62 | https://github.com/cloudfoundry/java-buildpack.git#222ce62
-----> Downloading Jvmkill Agent 1.14.0_RELEASE from https://java-buildpack.cloudfoundry.org/jvmkill/trusty/x86_64/jvmkill-1.14.0_RELEASE.so (0.0s)
-----> Downloading Open Jdk JRE 1.8.0_172 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_172.tar.gz (0.9s)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.4s)
JVM DNS caching disabled in lieu of BOSH DNS caching
-----> Downloading Open JDK Like Memory Calculator 3.13.0_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-3.13.0_RELEASE.tar.gz (0.0s)
Loaded Classes: 16818, Threads: 250
-----> Downloading Client Certificate Mapper 1.6.0_RELEASE from https://java-buildpack.cloudfoundry.org/client-certificate-mapper/client-certificate-mapper-1.6.0_RELEASE.jar (0.0s)
-----> Downloading Container Security Provider 1.14.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-security-provider/container-security-provider-1.14.0_RELEASE.jar (0.0s)
-----> Downloading Spring Auto Reconfiguration 2.4.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-2.4.0_RELEASE.jar (0.0s)
```


-Ben Hale
Cloud Foundry Java Experience
FINAL REMINDER: CAB call for June is Wednesday 06/20 @ 8a PST or 11a EST

Michael Maximilien
 

FYI...

Tomorrow 8AM Pacific or 3PM UTC.

Zoom soon. Best,

dr.max
ibm ☁ 
silicon valley, ca



dr.max
ibm ☁ 
silicon valley, ca


On Jun 13, 2018, at 3:43 PM, Michael Maximilien <maxim@...> wrote:

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,
Re: cf restart-app-instance and environment variables #cf

Preetam Palwe
 

Thanks Dan - It's a reasonable guess!

Following link has some explanation about why it has not worked on Diego - (The documentation of cf restart-app-instance should have this mentioned.)
https://github.com/cloudfoundry/cli/issues/777 

As per above link - Diego team has done some work to propogate env var changes during restart-app-instance. Does anyone here know more about it?
Is there any way to get env vars reflected using cf restart-app-instance or any other means without downtime?

On other hand I also thought about using copy-source but that command require the target app to exist. Can we clone the app?

Appreciate any help on this - Many Thanks !
~Preetam
1341 - 1360 of 9431