Date   

Re: *.cf.internal on diego windows

Edward Hill
 

setting had gone

added it back on and app deployed \o/


Re: *.cf.internal on diego windows

Edward Hill
 

2 seconds after hitting send I remembered the DNS section in setup.ps1

I expect that

$newDNS = @("127.0.0.1") + $currentDNS

has something to do with it, need to see where that setting went I think


*.cf.internal on diego windows

Edward Hill
 

I've been trying out the windows cell by having a bosh lite VM and a Windows 2012 VM locally on my machine and have hit a stumbling block that highlighted I don't know enough

My bosh lite VM is up and running with the windows stack added and my 2012 VM's event log shows it joining the cluster and reporting back details about the box

If I try and start the NET-sample-app in bosh lite it creates the container on the 2012 VM but then fails downloading the buildpack

If I look in the event logs it's failing to get to:

file-server.service.cf.internal

to download the windows_app_lifecycle.tgz file

I can't see how Diego Windows or Garden Windows is going to direct these urls that bosh is providing to the consul agent on the 2012 box or even the consul VM on bosh-lite.

Have I missed something? including misunderstanding consul :-)


[abacus] MongoDB client

Hristo Iliev
 

Hi,

I now have the first version of a drop-in replacement client for MongoDB:
https://github.com/hsiliev/cf-abacus/commit/c29700aa996bf8169767f99ff3d815d4768a2608

The client still has some limitations:
* no support for ajax.rejectUnauthorized CouchDB option
* no support for skip_setup CouchDB option
* no support for keys, starting with $ (Mongo restriction)
* no support for custom backends (in-memory, lrudown cache, ...)

The eureka stub in my fork stores the port number with key different than $ to overcome the Mongo restrictions.

The client was tested with 2.x and 3.x versions of Mongo. All unit-tests pass without modification, and I started working on the integration tests.

We can add the mongo client as a new sub-module to:
* make the work on integrating and polishing the Mongo code more transparent
* allow reporting of issues for the new code (bugs, improvements, suggestions, requirements)
* start creating abstraction layer that can select one of the DB clients

What do you think?

Regards,
Hristo Iliev


Re: Need help for diego deployment

Eric Malm <emalm@...>
 

Hi, Kinjal,

Thanks for asking: this is an area in which the Diego team is looking
forward to improving documentation and tooling in the near term. For the
time being, here are some more manual instructions:

Assuming you have AWS infrastructure already provisioned for your CF
deployment (VPC, subnets, NAT box, ELBs, etc.), you should need only to add
one or more additional subnets for the VMs in the Diego deployment, and
optionally an ELB for the SSH proxy routing tier (you can also use the
HAproxy in the CF deployment to do the same load-balancing, but you'll need
to give it an Elastic IP). If you're brave, and can coordinate the reserved
sections in the CF and Diego deployment manifests' networking configs
correctly, you could even share the same subnet(s) between the two
deployments.

Once you have those subnets provisioned, you'll need to translate their
properties into the iaas-settings.yml stub that you supply to the
generate-deployment-manifest script in diego-release. Since you're
deploying CF v226, we recommend you use Diego final version v0.1442.0 and
the associated manifest-generation script in that version of the release.
The other stubs should be independent of that iaas-settings one, and should
be pretty much the same as the ones for the BOSH-Lite deployment. You'll
likely want to provide different secrets and credentials in the
property-overrides stub, though, and perhaps different instance counts
depending on the availability needs of your deployment. I've included at
the end of this email a representative iaas-settings.yml file from one of
the Diego team's environments, with any specific identifiers for AWS
entities replaced by PLACEHOLDER values.

As a side note, if you don't already have the consul VMs deployed in your
CF deployment, you'll need to enable them so that the Diego components can
use it to communicate. We recommend you operate an odd number of consul
VMs: 1 if don't need high availability, and 3 or 5 if you do (as in a
production environment). You can enable them by changing the instance count
on the consul_z1 and consul_z2 jobs in the CF manifest.

After you've customized those stubs and adjusted your CF manifest if
necessary, you can generate the Diego manifest by running something like
the following from your diego-release directory:

$ ./scripts/generate-deployment-manifest \
PATH/TO/MY/CUSTOMIZED-PROPERTY-OVERRIDES.YML \
PATH/TO/MY/CUSTOMIZED-INSTANCE-COUNT-OVERRIDES.YML \
manifest-generation/bosh-lite-stubs/persistent-disk-overrides.yml \
PATH/TO/MY/CUSTOMIZED-IAAS-SETTINGS.YML \
manifest-generation/bosh-lite-stubs/additional-jobs.yml \
manifest-generation/bosh-lite-stubs/release-versions.yml \
PATH/TO/MY/MANIFEST/DIRECTORY \
> PATH/TO/MY/MANIFEST/DIRECTORY/diego.yml

'PATH/TO/MY/MANIFEST/DIRECTORY' should contain your CF manifest in a file
named 'cf.yml'. Also, please note that if you move to CF v227 or later,
which recommend Diego v0.1445.0 or later, the manifest-generation script
has changed to take its stub arguments via flags, instead of as these
positional arguments, and some of the stubs have changed slightly.

We also realize this is currently an obscure and potentially error-prone
process, and the Diego team does have a couple stories queued up to do soon
to provide more information about how to set up Diego on AWS:

- We plan in https://www.pivotaltracker.com/story/show/100909610 to
parametrize, document, and publish the tools and additional templates we
use to provision the AWS environments we use for CI and for our developers'
experiments and investigations, all the way from an empty account to a VPC
with BOSH, CF, and Diego.
- We plan in https://www.pivotaltracker.com/story/show/100909610 to provide
more manual instructions to set up a Diego environment compatible with the
'minimal-aws' CF deployment manifest and infrastructure settings, including
provisioning any additional infrastructure such as subnets and translating
their information into the stubs for the diego-release manifest-generation
script.

We'll also be eager to adopt and to integrate with the tooling the CF
Infrastructure and CF Release Integration teams will produce at some point
to automate environment bootstrapping and CF manifest generation as much as
possible.

Please let me and the rest of the team know here if you need further
assistance or clarification.

Thanks again,
Eric, CF Runtime Diego PM

*****

Example iaas-settings.yml file, with PLACEHOLDER entries for your
environment's info:

iaas_settings:
compilation_cloud_properties:
availability_zone: us-east-1a
instance_type: c3.large
resource_pool_cloud_properties:
- cloud_properties:
availability_zone: us-east-1a
elbs:
- PLACEHOLDER-SSHProxyELB-ID
instance_type: m3.medium
name: access_z1
- cloud_properties:
availability_zone: us-east-1b
elbs:
- PLACEHOLDER-SSHProxyELB-ID
instance_type: m3.medium
name: access_z2
- cloud_properties:
availability_zone: us-east-1c
elbs:
- PLACEHOLDER-SSHProxyELB-ID
instance_type: m3.medium
name: access_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.medium
name: brain_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.medium
name: brain_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.medium
name: brain_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.medium
name: cc_bridge_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.medium
name: cc_bridge_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.medium
name: cc_bridge_z3
- cloud_properties:
availability_zone: us-east-1a
ephemeral_disk:
iops: 1200
size: 50000
type: io1
instance_type: m3.large
name: cell_z1
- cloud_properties:
availability_zone: us-east-1b
ephemeral_disk:
iops: 1200
size: 50000
type: io1
instance_type: m3.large
name: cell_z2
- cloud_properties:
availability_zone: us-east-1c
ephemeral_disk:
iops: 1200
size: 50000
type: io1
instance_type: m3.large
name: cell_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.large
name: colocated_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.large
name: colocated_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.large
name: colocated_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.large
name: database_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.large
name: database_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.large
name: database_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.medium
name: route_emitter_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.medium
name: route_emitter_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.medium
name: route_emitter_z3
stemcell:
name: bosh-aws-xen-hvm-ubuntu-trusty-go_agent
version: latest
subnet_configs:
- name: diego1
subnets:
- cloud_properties:
security_groups:
- PLACEHOLDER-InternalSecurityGroup-ID
subnet: PLACEHOLDER-subnet-id-A
dns:
- 10.10.0.2
gateway: 10.10.5.1
range: 10.10.5.0/24
reserved:
- 10.10.5.2 - 10.10.5.9
static:
- 10.10.5.10 - 10.10.5.63
- name: diego2
subnets:
- cloud_properties:
security_groups:
- PLACEHOLDER-InternalSecurityGroup-ID
subnet: PLACEHOLDER-subnet-id-B
dns:
- 10.10.0.2
gateway: 10.10.6.1
range: 10.10.6.0/24
reserved:
- 10.10.6.2 - 10.10.6.9
static:
- 10.10.6.10 - 10.10.6.63
- name: diego3
subnets:
- cloud_properties:
security_groups:
- PLACEHOLDER-InternalSecurityGroup-ID
subnet: PLACEHOLDER-subnet-id-C
dns:
- 10.10.0.2
gateway: 10.10.7.1
range: 10.10.7.0/24
reserved:
- 10.10.7.2 - 10.10.7.9
static:
- 10.10.7.10 - 10.10.7.63


On Fri, Jan 22, 2016 at 4:28 AM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

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: Question about `cf scale`

Marco Nicosia
 

Sweet! Thank you guys!

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.

On Fri, Jan 22, 2016 at 11:55 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Routing team has the ball.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, Jan 22, 2016 at 11:47 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Marco,

I've reproduced the behavior on a CF v228 installation: it's happening
because the app-version on CC's app model is changing on the scale. I've
filed a bug with the CAPI team about it at
https://www.pivotaltracker.com/story/show/112251451.

Fortunately, this seems to happen only on the first scale-up or
scale-down after the upgrade to CF v228, and subsequent scales leave the
remaining desired instances undisturbed. One possible reason that this is
happening may be that a new 'ports' field is getting back-filled on the app
when it's altered with the new desired instance count, and that change to
the 'ports' field triggers a new internal version of the app to be
generated and submitted to the runtime backend. In any case, the relevant
teams will investigate the cause and possible remediations for the
regression.

Thanks again,
Eric


On Fri, Jan 22, 2016 at 10:51 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Marco,

Thanks for the report. That does sound disturbing, as scale-up and
scale-down operations on an app should not disrupt running instances that
are still desired. We'll have a pair from the CAPI or Diego teams take a
look at this as soon as possible.

Best,
Eric, CF Runtime Diego PM

On Fri, Jan 22, 2016 at 9:06 AM, Marco Nicosia <mnicosia(a)pivotal.io>
wrote:

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.


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

Amit Kumar Gupta
 

Hey Stanley,

The core dev team will look at the GitHub issue you've opened here:
https://github.com/cloudfoundry/cf-release/issues/888. I encourage anyone
else who wants to help to answer on GitHub, so we have a single source of
truth and avoid duplicating effort.

Cheers,
Amit

On Thu, Jan 21, 2016 at 10:34 PM, Stanley Shen <meteorping(a)gmail.com> wrote:

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: Question about `cf scale`

Shannon Coen
 

Routing team has the ball.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, Jan 22, 2016 at 11:47 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Marco,

I've reproduced the behavior on a CF v228 installation: it's happening
because the app-version on CC's app model is changing on the scale. I've
filed a bug with the CAPI team about it at
https://www.pivotaltracker.com/story/show/112251451.

Fortunately, this seems to happen only on the first scale-up or scale-down
after the upgrade to CF v228, and subsequent scales leave the remaining
desired instances undisturbed. One possible reason that this is happening
may be that a new 'ports' field is getting back-filled on the app when it's
altered with the new desired instance count, and that change to the 'ports'
field triggers a new internal version of the app to be generated and
submitted to the runtime backend. In any case, the relevant teams will
investigate the cause and possible remediations for the regression.

Thanks again,
Eric


On Fri, Jan 22, 2016 at 10:51 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Marco,

Thanks for the report. That does sound disturbing, as scale-up and
scale-down operations on an app should not disrupt running instances that
are still desired. We'll have a pair from the CAPI or Diego teams take a
look at this as soon as possible.

Best,
Eric, CF Runtime Diego PM

On Fri, Jan 22, 2016 at 9:06 AM, Marco Nicosia <mnicosia(a)pivotal.io>
wrote:

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.


Re: Question about `cf scale`

Eric Malm <emalm@...>
 

Hi, Marco,

I've reproduced the behavior on a CF v228 installation: it's happening
because the app-version on CC's app model is changing on the scale. I've
filed a bug with the CAPI team about it at
https://www.pivotaltracker.com/story/show/112251451.

Fortunately, this seems to happen only on the first scale-up or scale-down
after the upgrade to CF v228, and subsequent scales leave the remaining
desired instances undisturbed. One possible reason that this is happening
may be that a new 'ports' field is getting back-filled on the app when it's
altered with the new desired instance count, and that change to the 'ports'
field triggers a new internal version of the app to be generated and
submitted to the runtime backend. In any case, the relevant teams will
investigate the cause and possible remediations for the regression.

Thanks again,
Eric

On Fri, Jan 22, 2016 at 10:51 AM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Marco,

Thanks for the report. That does sound disturbing, as scale-up and
scale-down operations on an app should not disrupt running instances that
are still desired. We'll have a pair from the CAPI or Diego teams take a
look at this as soon as possible.

Best,
Eric, CF Runtime Diego PM

On Fri, Jan 22, 2016 at 9:06 AM, Marco Nicosia <mnicosia(a)pivotal.io>
wrote:

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.


Re: UAA service is currently unavailable -- even though it appears to be?

Tom Sherrod <tom.sherrod@...>
 

Great timing.

I compared the manifest to a working revision and discovered the url after
spring_profiles: was incorrect.

Corrected and redeployed allowed for setting of roles.

Thank you!

On Fri, Jan 22, 2016 at 2:24 PM, CF Runtime <cfruntime(a)gmail.com> wrote:

Hi Tom

Can you please give us your UAA logs and redacted deployment manifest?

Thanks,
Zak Auerbach
CF Release Integration

On Tue, Jan 19, 2016 at 7:06 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

cf 225, diego 0.1446.0, etcd 22, garden-linux 0.330.0

Deployed fine. Log in with admin, no problems.
cf create-user -- works, user can login
cf set-org-role or cf set-space-role -- "Server error, status code: 503,
error code: 20004, message: The UAA service is currently unavailable"

Where to look next? Problem?

Snippet from cloud_controller_ng.log:
"timestamp":1453214684.8997626,"message":"UAA request for token failed:
#<CF::UAA::NotFound: invalid status response:
404>","log_level":"error","source":"cc.uaa_client","data":{"request_guid":"9a23635a-9bd1-466d-4634-09a5b5b68ad5::d81a9295-1cd4-4bc0-aba8-e6be21b078d6"},"thread_id":70231565138100,"fiber_id":70231564408960,"process_id":6686,"file":"/var/vcap/data/packages/cloud_controller_ng/80b067d32996057a4fc88fe1c553764671e7e8e8.1-9d085696303be97998891bd2c719646024909e5a/cloud_controller_ng/lib/cloud_controller/uaa/uaa_client.rb","lineno":28,"method":"rescue
in token_info"}
{"timestamp":1453214684.9005187,"message":"Request failed: 503:
{\"code\"=>20004, \"description\"=>\"The UAA service is currently
unavailable\", \"error_code\"=>\"CF-UaaUnavailable\",
\"backtrace\"=>[\"/var/vcap/data/packages/cloud_controller_ng/80b067d32996057a4fc88fe1c553764671e7e8e8.1-9d085696303be97998891bd2c719646024909e5a/cloud_controller_ng/app/controllers/runtime/organizations_controller.rb:128:in
`rescue in block (2 levels) i


Re: UAA service is currently unavailable -- even though it appears to be?

CF Runtime
 

Hi Tom

Can you please give us your UAA logs and redacted deployment manifest?

Thanks,
Zak Auerbach
CF Release Integration

On Tue, Jan 19, 2016 at 7:06 AM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

cf 225, diego 0.1446.0, etcd 22, garden-linux 0.330.0

Deployed fine. Log in with admin, no problems.
cf create-user -- works, user can login
cf set-org-role or cf set-space-role -- "Server error, status code: 503,
error code: 20004, message: The UAA service is currently unavailable"

Where to look next? Problem?

Snippet from cloud_controller_ng.log:
"timestamp":1453214684.8997626,"message":"UAA request for token failed:
#<CF::UAA::NotFound: invalid status response:
404>","log_level":"error","source":"cc.uaa_client","data":{"request_guid":"9a23635a-9bd1-466d-4634-09a5b5b68ad5::d81a9295-1cd4-4bc0-aba8-e6be21b078d6"},"thread_id":70231565138100,"fiber_id":70231564408960,"process_id":6686,"file":"/var/vcap/data/packages/cloud_controller_ng/80b067d32996057a4fc88fe1c553764671e7e8e8.1-9d085696303be97998891bd2c719646024909e5a/cloud_controller_ng/lib/cloud_controller/uaa/uaa_client.rb","lineno":28,"method":"rescue
in token_info"}
{"timestamp":1453214684.9005187,"message":"Request failed: 503:
{\"code\"=>20004, \"description\"=>\"The UAA service is currently
unavailable\", \"error_code\"=>\"CF-UaaUnavailable\",
\"backtrace\"=>[\"/var/vcap/data/packages/cloud_controller_ng/80b067d32996057a4fc88fe1c553764671e7e8e8.1-9d085696303be97998891bd2c719646024909e5a/cloud_controller_ng/app/controllers/runtime/organizations_controller.rb:128:in
`rescue in block (2 levels) i


Re: Question about `cf scale`

Eric Malm <emalm@...>
 

Hi, Marco,

Thanks for the report. That does sound disturbing, as scale-up and
scale-down operations on an app should not disrupt running instances that
are still desired. We'll have a pair from the CAPI or Diego teams take a
look at this as soon as possible.

Best,
Eric, CF Runtime Diego PM

On Fri, Jan 22, 2016 at 9:06 AM, Marco Nicosia <mnicosia(a)pivotal.io> wrote:

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.


AWS Elastic Cache service broker

Sachin
 

Is there an Elastic Cache service broker for AWS that can be leveraged?

Thanks,
Sachin


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?

5901 - 5920 of 9398