Date   

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@lists.cloudfoundry.org [mailto:cf-dev@lists.cloudfoundry.org] On Behalf Of Ben Hale
Sent: Montag, 18. Juni 2018 20:23
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@lists.cloudfoundry.org>
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


UAA and SQL injections #cf

Enrique Cano
 

Hi

Has CF UAA code been developed in a way that is protected against potential SQL injections?

Thanks

Enrique


Re: cf restart-app-instance and environment variables #cf

Daniel Mikusa
 



On Tue, Jun 19, 2018 at 12:45 AM, Preetam Palwe <preetam.palwe@...> wrote:

[Edited Message Follows]
[Reason: extra observation and information]

Hello everyone !

I am observing that the new environment variable set to my application using cf set-env is not getting reflected in the container even after cf restart-app-instance is done. Why is it so?

To give a brief context - I have an Java Spring Boot application which is deployed on PCF. I am setting a new env var using cf set-env. In order to reflect the env var in the application I understand that application restart is essential. (I don't need restage as my env var is not getting used in the buildpack.)
But cf restart as per documentation create downtime. Hence I decided to scale my application to minimum 2 instances and then used cf restart-app-instance one by one for the 2 instances. (It's kind of rolling restart)
I was expecting that the env var will get reflected in each instance but it has not happened. I checked this by both means - printing env vars in my application and doing cf ssh -i on each instance. In both cases I was not able to see the new env var.

What could be wrong or am I missing something here?

Versions I am using are 
CLI version 6.32.0+0191c33d9.2017-09-26
PCF version 1.12
Note - I did observed that cf restart reflected the env variables as expected. (only cf restart-app-instance failed to do that - why?)

I'd guess that it's because you don't ever want to have an inconsistent state across your app instances.  If you were able to use `cf restart-app-instance` and see this change then you'd have one app instance which could see it and possibly other app instances that cannot (at least until they're all restarted this way).  Conversely, `cf restart` will restart all of your app instances so they'll all see the new variable and everything will be consistent.  Inconsistency is bad, the platform is trying to protect you.

Dan

 

Appreciate any help on this - Many Thanks !
~Preetam



CF+K8S SIG Call Schedule Change

Chip Childers <cchilders@...>
 

Rescheduling the call from this week to next week due to travel in Asia.

The team working on the "containerize CFAR control plane" effort would like to demo their efforts during the next call.


See you there!
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


cf restart-app-instance and environment variables #cf

Preetam Palwe
 
Edited

Hello everyone !

I am observing that the new environment variable set to my application using cf set-env is not getting reflected in the container even after cf restart-app-instance is done. Why is it so?

To give a brief context - I have an Java Spring Boot application which is deployed on PCF. I am setting a new env var using cf set-env. In order to reflect the env var in the application I understand that application restart is essential. (I don't need restage as my env var is not getting used in the buildpack.)
But cf restart as per documentation create downtime. Hence I decided to scale my application to minimum 2 instances and then used cf restart-app-instance one by one for the 2 instances. (It's kind of rolling restart)
I was expecting that the env var will get reflected in each instance but it has not happened. I checked this by both means - printing env vars in my application and doing cf ssh -i on each instance. In both cases I was not able to see the new env var.

What could be wrong or am I missing something here?

Versions I am using are 
CLI version 6.32.0+0191c33d9.2017-09-26
PCF version 1.12
Note - I did observed that cf restart reflected the env variables as expected. (only cf restart-app-instance failed to do that - why?)

Appreciate any help on this - Many Thanks !
~Preetam


Re: Buildpack Cache

Ben Hale <bhale@...>
 

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: Buildpack Cache

Stephen Levine
 

The system buildpacks are cached on the cell and bind mounted read-only into each staging container. Buildpack URLs (to a git repo or a zip file) are downloaded every time staging occurs.


On Mon, Jun 18, 2018 at 12:50 PM Stephan Merker <stephan.merker@...> wrote:

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.

 

 

-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

 


Re: Buildpack Cache

Stephan Merker
 

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.

 

 

-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

 


Re: Feedback on service instance sharing (experimental)

Lukas Lehmann
 

Great news, thans a lot for the update Matt!

Am Mo., 18. Juni 2018 um 12:22 Uhr schrieb Matt McNeeney <mmcneeney@...>:

Hey Lukas,

Thanks for checking in! We have had further feedback from users who have been trying out this feature and so far of the feedback has been very positive. Given that, we are likely to look into what we need to do to make this feature GA in the next few weeks. You can track this story to keep updated!

Matt


On Mon, Jun 18, 2018 at 9:43 AM Lukas Lehmann <lukas92lehmann@...> wrote:
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:
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:

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
 



--
Freundliche Grüsse
 
Lukas Lehmann
 


Re: Feedback on service instance sharing (experimental)

Matt McNeeney
 

Hey Lukas,

Thanks for checking in! We have had further feedback from users who have been trying out this feature and so far of the feedback has been very positive. Given that, we are likely to look into what we need to do to make this feature GA in the next few weeks. You can track this story to keep updated!

Matt


On Mon, Jun 18, 2018 at 9:43 AM Lukas Lehmann <lukas92lehmann@...> wrote:
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:
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:

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
 


Re: Feedback on service instance sharing (experimental)

Lukas Lehmann
 

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:
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:

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
 


Re: (action requested) Changing CF App Display

Abby Chau
 

Hi all,

The CF CLI app display feedback survey will close today; if you haven't had a chance to take the short survey, we would appreciate your feedback. 

Thanks!

Best,

Abby


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




Cloud Foundry Java Client 2.x EOL

Paul Harris
 

Hi All,

We are planning to end support for version 2.x of the Cloud Foundry Java Client on December 31st, 2018. Updates will continue until then, but we recommend all users upgrade [0] to 3.x early. The 3.x line currently contains all the same functionality as the 2.x line, but benefits from more up-to-date dependencies.

Cheers, Paul


Calling Cloud Foundry Meetup Organizers

Swarna Podila
 

If you're a Cloud Foundry meetup organizer (or a frequent speaker at Cloud Foundry meetups), can you please connect with me directly via email or slack? 

Thank you,
-- ​Swarna Podila
​Senior
 Director
​, Community​
 | Cloud Foundry Foundation
​spodila
@cloudfoundry.org
@
​skpodila​


Re: Buildpack Cache

Stephen Levine
 

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.


-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

 

1301 - 1320 of 9377