Date   

Re: question about token management using cf client using java

Ben Hale <bhale@...>
 

1. is there way to know about token expiration time using cf java client?
I'm using PasswordGrantTokenProvider
Configuring the `cf-java-client.token` logger to `DEBUG` will give you detailed information about the negotiated tokens.

```
cloudfoundry-client.request POST https://login.peach.springapps.io:443/oauth/token
cloudfoundry-client.response 200 https://login.peach.springapps.io:443/oauth/token (460 ms)
cloudfoundry-client.token Refresh Token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0xIiwidHlwIjo...
cloudfoundry-client.token Refresh Token Issued At: 2017-07-20T16:27:12 UTC
cloudfoundry-client.token Refresh Token Expires At: 2017-08-03T16:27:12 UTC
cloudfoundry-client.token Access Token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0xIiwidHlwIjoi...
cloudfoundry-client.token Access Token Issued At: 2017-07-20T16:27:12 UTC
cloudfoundry-client.token Access Token Expires At: 2017-07-20T18:27:12 UTC
```


2. sometimes there is 401 error when i restart the nozzle program. is there way to prevent it? how can i do?
The 401 is an expected part of the HTTP authentication handshake. The first call without a token returns a 401 telling the caller that a token must be presented. At this point, the client goes off to negotiate a token and re-makes the same call with the proper token, which is then accepted. Eagerly sending credentials without first being prompted by a 401 is considered poor security practice.


3. suppose token expiration time is ten minutes. during receiving data using subscribe method
is token expiration time extended automatically? or should refresh token every ten minute?
Tokens are only used during the initiation of a connection. So if a connection lives for 1000 hours, the token is only needed at the beginning of the request, not the entire duration. If the connection drops and is restarted, the standard token negotiation handshake takes place. If the token has expired (as indicated by a 401), then the token is refreshed and the request is automatically retried.


-Ben Hale
Cloud Foundry Java Experience


Re: Reg- CCDB and UAADB model

Filip Hanik
 

UAA DB is nothing special. We like to keep it simple.
We don't use foreign keys to simplify migration scripts.
We support four different database types, HSQLDB, MySQL(MariaDB),
PostgreSQL and SQL Server.

We made a choice to store some data in JSON format in text or clob columns.
We do this for data we don't want to query and index.


The UAADB is really a very small database, there isn't much to it. The one
thing we are considering reworking is data that is frequently deleted based
on time expiration. MySQL performance is really bad for large transactional
deletes and it can cause hiccups and consume both locks and CPU.

We use Flyway for database migrations between versions.

Filip


On Thu, Jul 20, 2017 at 8:49 AM, Gowrisankar M <gowrisankarbeece(a)gmail.com>
wrote:

Hi Colleages,

I am trying to understand CCDB/UAADB design . Can somebody share some link
for the db design of uaa/cc

BRs, Gowrisankar


Reg- CCDB and UAADB model

Gowrisankar M
 

Hi Colleages,

I am trying to understand CCDB/UAADB design . Can somebody share some link
for the db design of uaa/cc

BRs, Gowrisankar


Re: CF space application sharing

Daniel Mikusa
 


Aren't space-scoped ASGs shared across all apps deployed in the same
space?
Yes


So if one app in a space has network access to a service, any other app in
the same space would be able to reach it, at least on the network level,
even if the other app isn't actually bound to the service?
Yes. Network access and service binding are two completely different
things. Just because a component has network access doesn't mean it will
have the IP & credentials to access a service. In the same way, an app
could have a service bound but not have network access.

As long as your services require authentication (which they should), IMHO
the situation you're describing doesn't seem to be a security issue. That
said, security happens in layers so if you can block at the network & not
provide credentials, that's better than just one of those.

tl;dr - if you're using ASGs to protect resources, be careful what apps you
put into an org and space.

Hope that helps!

Dan




On Tue, Jul 18, 2017 at 4:35 PM, Julz Friedman <julz.friedman(a)gmail.com>
wrote:

Garden does have (currently not very well documented) support for setting
hard cpu maximums as well as the fair share limits described above. This is
off by default but can be enabled via the 'garden.cpu_quota_per_share_in_us'
bosh property (more details at https://github.com/cloudfoundr
y/garden-runc-release/releases/tag/v1.3.0). This is a first pass at
solving this so we're very interested in feedback for it and any use cases
it still doesn't solve.


On Tue, 18 Jul 2017 at 14:07, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

John,

Further down the stack, Garden uses CPU cgroups to achieve CPU
resource management. CPU intensive applications can not affect other
applications in the same space, org or cell.

In the case of apps on the same cell, I would say that one CPU intensive
application can affect other applications on the same cell, but it cannot
completely starve out the other applications on the cell.

Each application on CF is given a number of CPU shares (I believe this
is proportional to the memory limit for the application, i.e. more memory,
more CPU shares) and, while this might be an over simplification, the
shares essentially guarantee you'll receive a minimum amount of CPU time.
They don't prevent you from getting more CPU time, but it prevents other
processes from starving out a process.

Ex 1: You have one Cell with two apps running on it. The apps have the
same memory limit, thus the same CPU shares.
- If App A is doing nothing, App B can make *full* use of the CPUs
- If App B is doing nothing, App A can make *full* use of the CPUs
- if App A & App B are running very CPU intensive workloads, they
should each roughly get half of the CPU resources.

It is technically possible for App A to affect App B's CPU time because
both are guaranteed their shares, however, it's not possible for App A to
starve App B and prevent it from getting any CPU time. The cgroups
configuration guarantees this an app a minimum amount of time.

Where you have to be careful is when you have applications of varying
memory limits (and thus varying CPU shares). The example above is simple
because they both have the same limits. If you have two applications with
wildly different memory limits, you might see issues.

Ex 2: You have one Cell with two apps running on it. App A is very
small and has a 64M memory limit, App B is very large and has a 8G memory
limit.
- Again, if App A is doing nothing, App B can make *full* use of the
CPUs
- Again, if App B is doing nothing, App A can make *full* use of the
CPUs
- If App A & App B are running very CPU intensive workloads, they will
*not* receive equal time on the CPU. App A will basically get 1/128th the
CPU time of App B because of the way CF configures the shares.

Despite this being a fair (i.e. App A is getting what it asked), App A
will undoubtedly be perceived as running slow by its users since it's
getting significantly less access to the CPU while App B is running its
intensive workload. Again, App B cannot completely starve App A, but
in this case because of the CPU shares, it can definitely impact App A a
lot more.

If you find yourself in this situation, you can try restarting your app,
which will perhaps cause it to be run on a different Cell where CPU is not
in contention or you can bump up your memory limit, which will give you
more CPU shares.

Hope that helps!

Dan

PS. George please feel free to correct me if I've misstated anything.



On Tue, Jul 18, 2017 at 5:26 AM, John jerrby <jjerrby(a)gmail.com> wrote:

Hi George,

Thanks!
1. So who "pay" :) when the application in CPU intensive ? if not
other app in the cell ...
2. if there any documentation which can shad some additional lights on
this topic it it will be great if you can share it...

Thanks a lot and have a nice day,

John


Manage Cloud foundry Org/space

Jenny Hilton
 

HI,

We have an old org for our which exceed quota after several month of teams usage, then we start to delete services manually which not used and this is not a simple job to run after quata , not used service and very hard to manage it...
We have a new Org in CF for Our teams ( we use native CF- OS) .

Now we have a much big Quota, (memory, disk,routes etc) but if we do not do some cleanup job a while the quota will exceed after few month again...
There is some service/ capability in native CF to do some cleanup or shout down automatically for services/app which not used/called after some defined time (like after 2-3 month ) maybe stop them or even delete them .. king of "Watch Dog" ?

Lets say I've the org admin rights ...

Thanks!


Re: CF space application sharing

John jerrby
 

Hi Lior,

This part is very intersting, i'll hope we will get an answer that explain the IP issue since sounds like some security risk ...


Regards,
John


Re: CF space application sharing

John jerrby
 

HI Daniel,

Thanks for this answer, I learned a lot from it!

Have a nice day!
John


question about token management using cf client using java

SOHN SEOROCK
 

I'm testing cf nozzle using cf client java and have three questions about token management

1. is there way to know about token expiration time using cf java client?
I'm using PasswordGrantTokenProvider

2. sometimes there is 401 error when i restart the nozzle program. is there way to prevent it? how can i do?

3. suppose token expiration time is ten minutes. during receiving data using subscribe method
is token expiration time extended automatically? or should refresh token every ten minute?

thanks and bless you.


Information about 3 CAPI CVEs

Molly Crowther
 

Hello all -

Please see below for more information on 3 CAPI CVEs made public today.


Please reply if you have any questions.


Thanks,

Molly Crowther

CFF Security Team

CVE-2017-8033: Cloud Controller API filesystem traversal vulnerability

HIGH

Upgrade instructions: https://www.cloudfoundry.org/cve-2017-8033/

How to tell if your CF installation is affected

At this time we believe that all CF installations are vulnerable.

How to tell if your installation has been exploited

We do not have concrete exploit information at this time.

Immediate Mitigation

-

Turn off the App Bits Upload feature flag. NOTE: this will prevent all
CF Pushes but will not cause application downtime for running apps.

------------------------------


CVE-2017-8035: Cloud Controller API access to CC VM contents

CRITICAL

Upgrade instructions: https://www.cloudfoundry.org/cve-2017-8035/

How to tell if your CF installation is affected

At this time we believe that all CF installations using the versions of the
Cloud Controller API stated in the notice are vulnerable.

How to tell if your installation has been exploited

It is believed that this vulnerability has existed since cf-release 245
(October 2016). It is possible to search logs to determine if you have been
exploited.

Search logs for requests that include any of “droplet_path”,
“application_path”, “buildpack_path”, and “bits_path”. If any log lines
contain this text and they are being used in the query string of an http
request, then that is an indication of an exploit attempt.

Example log text containing one of the above search terms as a query
parameter: “PUT
/v2/apps/033c1ca1-c3bd-40d5-92f8-12c711ead64b/droplet/upload?droplet_path=/some/path”

Immediate Mitigation

-

It is possible to mitigate this issue prior to upgrade by turning off
developer access to the CC API.

------------------------------


CVE-2017-8036: Cloud Controller API regression

CRITICAL

Upgrade instructions: https://www.cloudfoundry.org/cve-2017-8036/

How to tell if your CF installation is affected

This issue only affects installations using CAPI-release v1.33.0.

How to tell if your installation has been exploited

We do not have concrete exploit information at this time.

Immediate Mitigation

-

Turn off the App Bits Upload feature flag. NOTE: this will prevent all
CF Pushes but will not cause application downtime for running apps.


Re: Application Metric Forwarding and Developer Segmented Firehose

Maxwell Eshleman
 

These sound like great ideas! What is the difference between the app metric
forwarding mentioned here and what Scott's team is doing?

-Max

On Wed, Jul 19, 2017 at 2:35 PM Adam Hevenor <ahevenor(a)pivotal.io> wrote:

Hi Everyone -

The Loggregator team has been discussing two related features that surface
more capabilities to App Developers. There are two separate concepts being
proposed here. The first is the ability for developers to forward metrics
into the firehose [1]. This expands abilities for developers to inspect
custom aspects of their application and build automation on top of existing
standards and tooling. The second concept is for developers to have access
to a firehose segmented to their org/space[2]. This builds further on
existing tooling, but exposes the tooling to development teams at a scope
level they have access to on the platform. There is an intentional ordering
to these separate but related proposals.

I appreciate your feedback and comments.

Thanks
Adam

[1] -
https://docs.google.com/document/d/1hjMO3plNBDwtqCgVIYsayhCcl0k-H0Hzvaaam4SSkto/edit
[2] -
https://docs.google.com/document/d/1z5aVaUn0J3sG3q5tGB1viDxAF70HZ1BYnF9vUe-c0j4/edit


Application Metric Forwarding and Developer Segmented Firehose

Adam Hevenor
 

Hi Everyone -

The Loggregator team has been discussing two related features that surface more capabilities to App Developers. There are two separate concepts being proposed here. The first is the ability for developers to forward metrics into the firehose [1]. This expands abilities for developers to inspect custom aspects of their application and build automation on top of existing standards and tooling. The second concept is for developers to have access to a firehose segmented to their org/space[2]. This builds further on existing tooling, but exposes the tooling to development teams at a scope level they have access to on the platform. There is an intentional ordering to these separate but related proposals.

I appreciate your feedback and comments.

Thanks
Adam

[1] - https://docs.google.com/document/d/1hjMO3plNBDwtqCgVIYsayhCcl0k-H0Hzvaaam4SSkto/edit
[2] - https://docs.google.com/document/d/1z5aVaUn0J3sG3q5tGB1viDxAF70HZ1BYnF9vUe-c0j4/edit


Re: Increasing Routing availability in the event of failure with route registration

Shannon Coen
 

Hi Mike,

Yes, exactly the same as the current behavior when the Gorouter can't
establish a TCP connection. We currently reject the request after three
failed attempts.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 18, 2017 at 4:38 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

This sounds like a great solution to a very old nagging problem. I'm
excited to see this issue moving forward. I assume that if the mTLS
handshake fails then the router will try the next instance in the table as
if the TCP connection had failed?

Mike

On Tue, Jul 18, 2017 at 5:25 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

After weeks of exploration by the Routing, Networking, and Diego teams, we
have a solution in mind and will begin implementation shortly.

TL;DR
We plan to install a proxy in every container to terminate mTLS for
requests
from Gorouter, enabling validation of application identity and
optimization
for availability over consistency. The solution will be transparent to
application developers.

Our proposal has been updated with details on this solution, and we
welcome
your comments:
https://docs.google.com/document/d/1zkPVGNnBX18rWdOpinIEtRxt
e3kwpVhIyS9_WM3ITqM/edit?usp=sharing





--
View this message in context: http://cf-dev.70369.x6.nabble.
com/cf-dev-Increasing-Routing-availability-in-the-event-of-f
ailure-with-route-registration-tp6703p7220.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Increasing Routing availability in the event of failure with route registration

Mike Youngstrom
 

This sounds like a great solution to a very old nagging problem. I'm
excited to see this issue moving forward. I assume that if the mTLS
handshake fails then the router will try the next instance in the table as
if the TCP connection had failed?

Mike

On Tue, Jul 18, 2017 at 5:25 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

After weeks of exploration by the Routing, Networking, and Diego teams, we
have a solution in mind and will begin implementation shortly.

TL;DR
We plan to install a proxy in every container to terminate mTLS for
requests
from Gorouter, enabling validation of application identity and optimization
for availability over consistency. The solution will be transparent to
application developers.

Our proposal has been updated with details on this solution, and we welcome
your comments:
https://docs.google.com/document/d/1zkPVGNnBX18rWdOpinIEtRxte3kwp
VhIyS9_WM3ITqM/edit?usp=sharing





--
View this message in context: http://cf-dev.70369.x6.nabble.
com/cf-dev-Increasing-Routing-availability-in-the-event-of-
failure-with-route-registration-tp6703p7220.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Increasing Routing availability in the event of failure with route registration

Shannon Coen
 

After weeks of exploration by the Routing, Networking, and Diego teams, we
have a solution in mind and will begin implementation shortly.

TL;DR
We plan to install a proxy in every container to terminate mTLS for requests
from Gorouter, enabling validation of application identity and optimization
for availability over consistency. The solution will be transparent to
application developers.

Our proposal has been updated with details on this solution, and we welcome
your comments:
https://docs.google.com/document/d/1zkPVGNnBX18rWdOpinIEtRxte3kwpVhIyS9_WM3ITqM/edit?usp=sharing





--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Increasing-Routing-availability-in-the-event-of-failure-with-route-registration-tp6703p7220.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: CF space application sharing

Lior Okman
 

Hi,

Aren't space-scoped ASGs shared across all apps deployed in the same space?
So if one app in a space has network access to a service, any other app in
the same space would be able to reach it, at least on the network level,
even if the other app isn't actually bound to the service?


--
Regards,
Lior

On Tue, Jul 18, 2017 at 4:35 PM, Julz Friedman <julz.friedman(a)gmail.com>
wrote:

Garden does have (currently not very well documented) support for setting
hard cpu maximums as well as the fair share limits described above. This is
off by default but can be enabled via the 'garden.cpu_quota_per_share_in_us'
bosh property (more details at https://github.com/
cloudfoundry/garden-runc-release/releases/tag/v1.3.0). This is a first
pass at solving this so we're very interested in feedback for it and any
use cases it still doesn't solve.


On Tue, 18 Jul 2017 at 14:07, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

John,

Further down the stack, Garden uses CPU cgroups to achieve CPU resource
management. CPU intensive applications can not affect other applications in
the same space, org or cell.

In the case of apps on the same cell, I would say that one CPU intensive
application can affect other applications on the same cell, but it cannot
completely starve out the other applications on the cell.

Each application on CF is given a number of CPU shares (I believe this is
proportional to the memory limit for the application, i.e. more memory,
more CPU shares) and, while this might be an over simplification, the
shares essentially guarantee you'll receive a minimum amount of CPU time.
They don't prevent you from getting more CPU time, but it prevents other
processes from starving out a process.

Ex 1: You have one Cell with two apps running on it. The apps have the
same memory limit, thus the same CPU shares.
- If App A is doing nothing, App B can make *full* use of the CPUs
- If App B is doing nothing, App A can make *full* use of the CPUs
- if App A & App B are running very CPU intensive workloads, they should
each roughly get half of the CPU resources.

It is technically possible for App A to affect App B's CPU time because
both are guaranteed their shares, however, it's not possible for App A to
starve App B and prevent it from getting any CPU time. The cgroups
configuration guarantees this an app a minimum amount of time.

Where you have to be careful is when you have applications of varying
memory limits (and thus varying CPU shares). The example above is simple
because they both have the same limits. If you have two applications with
wildly different memory limits, you might see issues.

Ex 2: You have one Cell with two apps running on it. App A is very small
and has a 64M memory limit, App B is very large and has a 8G memory limit.
- Again, if App A is doing nothing, App B can make *full* use of the
CPUs
- Again, if App B is doing nothing, App A can make *full* use of the
CPUs
- If App A & App B are running very CPU intensive workloads, they will
*not* receive equal time on the CPU. App A will basically get 1/128th the
CPU time of App B because of the way CF configures the shares.

Despite this being a fair (i.e. App A is getting what it asked), App A
will undoubtedly be perceived as running slow by its users since it's
getting significantly less access to the CPU while App B is running its
intensive workload. Again, App B cannot completely starve App A, but in
this case because of the CPU shares, it can definitely impact App A a lot
more.

If you find yourself in this situation, you can try restarting your app,
which will perhaps cause it to be run on a different Cell where CPU is not
in contention or you can bump up your memory limit, which will give you
more CPU shares.

Hope that helps!

Dan

PS. George please feel free to correct me if I've misstated anything.



On Tue, Jul 18, 2017 at 5:26 AM, John jerrby <jjerrby(a)gmail.com> wrote:

Hi George,

Thanks!
1. So who "pay" :) when the application in CPU intensive ? if not
other app in the cell ...
2. if there any documentation which can shad some additional lights on
this topic it it will be great if you can share it...

Thanks a lot and have a nice day,

John


Re: CF CAB call for July 2017 is next Wednesday, July 19th @ 8a PDT [15:00 UTC]

Michael Maximilien
 

Final reminder... see below. Zoom with us tomorrow at 8a PDT.
 
Best,

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org
 
 

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: cf-dev@...
Cc:
Subject: CF CAB call for July 2017 is next Wednesday, July 19th @ 8a PDT [15:00 UTC]
Date: Wed, Jul 12, 2017 2:35 PM
 
Hi, all,
 
Quick reminder of the CAB call for July is next Wednesday, July 19th @ 8a PDT. All info in link [1].
 
Remember, no more status update but rather discussions, so come ready with your questions. Also we will have David Sabeti of Pivotal giving an update on cf-deployment [2]. 
 
Finally, I am looking for one more 15 mins presentation. Please contact me replying here or on the slack.cloudfoundry.org #CAB channel if you have suggestions and to browse previous and future discussions.
 
Talk to you all next week. I'll send one more reminder on this list next week.
 
Best,
 
dr.max
 
ibm cloud labs 
sillicon valley, ca
usa 
 
Sent from my iPhone
 
 
 


Re: CF space application sharing

Julz Friedman
 

Garden does have (currently not very well documented) support for setting
hard cpu maximums as well as the fair share limits described above. This is
off by default but can be enabled via the
'garden.cpu_quota_per_share_in_us' bosh property (more details at
https://github.com/cloudfoundry/garden-runc-release/releases/tag/v1.3.0).
This is a first pass at solving this so we're very interested in feedback
for it and any use cases it still doesn't solve.

On Tue, 18 Jul 2017 at 14:07, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

John,

Further down the stack, Garden uses CPU cgroups to achieve CPU resource
management. CPU intensive applications can not affect other applications in
the same space, org or cell.

In the case of apps on the same cell, I would say that one CPU intensive
application can affect other applications on the same cell, but it cannot
completely starve out the other applications on the cell.

Each application on CF is given a number of CPU shares (I believe this is
proportional to the memory limit for the application, i.e. more memory,
more CPU shares) and, while this might be an over simplification, the
shares essentially guarantee you'll receive a minimum amount of CPU time.
They don't prevent you from getting more CPU time, but it prevents other
processes from starving out a process.

Ex 1: You have one Cell with two apps running on it. The apps have the
same memory limit, thus the same CPU shares.
- If App A is doing nothing, App B can make *full* use of the CPUs
- If App B is doing nothing, App A can make *full* use of the CPUs
- if App A & App B are running very CPU intensive workloads, they should
each roughly get half of the CPU resources.

It is technically possible for App A to affect App B's CPU time because
both are guaranteed their shares, however, it's not possible for App A to
starve App B and prevent it from getting any CPU time. The cgroups
configuration guarantees this an app a minimum amount of time.

Where you have to be careful is when you have applications of varying
memory limits (and thus varying CPU shares). The example above is simple
because they both have the same limits. If you have two applications with
wildly different memory limits, you might see issues.

Ex 2: You have one Cell with two apps running on it. App A is very small
and has a 64M memory limit, App B is very large and has a 8G memory limit.
- Again, if App A is doing nothing, App B can make *full* use of the CPUs
- Again, if App B is doing nothing, App A can make *full* use of the CPUs
- If App A & App B are running very CPU intensive workloads, they will
*not* receive equal time on the CPU. App A will basically get 1/128th the
CPU time of App B because of the way CF configures the shares.

Despite this being a fair (i.e. App A is getting what it asked), App A
will undoubtedly be perceived as running slow by its users since it's
getting significantly less access to the CPU while App B is running its
intensive workload. Again, App B cannot completely starve App A, but in
this case because of the CPU shares, it can definitely impact App A a lot
more.

If you find yourself in this situation, you can try restarting your app,
which will perhaps cause it to be run on a different Cell where CPU is not
in contention or you can bump up your memory limit, which will give you
more CPU shares.

Hope that helps!

Dan

PS. George please feel free to correct me if I've misstated anything.



On Tue, Jul 18, 2017 at 5:26 AM, John jerrby <jjerrby(a)gmail.com> wrote:

Hi George,

Thanks!
1. So who "pay" :) when the application in CPU intensive ? if not other
app in the cell ...
2. if there any documentation which can shad some additional lights on
this topic it it will be great if you can share it...

Thanks a lot and have a nice day,

John


Re: CF space application sharing

Daniel Mikusa
 

John,

Further down the stack, Garden uses CPU cgroups to achieve CPU resource
management. CPU intensive applications can not affect other applications in
the same space, org or cell.

In the case of apps on the same cell, I would say that one CPU intensive
application can affect other applications on the same cell, but it cannot
completely starve out the other applications on the cell.

Each application on CF is given a number of CPU shares (I believe this is
proportional to the memory limit for the application, i.e. more memory,
more CPU shares) and, while this might be an over simplification, the
shares essentially guarantee you'll receive a minimum amount of CPU time.
They don't prevent you from getting more CPU time, but it prevents other
processes from starving out a process.

Ex 1: You have one Cell with two apps running on it. The apps have the
same memory limit, thus the same CPU shares.
- If App A is doing nothing, App B can make *full* use of the CPUs
- If App B is doing nothing, App A can make *full* use of the CPUs
- if App A & App B are running very CPU intensive workloads, they should
each roughly get half of the CPU resources.

It is technically possible for App A to affect App B's CPU time because
both are guaranteed their shares, however, it's not possible for App A to
starve App B and prevent it from getting any CPU time. The cgroups
configuration guarantees this an app a minimum amount of time.

Where you have to be careful is when you have applications of varying
memory limits (and thus varying CPU shares). The example above is simple
because they both have the same limits. If you have two applications with
wildly different memory limits, you might see issues.

Ex 2: You have one Cell with two apps running on it. App A is very small
and has a 64M memory limit, App B is very large and has a 8G memory limit.
- Again, if App A is doing nothing, App B can make *full* use of the CPUs
- Again, if App B is doing nothing, App A can make *full* use of the CPUs
- If App A & App B are running very CPU intensive workloads, they will
*not* receive equal time on the CPU. App A will basically get 1/128th the
CPU time of App B because of the way CF configures the shares.

Despite this being a fair (i.e. App A is getting what it asked), App A will
undoubtedly be perceived as running slow by its users since it's getting
significantly less access to the CPU while App B is running its intensive
workload. Again, App B cannot completely starve App A, but in this
case because of the CPU shares, it can definitely impact App A a lot more.

If you find yourself in this situation, you can try restarting your app,
which will perhaps cause it to be run on a different Cell where CPU is not
in contention or you can bump up your memory limit, which will give you
more CPU shares.

Hope that helps!

Dan

PS. George please feel free to correct me if I've misstated anything.



On Tue, Jul 18, 2017 at 5:26 AM, John jerrby <jjerrby(a)gmail.com> wrote:

Hi George,

Thanks!
1. So who "pay" :) when the application in CPU intensive ? if not other
app in the cell ...
2. if there any documentation which can shad some additional lights on
this topic it it will be great if you can share it...

Thanks a lot and have a nice day,

John


Re: Mailing lists and links to archived messages

Chip Childers <cchilders@...>
 

I'll ask. Thanks.

On Tue, Jul 18, 2017 at 2:56 AM Stanislav German-Evtushenko <
s.germanevtushenko(a)rakuten.com> wrote:

Hi,

Can anybody reach mailing list server admin and ask them to fix the
hostname so that "Archived-At" has lists.cloudfoundry.org instead of
localhost and (if possible) to add the same link to the email body?

Best regards,
Stanislav
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: EOL for Diego-Enabler cf CLI plugin 31 July 2017

Ronak Banka
 

Hi Dies,

Due to some internal decisions, we are still in migration phase.

Will it be possible to postpone the deletion of the plugin from community
plugin repo?

Thanks
Ronak



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-EOL-for-Diego-Enabler-cf-CLI-plugin-31-July-2017-tp7209p7214.html
Sent from the CF Dev mailing list archive at Nabble.com.

2321 - 2340 of 9389