I deployed diego release and still have issues.

1. Uploaded the app with no-start flag.
2. cf apps works
3. Started the app, got the failed status (app it self is working. I can
get int o the app from browser)
4. cf apps and cf logs are failing (irrespective of how many times I try
and how long I wait)


Following are my command logs and the logs from all the bosh vms is in
https://gist.github.com/6c81bed0d8eb888da970

1. diego_cf-deployment.yml - diego cf deployment
2. diego_diego-deployment.yml - diego diego deployment
3. jobsLogDiego.tgz - logs from all bosh vms

*******************Uploading app********
guests-MacBook-Pro:apps rsamban$ cf push gs -p
gs-serving-web-content-0.1.0.jar --no-start
Creating app gs in org yesVin / space dev as admin...
OK

Creating route gs.192.168.1.103.xip.io...
OK

Binding gs.192.168.1.103.xip.io to gs...
OK

Uploading gs...
Uploading app files from: gs-serving-web-content-0.1.0.jar
Uploading 12.9M, 112 files
Done uploading
OK
*******************cf apps SUCCESS********
guests-MacBook-Pro:apps rsamban$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
gs stopped 0/1 1G 1G
gs.192.168.1.103.xip.io
******************Staring apps FAILED********
guests-MacBook-Pro:apps rsamban$ cf start gs
Warning: error tailing logs
Unauthorized error: You are not authorized. Error: Invalid authorization
Starting app gs in org yesVin / space dev as admin...

FAILED
Start app timeout

TIP: use 'cf logs gs --recent' for more information
*********************cf logs FAILED***********
guests-MacBook-Pro:apps rsamban$ cf logs gs --recent
Connected, dumping recent logs for app gs in org yesVin / space dev as
admin...

FAILED
Unauthorized error: You are not authorized. Error: Invalid authorization
*********************cf apps fails***********
guests-MacBook-Pro:apps rsamban$ cf apps
Getting apps in org yesVin / space dev as admin...
FAILED
Server error, status code: 500, error code: 10001, message: An unknown
error occurred.
guests-MacBook-Pro:apps rsamban$

The logs for all the bosh vms are in jobsLogDiego.tgz
Following is the bosh vms output
ramesh(a)ubuntu:~/cloudFoundry/bosh-workplace/logs/6c81bed0d8eb888da970$
bosh vms
Acting as user 'admin' on 'bosh2'
Deployment `yesVinCloudFoundry'

Director task 421

Task 421 done


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

+------------------------------------+---------+---------------+---------------+
| api_worker_z1/0 | running | small_z1 |
192.168.1.122 |
| api_worker_z2/0 | running | small_z2 |
192.168.1.222 |
| api_z1/0 | running | large_z1 |
192.168.1.120 |
| api_z2/0 | running | large_z2 |
192.168.1.220 |
| clock_global/0 | running | medium_z1 |
192.168.1.121 |
| consul_z1/0 | running | medium_z1 |
192.168.1.117 |
| doppler_z1/0 | running | medium_z1 |
192.168.1.107 |
| doppler_z2/0 | running | medium_z2 |
192.168.1.207 |
| etcd_z1/0 | running | medium_z1 |
192.168.1.114 |
| etcd_z1/1 | running | medium_z1 |
192.168.1.115 |
| etcd_z2/0 | running | medium_z2 |
192.168.1.213 |
| ha_proxy_z1/0 | running | router_z1 |
192.168.1.103 |
| hm9000_z1/0 | running | medium_z1 |
192.168.1.123 |
| hm9000_z2/0 | running | medium_z2 |
192.168.1.223 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 |
192.168.1.108 |
| loggregator_trafficcontroller_z2/0 | running | small_z2 |
192.168.1.208 |
| nats_z1/0 | running | medium_z1 |
192.168.1.101 |
| nats_z2/0 | running | medium_z2 |
192.168.1.201 |
| nfs_z1/0 | running | medium_z1 |
192.168.1.102 |
| postgres_z1/0 | running | medium_z1 |
192.168.1.112 |
| router_z1/0 | running | router_z1 |
192.168.1.105 |
| router_z2/0 | running | router_z2 |
192.168.1.205 |
| runner_z1/0 | running | runner_z1 |
192.168.1.124 |
| runner_z2/0 | running | runner_z2 |
192.168.1.224 |
| stats_z1/0 | running | small_z1 |
192.168.1.110 |
| uaa_z1/0 | running | medium_z1 |
192.168.1.111 |
| uaa_z2/0 | running | medium_z2 |
192.168.1.211 |

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

VMs total: 27
Deployment `yesVinCloudFoundry-diego'

Director task 422

Task 422 done

+--------------------+---------+------------------+---------------+
| Job/index | State | Resource Pool | IPs |
+--------------------+---------+------------------+---------------+
| access_z1/0 | running | access_z1 | 192.168.1.152 |
| brain_z1/0 | running | brain_z1 | 192.168.1.27 |
| cc_bridge_z1/0 | running | cc_bridge_z1 | 192.168.1.29 |
| cell_z1/0 | running | cell_z1 | 192.168.1.28 |
| database_z1/0 | running | database_z1 | 192.168.1.26 |
| route_emitter_z1/0 | running | route_emitter_z1 | 192.168.1.30 |
+--------------------+---------+------------------+---------------+

VMs total: 6

I appears that once I start the app, things go awry for some reason. Even
though staring app reports failure, the app is actually started

I would really appreciate any help

thanks
-Ramesh

Hi,all.
My local bosh version is 1.2124.0. From cf v208, there is a change in the templates to no longer include resoure pool sizes require s a minimun bosh director of v149. So I guess the solution is to upgrade bosh. But I couldn't find a doc for it.

Hey all,

As of version 9000.50.0 bosh-lite uses official garden-linux release. If
everything was gone right, you will not notice any difference in how things
work.

One benefit of using newer garden server in bosh-lite is easier networking
configuration in your bosh-lite manifests.

For example before you would do something like this:

networks:
- name: cf1
subnets:
- cloud_properties: {name: random}
range: 10.244.0.0/30
reserved:
- 10.244.0.1
static:
- 10.244.0.2
- cloud_properties: {name: random}
range: 10.244.0.4/30
reserved:
- 10.244.0.5
static:
- 10.244.0.6
...

and now you can just do something like this since garden server allows to
place multiple containers on the same subnet:

networks:
- name: cf1
subnets:
- range: 10.244.0.0/24
gateway: 10.244.0.1
static: [10.244.0.2, 10.244.0.3]
...

Dmitriy

I am glad for future simpler networking for bosh-lite manifests; I just
know we have lots of infrastructure-warden.yml spiff templates in lots of
bosh releases.

Also, will bosh-lite stemcells keep *warden* in their name? I assume
there's no functional difference; they are just rootfs.

There's probably automation around that looks for if the current stemcell
name has been uploaded already; else tries to upload it.





On Fri, Sep 11, 2015 at 4:53 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Hey all,

As of version 9000.50.0 bosh-lite uses official garden-linux release. If
everything was gone right, you will not notice any difference in how things
work.

One benefit of using newer garden server in bosh-lite is easier
networking configuration in your bosh-lite manifests.

For example before you would do something like this:

networks:
- name: cf1
subnets:
- cloud_properties: {name: random}
range: 10.244.0.0/30
reserved:
- 10.244.0.1
static:
- 10.244.0.2
- cloud_properties: {name: random}
range: 10.244.0.4/30
reserved:
- 10.244.0.5
static:
- 10.244.0.6
...

and now you can just do something like this since garden server allows to
place multiple containers on the same subnet:

networks:
- name: cf1
subnets:
- range: 10.244.0.0/24
gateway: 10.244.0.1
static: [10.244.0.2, 10.244.0.3]
...

Dmitriy

Hey all,
As of version 9000.50.0 bosh-lite uses official garden-linux release. If
everything was gone right, you will not notice any difference in how things
work.
One benefit of using newer garden server in bosh-lite is easier networking
configuration in your bosh-lite manifests.
For example before you would do something like this:
networks:
- name: cf1
subnets:
- cloud_properties: {name: random}
range: 10.244.0.0/30
reserved:
- 10.244.0.1
static:
- 10.244.0.2
- cloud_properties: {name: random}
range: 10.244.0.4/30
reserved:
- 10.244.0.5
static:
- 10.244.0.6
...
and now you can just do something like this since garden server allows to
place multiple containers on the same subnet:
networks:
- name: cf1
subnets:
- range: 10.244.0.0/24
gateway: 10.244.0.1
static: [10.244.0.2, 10.244.0.3]
...
Dmitriy

Hey all,
As of version 9000.50.0 bosh-lite uses official garden-linux release. If
everything was gone right, you will not notice any difference in how things
work.
One benefit of using newer garden server in bosh-lite is easier networking
configuration in your bosh-lite manifests.
For example before you would do something like this:
networks:
- name: cf1
subnets:
- cloud_properties: {name: random}
range: 10.244.0.0/30
reserved:
- 10.244.0.1
static:
- 10.244.0.2
- cloud_properties: {name: random}
range: 10.244.0.4/30
reserved:
- 10.244.0.5
static:
- 10.244.0.6
...
and now you can just do something like this since garden server allows to
place multiple containers on the same subnet:
networks:
- name: cf1
subnets:
- range: 10.244.0.0/24
gateway: 10.244.0.1
static: [10.244.0.2, 10.244.0.3]
...
Dmitriy