Date   

Question about `cf scale`

Marco Nicosia
 

Good morning from wet SF,

I sat down and noticed something odd in last night's scrollback. This
happens to be PWS (cf 228, diego 0.1446.0, stemcell 3147) but it's a
general CF question:

$ cf app clickpoint
[...]
state since cpu memory disk
details
#0 running 2016-01-19 07:21:10 PM 0.0% 78.9M of 128M 50.8M of 1G

$ cf scale clickpoint -i 5
Scaling app clickpoint in org moragasystems / space development...
OK


$ cf app clickpoint
[...]
state since cpu memory disk
details
#0 running 2016-01-21 03:57:48 PM 0.0% 37.4M of 128M 24.2M of 1G
#1 running 2016-01-21 03:57:48 PM 0.0% 0 of 128M 0 of 1G
#2 running 2016-01-21 03:57:48 PM 0.0% 37.4M of 128M 24.2M of 1G
#3 running 2016-01-21 03:57:49 PM 0.0% 39.3M of 128M 24.2M of 1G
#4 running 2016-01-21 03:57:48 PM 0.0% 0 of 128M 0 of 1G

Hey. What happened to my container running since the 19th? It's not a
serious issue, but it seems like adding instances shouldn't disturb running
instances?

I looked at https://docs.cloudfoundry.org/devguide/deploy-apps/cf-scale.html
but I didn't see what the expected behavior should be.

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.


Problem with Deigo Docker Cache

Anuj Jain <anuj17280@...>
 

Hi,

I am using CF V226, Diego: 0.1443.0, Diego docker cache: 0.1021.0, etcd:
20, garden-linux: 0.329.0

While creating application using 'cf docker-push' I am able to create
the container - but as soon as I am trying to enable diego docker cache, it
is giving me 'oversized record received with length 20527' error

=== command which I am using to create and enable cahce =========
cf docker-push dockertest8 anuj17280/tomcat --no-start
cf set-env dockertest8 DIEGO_DOCKER_CACHE true
cf start dockertest8

============= Error which I am getting ================
Digest:
sha256:5095b0ecf855032f8281325df9d519cb1de87cd3ffbdcee344675af212a6b24c
Status: Downloaded newer image for anuj17280/tomcat:latest
Docker image pulled.
Docker image will be cached as
docker-registry.service.cf.internal:8080/a05eb57d-57d4-4cd7-5e18-93389e438687
Tagging docker image anuj17280/tomcat:latest as
docker-registry.service.cf.internal:8080/a05eb57d-57d4-4cd7-5e18-93389e438687
...
Docker image tagged.
Pushing docker image
docker-registry.service.cf.internal:8080/a05eb57d-57d4-4cd7-5e18-93389e438687
The push refers to a repository
[docker-registry.service.cf.internal:8080/a05eb57d-57d4-4cd7-5e18-93389e438687]
(len: 1)
unable to ping registry endpoint
https://docker-registry.service.cf.internal:8080/v0/
v2 ping attempt failed with error: Get
https://docker-registry.service.cf.internal:8080/v2/: tls: oversized record
received with length 20527
v1 ping attempt failed with error: Get
https://docker-registry.service.cf.internal:8080/v1/_ping: tls: oversized
record received with length 20527
failed to cache image anuj17280/tomcat:latest exit status 1
Staging process failed: Exit trace for group:
builder exited with error: exit status 1
docker_daemon exited with nil
Exit status 2
Staging Failed: Exited with status 2

FAILED
StagingError

TIP: use 'cf logs dockertest8 --recent' for more information


Re: Debug failed to create container, Failed to stage application: staging failed?

Tom Sherrod <tom.sherrod@...>
 

Thanks for following up.

I recently found a mention of TMPDIR issue and deployed the latest diego
with v0.330.0. Appears to have resolved the issue.

Tom

On Fri, Jan 22, 2016 at 6:49 AM, Will Pragnell <wpragnell(a)pivotal.io> wrote:

In fact, I'd strongly recommend upgrading to Garden-Linux-Release v0.330.0
[1], as that release fixed a nasty security issue (CVE-2015-5350 [2]).

Best,
Will

[1]:
https://github.com/cloudfoundry-incubator/garden-linux-release/releases/tag/v0.330.0
[2]:
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LSU7KECXU3X52RLWZPJQIBBVLPEOJSWR/

On 22 January 2016 at 11:45, Will Pragnell <wpragnell(a)pivotal.io> wrote:

Hi Tom,

Sorry, didn't spot this one (thanks Amit for bringing it to our
attention). This was a known issue relating to the way BOSH sets the
$TMPDIR environment variable by default. We fixed the issue in
Garden-Linux-Release v0.328.0 [1] so I'd recommend upgrading to that
release (or later) if possible.

Best,
Will

[1]:
https://github.com/cloudfoundry-incubator/garden-linux-release/releases/tag/v0.328.0

On 22 January 2016 at 01:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Let me cc the Garden team, hopefully someone there can help.

Best,
Amit

On Sat, Jan 16, 2016 at 8:17 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Thanks for the pointer.

Now the problem:

garden.stdout.log:
{"timestamp":"1453002747.400245667","source":"garden-linux","message":"garden-linux.pool.acquire.provide-rootfs-
failed","log_level":2,"data":{"error":"write /tmp/687182776: no space
left on
device","handle":"089ad5d6-4457-4184-bbda-ef918fb6676a-90065023-86c3-4fa2-8915-2508001bb91b-1e2fb2e4-f985-40f2-70f2-71bd8b0cdd12","session":"8.7"}}

/tmp is pointing to /dev/loop0 (120M) and full. How can this problem be
corrected?

Tom

On Thu, Jan 14, 2016 at 10:49 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

It's saying "failed to create container" so you could get logs from
the Diego cells and see what errors you see there. If you've configured
syslog to drain to an aggregation service, you can just watch the logs
there (especially look for errors in rep and garden logs). Otherwise, I
would simulcast to multiple terminal sessions, SSH to each cell, and tail
the logs of the rep and gardens to catch the error as it happens.

On Thu, Jan 14, 2016 at 11:04 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

CF: 225
Diego: 0.1441.0
Default to diego.

I deploy a sample app, no problems. I attempt to deploy another app
that fails, because of application issues. A deploy of any other app fails
with:
2016-01-14T18:35:54.47+0000 [STG/0] ERR Failed to create
container
2016-01-14T18:35:54.73+0000 [API/0] ERR Failed to stage
application: staging failed

I redeploy the sample app as a test and it fails. Any app deployment
fails.
CC, stager.stdout.log says staging failed.

Pointers of where to look next to find out why staging is failing?

Thanks,
Tom


Need help for diego deployment

Kinjal Doshi
 

Hi,

After deploying CF version 226 on AWS using microbosh, I am trying to
understand how to deploy Diego now to work with this version of CF but have
not been able to figure out much yet. I was able to find steps for
deploying Diego on BOSH-Lite at
https://github.com/cloudfoundry-incubator/diego-release#deploying-diego-to-bosh-lite
but not for BOSH.

Would appreciate some pointers in this direction .

Thanks in advance,
Kinjal


Re: Debug failed to create container, Failed to stage application: staging failed?

Will Pragnell <wpragnell@...>
 

In fact, I'd strongly recommend upgrading to Garden-Linux-Release v0.330.0
[1], as that release fixed a nasty security issue (CVE-2015-5350 [2]).

Best,
Will

[1]:
https://github.com/cloudfoundry-incubator/garden-linux-release/releases/tag/v0.330.0
[2]:
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LSU7KECXU3X52RLWZPJQIBBVLPEOJSWR/

On 22 January 2016 at 11:45, Will Pragnell <wpragnell(a)pivotal.io> wrote:

Hi Tom,

Sorry, didn't spot this one (thanks Amit for bringing it to our
attention). This was a known issue relating to the way BOSH sets the
$TMPDIR environment variable by default. We fixed the issue in
Garden-Linux-Release v0.328.0 [1] so I'd recommend upgrading to that
release (or later) if possible.

Best,
Will

[1]:
https://github.com/cloudfoundry-incubator/garden-linux-release/releases/tag/v0.328.0

On 22 January 2016 at 01:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Let me cc the Garden team, hopefully someone there can help.

Best,
Amit

On Sat, Jan 16, 2016 at 8:17 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Thanks for the pointer.

Now the problem:

garden.stdout.log:
{"timestamp":"1453002747.400245667","source":"garden-linux","message":"garden-linux.pool.acquire.provide-rootfs-
failed","log_level":2,"data":{"error":"write /tmp/687182776: no space
left on
device","handle":"089ad5d6-4457-4184-bbda-ef918fb6676a-90065023-86c3-4fa2-8915-2508001bb91b-1e2fb2e4-f985-40f2-70f2-71bd8b0cdd12","session":"8.7"}}

/tmp is pointing to /dev/loop0 (120M) and full. How can this problem be
corrected?

Tom

On Thu, Jan 14, 2016 at 10:49 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

It's saying "failed to create container" so you could get logs from the
Diego cells and see what errors you see there. If you've configured syslog
to drain to an aggregation service, you can just watch the logs there
(especially look for errors in rep and garden logs). Otherwise, I would
simulcast to multiple terminal sessions, SSH to each cell, and tail the
logs of the rep and gardens to catch the error as it happens.

On Thu, Jan 14, 2016 at 11:04 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

CF: 225
Diego: 0.1441.0
Default to diego.

I deploy a sample app, no problems. I attempt to deploy another app
that fails, because of application issues. A deploy of any other app fails
with:
2016-01-14T18:35:54.47+0000 [STG/0] ERR Failed to create container
2016-01-14T18:35:54.73+0000 [API/0] ERR Failed to stage
application: staging failed

I redeploy the sample app as a test and it fails. Any app deployment
fails.
CC, stager.stdout.log says staging failed.

Pointers of where to look next to find out why staging is failing?

Thanks,
Tom


Re: Debug failed to create container, Failed to stage application: staging failed?

Will Pragnell <wpragnell@...>
 

Hi Tom,

Sorry, didn't spot this one (thanks Amit for bringing it to our attention).
This was a known issue relating to the way BOSH sets the $TMPDIR
environment variable by default. We fixed the issue in Garden-Linux-Release
v0.328.0 [1] so I'd recommend upgrading to that release (or later) if
possible.

Best,
Will

[1]:
https://github.com/cloudfoundry-incubator/garden-linux-release/releases/tag/v0.328.0

On 22 January 2016 at 01:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Let me cc the Garden team, hopefully someone there can help.

Best,
Amit

On Sat, Jan 16, 2016 at 8:17 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Thanks for the pointer.

Now the problem:

garden.stdout.log:
{"timestamp":"1453002747.400245667","source":"garden-linux","message":"garden-linux.pool.acquire.provide-rootfs-
failed","log_level":2,"data":{"error":"write /tmp/687182776: no space
left on
device","handle":"089ad5d6-4457-4184-bbda-ef918fb6676a-90065023-86c3-4fa2-8915-2508001bb91b-1e2fb2e4-f985-40f2-70f2-71bd8b0cdd12","session":"8.7"}}

/tmp is pointing to /dev/loop0 (120M) and full. How can this problem be
corrected?

Tom

On Thu, Jan 14, 2016 at 10:49 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

It's saying "failed to create container" so you could get logs from the
Diego cells and see what errors you see there. If you've configured syslog
to drain to an aggregation service, you can just watch the logs there
(especially look for errors in rep and garden logs). Otherwise, I would
simulcast to multiple terminal sessions, SSH to each cell, and tail the
logs of the rep and gardens to catch the error as it happens.

On Thu, Jan 14, 2016 at 11:04 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

CF: 225
Diego: 0.1441.0
Default to diego.

I deploy a sample app, no problems. I attempt to deploy another app
that fails, because of application issues. A deploy of any other app fails
with:
2016-01-14T18:35:54.47+0000 [STG/0] ERR Failed to create container
2016-01-14T18:35:54.73+0000 [API/0] ERR Failed to stage
application: staging failed

I redeploy the sample app as a test and it fails. Any app deployment
fails.
CC, stager.stdout.log says staging failed.

Pointers of where to look next to find out why staging is failing?

Thanks,
Tom


Questions in deploy cf-release to AWS, need some help

Stanley Shen <meteorping@...>
 

Hello, I am trying to deploy cf to aws
And what I am following is page:
And create my stub manifest based on http://docs.cloudfoundry.org/deploying/aws/cf-stub.html
I also tried to use the postgres job provided by cf release but not RDS database.
I also tried to use only one zone to minimum the VMs.

./scripts/generate_deployment_manifest aws my_stub.yml
After the manifest is generated, I also did some manual changes.(which can be defined in stub file too actually)
And here is my final manifest
https://gist.github.com/StanleyShen/3c3ebb45529fc8310f4b
But when I am deploy it to AWS, the api job keep failing, and here are some logs from "bosh logs api_z1 0"
https://github.com/StanleyShen/learns/blob/master/api_z1.0.2016-01-21-13-30-37.tgz
From the log, I didn't get a clue for the reason.
I see some errors like:
[2016-01-22 05:57:05+0000] ------------ STARTING cloud_controller_ng_ctl at Fri Jan 22 05:57:05 UTC 2016 --------------
[2016-01-22 05:57:10+0000] Deprecated: Use -s or --insert-seed flag
[2016-01-22 06:03:10+0000] Killing /var/vcap/sys/run/cloud_controller_ng/cloud_controller_ng.pid: 4314
[2016-01-22 06:03:10+0000] ------------ STARTING cloud_controller_ng_ctl at Fri Jan 22 06:03:10 UTC 2016 --------------
[2016-01-22 06:03:11+0000] .Stopped
[2016-01-22 06:03:15+0000] Deprecated: Use -s or --insert-seed flag

[2016-01-22 05:57:10+0000] ------------ STARTING cloud_controller_worker_ctl at Fri Jan 22 05:57:10 UTC 2016 --------------
[2016-01-22 05:57:11+0000] ------------ STARTING cloud_controller_worker_ctl at Fri Jan 22 05:57:11 UTC 2016 --------------
[2016-01-22 05:57:29+0000] rake aborted!
[2016-01-22 05:57:29+0000] Sequel::Migrator::NotCurrentError: migrator is not current
[2016-01-22 05:57:29+0000] Tasks: TOP => buildpacks:install
[2016-01-22 05:57:30+0000] (See full trace by running task with --trace)
[2016-01-22 05:57:31+0000] rake aborted!
[2016-01-22 05:57:31+0000] Sequel::Migrator::NotCurrentError: migrator is not current
[2016-01-22 05:57:31+0000] Tasks: TOP => jobs:local
[2016-01-22 05:57:31+0000] (See full trace by running task with --trace)


for the "cfrouter" load balancer in manifest, I tried to create one load balancer based on https://docs.pivotal.io/pivotalcf/customizing/pcf-aws-manual-config.html#pcfaws-om-elbsecgrp
But in latest try, I didn't run to it yet, not sure if I was configuring it right.

| cf | 226+dev.1* | 5de34b6 |
| bosh-aws-xen-hvm-ubuntu-trusty-go_agent | ubuntu-trusty | 3177* | ami-7eafb41f light |

Could someone please help to take a look on it?
1. Is my manifest good enough for a deployment?
2. what's the possible issue for api cannot be running?


Re: /v2/organizations/org_guid/users takes more time compared to other org retrievals

Amit Kumar Gupta
 

It looks to me as though the fix may have first appeared in CF v227, but
you should take CF v228 [1] due to a critical CVE [2] fix in 228.

[1] https://github.com/cloudfoundry/cf-release/releases/tag/v228
[2]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/WGTU3YNCFXK2PA47QFXIXHCY6W35JZNA/

On Thu, Jan 21, 2016 at 10:15 PM, Ponraj E <ponraj.e(a)gmail.com> wrote:

Hi Amit,

Thanks for the reply.

1. We use Version 211 and CC API version 2.28.0. Does this version has the
issue?
2. From which CF version, the issue has been fixed?

Regards,
Ponraj


Re: /v2/organizations/org_guid/users takes more time compared to other org retrievals

Ponraj E
 

Hi Amit,

Thanks for the reply.

1. We use Version 211 and CC API version 2.28.0. Does this version has the issue?
2. From which CF version, the issue has been fixed?

Regards,
Ponraj


Re: /v2/organizations/org_guid/users takes more time compared to other org retrievals

Amit Kumar Gupta
 

What version of CF are you deploying? This sounds similar to a known issue
with consul which was fixed in a previous release.

On Thursday, January 21, 2016, Ponraj E <ponraj.e(a)gmail.com> wrote:

Hi Chris,

Thanks. Does CF have plans of increasing the performance here? OR there is
no other option and its a known issue? because currently irrespective of
the number of users, it takes atleast 10s (in my case) to retrieve all the
users.


Regards,
Ponraj


Re: UAA, autoapprove, and cf client

Madhura Bhave
 

Hi Matt,

Having auto approve true on a client means the token will be granted without the user having to approve the scopes that the client is requesting. It is used for clients that have a grant type of "implicit" or "authorization_code". The grant type decides whether you have a response_type=token or a response_type=code (implicit being the grant type that can be used to get the token directly) in the request to /oauth/authorize.

The cf client is a client of type "password grant" which does not require approval of scopes by the user.

https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/spec#L229 This property is being deprecated because auto-approve can be specified under the uaa.clients section on a per client basis.
Madhura

On Jan 21, 2016, at 1:07 PM, Matt Cholick <cholick(a)gmail.com> wrote:

We recently upgrades from 222 to 228 and saw a change we'd like to know the reason for.

Looking at the generated uaa.yml for the job's config, in the newest version, oauth.client.autoapprove only contains "login" and "support-signon". If we look back to the file in our other environments (still 222), the list also contains "cf". The shorter list looks to be what uaa-release has had for a while, so I'm guessing in the older environments the larger list is merged from elsewhere (I didn't find the source for this default value including "cf" in 222)

What was the reason for this change?

We're using the flow Trusted Authentication from Login Server
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#trusted-authentication-from-login-server
And having auto-approve means that in step 1, we can ask for response_type=token rather than response_type=code to immediately get the token.

Also, this property is listed as deprecated:
https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/spec#L229
We're relying on it in our login server. When is the uaa team planning to remove it?

-Matt Cholick


Re: /v2/organizations/org_guid/users takes more time compared to other org retrievals

Ponraj E
 

Hi Chris,

Thanks. Does CF have plans of increasing the performance here? OR there is no other option and its a known issue? because currently irrespective of the number of users, it takes atleast 10s (in my case) to retrieve all the users.


Regards,
Ponraj


Re: Debug failed to create container, Failed to stage application: staging failed?

Amit Kumar Gupta
 

Let me cc the Garden team, hopefully someone there can help.

Best,
Amit

On Sat, Jan 16, 2016 at 8:17 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

Thanks for the pointer.

Now the problem:

garden.stdout.log:
{"timestamp":"1453002747.400245667","source":"garden-linux","message":"garden-linux.pool.acquire.provide-rootfs-
failed","log_level":2,"data":{"error":"write /tmp/687182776: no space
left on
device","handle":"089ad5d6-4457-4184-bbda-ef918fb6676a-90065023-86c3-4fa2-8915-2508001bb91b-1e2fb2e4-f985-40f2-70f2-71bd8b0cdd12","session":"8.7"}}

/tmp is pointing to /dev/loop0 (120M) and full. How can this problem be
corrected?

Tom

On Thu, Jan 14, 2016 at 10:49 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

It's saying "failed to create container" so you could get logs from the
Diego cells and see what errors you see there. If you've configured syslog
to drain to an aggregation service, you can just watch the logs there
(especially look for errors in rep and garden logs). Otherwise, I would
simulcast to multiple terminal sessions, SSH to each cell, and tail the
logs of the rep and gardens to catch the error as it happens.

On Thu, Jan 14, 2016 at 11:04 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

CF: 225
Diego: 0.1441.0
Default to diego.

I deploy a sample app, no problems. I attempt to deploy another app that
fails, because of application issues. A deploy of any other app fails with:
2016-01-14T18:35:54.47+0000 [STG/0] ERR Failed to create container
2016-01-14T18:35:54.73+0000 [API/0] ERR Failed to stage
application: staging failed

I redeploy the sample app as a test and it fails. Any app deployment
fails.
CC, stager.stdout.log says staging failed.

Pointers of where to look next to find out why staging is failing?

Thanks,
Tom


UAA, autoapprove, and cf client

Matt Cholick
 

We recently upgrades from 222 to 228 and saw a change we'd like to know the
reason for.

Looking at the generated uaa.yml for the job's config, in the newest
version, oauth.client.autoapprove only contains "login" and
"support-signon". If we look back to the file in our other environments
(still 222), the list also contains "cf". The shorter list looks to be what
uaa-release has had for a while, so I'm guessing in the older environments
the larger list is merged from elsewhere (I didn't find the source for this
default value including "cf" in 222)

What was the reason for this change?

We're using the flow Trusted Authentication from Login Server
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#trusted-authentication-from-login-server
And having auto-approve means that in step 1, we can ask for
response_type=token rather than response_type=code to immediately get the
token.

Also, this property is listed as deprecated:
https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/spec#L229
We're relying on it in our login server. When is the uaa team planning to
remove it?

-Matt Cholick


Re: /v2/organizations/org_guid/users takes more time compared to other org retrievals

Christopher Piraino <cpiraino@...>
 

HI Ponraj,

Yes, for that specific API call the CC will internally be sending a request
to the UAA for user information. That extra request is probably what you
are seeing.

- Chris

On Thu, Jan 21, 2016 at 1:31 AM, Ponraj E <ponraj.e(a)gmail.com> wrote:

Hi,

We found that /v2/organizations/4df92169-5b8d-489b-ba0f-7114168aa476/users
takes more response time compared to other org retrievals like:

1./v2/organizations/4df92169-5b8d-489b-ba0f-7114168aa476/spaces
2./v2/organizations/dc1bedf0-d842-4170-8849-1a919a902336/services

3./v2/organizations/a163840f-5bd5-48a0-8736-1d837bda1353/space_quota_definitions
4./v2/organizations/525a6450-9202-4ea1-beca-6fdda210710e/summary

Are some extra steps involved at CC end to retrieve the users? Else, Could
it be purely a network delay from our end?


Regards,
Ponraj


Re: Mysql/Postgres Cluster via CF Containers Broker

Marco Nicosia
 

Hi Shashank,

We're all pretty eager to start messing about with data services via
containers vs. relying on BOSH-provisioned VMs.

There's a lot we could do to move forward, but the real sticking point is:
3. Manage the Volumes via Flocker
That hasn't been something that's as easily done as suggested.

Just this week, the team launched an effort to create volume persistence in
Diego. You can read more about it here:
http://cf-dev.70369.x6.nabble.com/cf-dev-CF-Persistence-Proposal-td2805.html

I think if you're serious about using the Containers Broker, you'll want to
follow their progress closely. Hopefully there's a way for you to get
involved!

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.


On Wed, Jan 20, 2016 at 7:46 PM, Shashank Jain <jain.sm(a)gmail.com> wrote:

Was toying with the idea of having a Postgres/Mysql cluster provisioned
via Container Service broker in CF.
What this primarily means is
1. Spin the Container Images of Mysql via Swarm
2. use Docker networking to create an Overlay network for the cluster
3. Manage the Volumes Via Flocker
4. use tools like pgpool etc to manage the HA aspects

Regards
Shashank


Re: Questions about Scaling Cloud Foundry document

Sam Dai
 

Hello Daniel,
Thank you for your response.

Thanks,
Sam


Re: Questions about Scaling Cloud Foundry document

Daniel Mikusa
 

On Thu, Jan 21, 2016 at 12:31 AM, Sam Dai <sam.dai(a)servicemax.com> wrote:

I have another question, in diego.xml, I saw cell has two jobs "cell_z1"
and "cell_z2", what is the difference between them? in which scenario I
need use cell_z2?
The cell VMs are where your actual applications run, so redundancy and
capacity are two scenarios that come to mind where you'd have multiple
cells.

Dan



- instances: 1
name: cell_z1
networks:
- name: diego1
properties:
diego:
rep:
zone: z1
metron_agent:
zone: z1
resource_pool: cell_z1
- instances: 0
name: cell_z2
networks:
- name: diego2
properties:
diego:
rep:
zone: z2
metron_agent:
zone: z2
resource_pool: cell_z2


The CF version is V227, Diego version is v.0.1445.0. the following is the
result of command "bosh vms"

------------------------------------+---------+---------------+--------------+
| Job/index | State | Resource Pool | IPs
|

+------------------------------------+---------+---------------+--------------+
| api_z1/0 | running | large_z1 |
10.244.0.138 |
| consul_z1/0 | running | small_z1 |
10.244.0.54 |
| doppler_z1/0 | running | medium_z1 |
10.244.0.146 |
| etcd_z1/0 | running | medium_z1 |
10.244.0.42 |
| ha_proxy_z1/0 | running | router_z1 |
10.244.0.34 |
| hm9000_z1/0 | running | medium_z1 |
10.244.0.142 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 |
10.244.0.150 |
| nats_z1/0 | running | medium_z1 |
10.244.0.6 |
| postgres_z1/0 | running | medium_z1 |
10.244.0.30 |
| router_z1/0 | running | router_z1 |
10.244.0.22 |
| runner_z1/0 | running | runner_z1 |
10.244.0.26 |
| uaa_z1/0 | running | medium_z1 |
10.244.0.130 |

+------------------------------------+---------+---------------+--------------+

VMs total: 13
Deployment `cf-warden-diego'

Director task 39

Task 39 done

+--------------------+---------+------------------+---------------+
| Job/index | State | Resource Pool | IPs |
+--------------------+---------+------------------+---------------+
| access_z1/0 | running | access_z1 | 10.244.16.6 |
| brain_z1/0 | running | brain_z1 | 10.244.16.134 |
| cc_bridge_z1/0 | running | cc_bridge_z1 | 10.244.16.150 |
| cell_z1/0 | running | cell_z1 | 10.244.16.142 |
| database_z1/0 | running | database_z1 | 10.244.16.130 |
| route_emitter_z1/0 | running | route_emitter_z1 | 10.244.16.154


Re: Questions about Scaling Cloud Foundry document

Daniel Mikusa
 

On Thu, Jan 21, 2016 at 12:10 AM, Sam Dai <sam.dai(a)servicemax.com> wrote:

Hello,
I read document
http://docs.cloudfoundry.org/concepts/high-availability.html today, there
are several questions as below, please help to review and answer these
questions:

(1) In "Scalable Processes" section, I saw there is Diego BBS job, but I
can't find this job in my generated manifest xml diego.xml. when I run
commend "bosh vms", also can't see this job. Where can I configure the
instance number of this job?
*Job**Number**Notes*
Diego BBS ≥ 3 This must be set to an odd number.

I believe that this is the diego database. See here.

https://github.com/cloudfoundry-incubator/diego-design-notes#components-on-the-database-vms


(2) In generated manifest xml diego.xml, I saw there are jobs called
"access" and "cc_bridge", but can't find them in document
http://docs.cloudfoundry.org/concepts/high-availability.html, what is the
instance number of these two jobs that cloud foundry suggested?

(3) In document
http://docs.cloudfoundry.org/concepts/high-availability.html , I saw the
following statement about HAProxy, but I haven't found the introduction
about how to replace HAProxy with our own highly-available load balancing
solution, is there sample or document to introduce this?
1.) Setup your own load balancer
2.) Configure it to balance across your gorouters.
3.) Remove HAProxy when you no longer need it (i.e. when there's no more
traffic going through it).

Dan

*HAProxy:Cloud Foundry deploys with a single instance of HAProxy for use
in lab and test environments. Production environments should use your own
highly-available load balancing solution.*
Thank,
Sam


/v2/organizations/org_guid/users takes more time compared to other org retrievals

Ponraj E
 

Hi,

We found that /v2/organizations/4df92169-5b8d-489b-ba0f-7114168aa476/users takes more response time compared to other org retrievals like:

1./v2/organizations/4df92169-5b8d-489b-ba0f-7114168aa476/spaces
2./v2/organizations/dc1bedf0-d842-4170-8849-1a919a902336/services
3./v2/organizations/a163840f-5bd5-48a0-8736-1d837bda1353/space_quota_definitions
4./v2/organizations/525a6450-9202-4ea1-beca-6fdda210710e/summary

Are some extra steps involved at CC end to retrieve the users? Else, Could it be purely a network delay from our end?


Regards,
Ponraj

5941 - 5960 of 9425