> 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

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

Thanks for the explanation.

 

I have one more question: Is there any caching for the buildpack itself?

The CC coding looks like the buildpack is downloaded for each staging operation (either as zip file or via git clone).

Is there a difference between system buildpacks and custom buildpacks when it comes to download and caching?

 

Best regards,

Stephan

 

From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Stephen Levine
Sent: Donnerstag, 14. Juni 2018 22:04
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>; Ben Hale <bhale@...>
Subject: Re: [cf-dev] Buildpack Cache

 

Hi Stephan,

 

The buildpack cache (aka "app cache," or "build artifacts cache") is a per-app cache that is stored as a tarball in the blob store and recovered when an existing app is restaged (regardless of app code or buildpack changes).

 

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.

 

Usage of the cache is documented here: https://docs.cloudfoundry.org/buildpacks/understand-buildpacks.html

 

-Stephen

 

 

On Thu, Jun 14, 2018 at 10:31 AM Stephan Merker <stephan.merker@...> wrote:

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

 

Hi Matt,

Just wanted to check back if there is something we can help to make this feature GA?

Did you get any further feedback within the last month?

Best regards,

Lukas

Am Mi., 16. Mai 2018 um 13:15 Uhr schrieb Matt McNeeney <mmcneeney@...>:

Hey Lukas,

Very pleased to hear the feature is working as you expected! As things stand, the feature should be released as GA within the next couple of months, and so far we haven't received any feedback that has made us rethink about how the feature works today.

Thanks,

Matt

On Wed, May 16, 2018 at 11:38 AM Lukas Lehmann <lukas92lehmann@...> wrote:

Hi Matt,

We have tested this feature in Swisscom and it works great and as expected. 

Is there a timeline on your side to release this future finally?

Is there something we can further help you with testing or so?

Best regards,

Lukas

2018-03-27 16:05 GMT+02:00 Matt McNeeney <mmcneeney@...>:

I'm pleased to announce that the ability to share service instances across orgs and spaces has been released!

In order to use this feature, please make sure you are running:

• CF Deployment >= v1.9.0
• CF CLI >= v6.35.1

To share a service instance from one space into another, you just need to run cf share-service SERVICE-INSTANCE -s SPACE

Note that this needs to be enabled by both admins (via a feature-flag) and by the author of the service you want to share.

For more information, please check out the following docs:

• Sharing Service Instances (developers)
• Enabling Service Instance Sharing (service authors)

I'd encourage you all to try this out with a supportive service broker (like this example broker). This feature is currently experimental (beta), so feedback at this time would be extremely valuable.

Best wishes,

The CF Services API team

--

Freundliche Grüsse

 

Lukas Lehmann

 

--

Freundliche Grüsse

 

Lukas Lehmann

 

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

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

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