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

Currently you have to specify static_ip for the job (some more info here:
https://bosh.io/docs/networks.html), and place that IP into a property of a
different job. However, we are in the middle of implementing a feature
called links which eliminates this manual configuration. Director will
automatically provide requested information (IPs, etc.) to each job. You
can find more implementation details here:
https://github.com/cloudfoundry/bosh-notes/blob/master/links.md. I have not
created user facing documentation as we are still implementing this feature.

On Fri, Sep 11, 2015 at 2:15 PM, Craig Rubendall <Craig.Rubendall(a)sas.com>
wrote:

Hi,



Newbie question….



I’m trying to create a deployment with 2 vms, let’s call them client and
server. From my client vm, I need the server’s allocated ip address (or
something that will resolve to an ip address) so I can make a tcp
connection.



Is there a facility in Bosh for the client to retrieve this information?



Craig

Hi,

Newbie question....

I'm trying to create a deployment with 2 vms, let's call them client and server. From my client vm, I need the server's allocated ip address (or something that will resolve to an ip address) so I can make a tcp connection.

Is there a facility in Bosh for the client to retrieve this information?

Craig

Not backing up releases etc is great idea.

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

Hey all,
We are trying to improve `bosh backup` functionality for backing up
Director contents. Currently it exports a tarball with a director db, task
logs, and blobstore contents. I don't think it's practical to export whole
blobstore (contains releases, compiled packages, etc.) since it may be very
large, so I am thinking to change `bosh backup` to only include director db
and task logs. For recovering blobstore contents you will be able to run
`bosh upload release x.tgz --fix` to backfill contents. We have fix-assets
stories to intro this features:
https://www.pivotaltracker.com/epic/show/1340278
Thoughts?
Dmitriy

+1 for bosh backup and bosh restore (bosh upload release x.tgz --fix).
Going to be huge help.

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

Hey all,

We are trying to improve `bosh backup` functionality for backing up
Director contents. Currently it exports a tarball with a director db, task
logs, and blobstore contents. I don't think it's practical to export whole
blobstore (contains releases, compiled packages, etc.) since it may be very
large, so I am thinking to change `bosh backup` to only include director db
and task logs. For recovering blobstore contents you will be able to run
`bosh upload release x.tgz --fix` to backfill contents. We have fix-assets
stories to intro this features:
https://www.pivotaltracker.com/epic/show/1340278

Thoughts?

Dmitriy

Hey all,

We are trying to improve `bosh backup` functionality for backing up
Director contents. Currently it exports a tarball with a director db, task
logs, and blobstore contents. I don't think it's practical to export whole
blobstore (contains releases, compiled packages, etc.) since it may be very
large, so I am thinking to change `bosh backup` to only include director db
and task logs. For recovering blobstore contents you will be able to run
`bosh upload release x.tgz --fix` to backfill contents. We have fix-assets
stories to intro this features:
https://www.pivotaltracker.com/epic/show/1340278

Thoughts?

Dmitriy

I am sure I created public gist. I think if we remove the .git (https://gist.github.com/6c81bed0d8eb888da970) from the end it works. of git clone https://gist.github.com/6c81bed0d8eb888da970.git also works,

Let me know

thanks
-Ramesh

Do I have to be on 3068 to get bosh export working? Also,Please post link if you got a chance to document the stuff..Appreciate your help

Hey Ramesh,

It seems that gist you posted is either private or has since been deleted.
We're trying to take a closer look at your logs and see what we can find.

Thanks,
Zak + Dan, CF OSS Integration team

On Thu, Sep 10, 2015 at 12:34 PM, Ramesh Sambandan <rsamban(a)gmail.com>
wrote:

I just deployed cloud foundry in vsphere. I can cf login,create org, space
etc. I can push app with —no -start flag. However, I cannot start the app.
Once I start the app, “cf apps” does not work.(cf login still works). But
after some time, the “cf apps” lists the apps until I again try to start
the app.

The same app works fine when I deploy to bosh lite.

guests-MacBook-Pro:apps rsamban$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
first.jar started 0/1 1G 1G
firstjar.192.168.1.103.xip.io
guests-MacBook-Pro:apps rsamban$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
first.jar started 0/1 1G 1G
firstjar.192.168.1.103.xip.io
guests-MacBook-Pro:apps rsamban$ cf start first.jar
App first.jar is already started
guests-MacBook-Pro:apps rsamban$ cf restage first.jar
Restaging app first.jar in org yesVin / space dev as admin...
Warning: error tailing logs
Unauthorized error: You are not authorized. Error: Invalid authorization
FAILED
Server error, status code: 400, error code: 170001, message: Staging
error: no available stagers

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$ 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$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
first.jar started 0/1 1G 1G
firstjar.192.168.1.103.xip.io

I searched the log files of all the vms for errors (Search for "no
available stagers”, "Invalid authorization" and "An unknown error occurred"
strings in all the bosh jobs).
I can see “no available stagers” message in
/var/vcap/sys/logs/cloud_controller_ng/cloud_controller_ng.log in api_z1
and other two strings are not found in any of the logs.

How would I find the problem. Not sure what I am missing.

Below are my logs and cf manifest.
https://gist.github.com/6c81bed0d8eb888da970.git

Can somebody help me,

thanks
Ramesh

Apologize if it is too much clutter, I wish the mailing list supports some
kind of formatting (like markdown)

We just found where the issue was coming from, there was a chown -R
vcap:vcap /var/vcap lying in one of our packages.

Sorry for the disturbance,

On Fri, Sep 11, 2015 at 4:55 PM Vincent Latombe <vlatombe(a)cloudbees.com>
wrote:

Hello again,

it seems like our manual fiddling on the server had led us to a wrong
direction. What we are actually experiencing :

- On a fresh deploy (new stemcell, new package), we get a successful
deployment
- On a config change in our package (any change actually), the 'bosh -n
deploy' fails.

From the logs after execution of bosh -n deploy, I found the following

bosh/log/@4000000055f2e2d51f95c6fc.s:2015-09-11_14:13:23.92877 [Cmd
Runner] 2015/09/11 14:13:23 DEBUG - /var/vcap/bosh/bin/monit Stderr: monit:
The control file '/var/vcap/bosh/etc/*monitrc*monitrc' must be owned by
you.

bosh/log/@4000000055f2e2d51f95c6fc.s:2015-09-11_14:13:23.92880
[monitJobSupervisor] 2015/09/11 14:13:23 ERROR - Failed to reload monit
Running command: 'monit reload', stdout: '', stderr: 'monit: The control
file '/var/vcap/bosh/etc/monitrc*monitrc*' must be owned by you.

As I undertand it, as part of the deploy process 'monit reload' is called
as root. However at this moment, /var/vcap/bosh/etc/monitrc is owned by
vcap:vcap, and monit complains.

I chowned /var/vcap/bosh/etc/monitrc to root:root and relaunched bosh -n
deploy. Deployment succeeded.

Then, I checked again permissions on this file, and it has been chown'ed
back to vcap:vcap, so I'm pretty sure the next deployment will fail again
because of the same previous error.
Can you help us on this?

Best regards,

Vincent


On Fri, Sep 11, 2015 at 12:12 PM Cyrille Le Clerc <cleclerc(a)cloudbees.com>
wrote:

Dear all,

To give more details,

* We understand that monit should run the control scripts as root - see
https://bosh.io/docs/vm-monit.html
* we have the feeling that on PCF 1.5.2 for AWS + stemcell ubuntu-3062,
monit is executed with different a user dependending on whether monit runs
for the first time on the server (creating a new server during a bosh
deploy) or restarts (updating the server during a bosh deploy).


We have a problem when monit tries to execute "docker_ctl" (1) during a
"bosh deploy" that updates an existing server

In /var/vcap/data/sys/log/monit/docker.err.log, we have "dpkg: error:
requested operation requires superuser privilege"

This lets us think that this docker_ctl is executed by monit as "vcap"
and not as root.

Cyrille


(1)
https://github.com/cf-platform-eng/docker-boshrelease/blob/master/jobs/docker/templates/bin/docker_ctl


On Fri, Sep 11, 2015 at 10:32 AM, Vincent Latombe <vlatombe(a)cloudbees.com>
wrote:

Hi,

I'm trying to debug an issue related to one of my jobs and I just want

a clarification regarding what user 'monit' is run as when executing the
bosh deployment.

My current environment, if that helps : PCF 1.5.2 - Stemcell 3062

In the documentation (https://bosh.io/docs/vm-monit.html#using-monit),

it seems monit is expected to run as root, but when ssh'ing to the box then
open a shell as root, 'monit summary' gives me back

monit: The control file '/var/vcap/bosh/etc/monitrc' must be owned by

you.

Indeed, /var/vcap/bosh/etc/monitrc is owned by user 'vcap'.

Thank you for your advices,

--
Cyrille Le Clerc
email & gtalk : cleclerc(a)cloudbees.com / mob: +33-6.61.33.69.86 / skype:
cyrille.leclerc
CloudBees, Inc
www.cloudbees.com

--

Vincent

--
Vincent

Hello again,

it seems like our manual fiddling on the server had led us to a wrong
direction. What we are actually experiencing :

- On a fresh deploy (new stemcell, new package), we get a successful
deployment
- On a config change in our package (any change actually), the 'bosh -n
deploy' fails.

From the logs after execution of bosh -n deploy, I found the following

bosh/log/@4000000055f2e2d51f95c6fc.s:2015-09-11_14:13:23.92877 [Cmd Runner]
2015/09/11 14:13:23 DEBUG - /var/vcap/bosh/bin/monit Stderr: monit: The
control file '/var/vcap/bosh/etc/*monitrc*monitrc' must be owned by you.

bosh/log/@4000000055f2e2d51f95c6fc.s:2015-09-11_14:13:23.92880
[monitJobSupervisor] 2015/09/11 14:13:23 ERROR - Failed to reload monit
Running command: 'monit reload', stdout: '', stderr: 'monit: The control
file '/var/vcap/bosh/etc/monitrc*monitrc*' must be owned by you.

As I undertand it, as part of the deploy process 'monit reload' is called
as root. However at this moment, /var/vcap/bosh/etc/monitrc is owned by
vcap:vcap, and monit complains.

I chowned /var/vcap/bosh/etc/monitrc to root:root and relaunched bosh -n
deploy. Deployment succeeded.

Then, I checked again permissions on this file, and it has been chown'ed
back to vcap:vcap, so I'm pretty sure the next deployment will fail again
because of the same previous error.
Can you help us on this?

Best regards,

Vincent


On Fri, Sep 11, 2015 at 12:12 PM Cyrille Le Clerc <cleclerc(a)cloudbees.com>
wrote:

Dear all,

To give more details,

* We understand that monit should run the control scripts as root - see
https://bosh.io/docs/vm-monit.html
* we have the feeling that on PCF 1.5.2 for AWS + stemcell ubuntu-3062,
monit is executed with different a user dependending on whether monit runs
for the first time on the server (creating a new server during a bosh
deploy) or restarts (updating the server during a bosh deploy).


We have a problem when monit tries to execute "docker_ctl" (1) during a
"bosh deploy" that updates an existing server

In /var/vcap/data/sys/log/monit/docker.err.log, we have "dpkg: error:
requested operation requires superuser privilege"

This lets us think that this docker_ctl is executed by monit as "vcap" and
not as root.

Cyrille


(1)
https://github.com/cf-platform-eng/docker-boshrelease/blob/master/jobs/docker/templates/bin/docker_ctl


On Fri, Sep 11, 2015 at 10:32 AM, Vincent Latombe <vlatombe(a)cloudbees.com>
wrote:

Hi,

I'm trying to debug an issue related to one of my jobs and I just want a

clarification regarding what user 'monit' is run as when executing the bosh
deployment.

My current environment, if that helps : PCF 1.5.2 - Stemcell 3062

In the documentation (https://bosh.io/docs/vm-monit.html#using-monit),

it seems monit is expected to run as root, but when ssh'ing to the box then
open a shell as root, 'monit summary' gives me back

monit: The control file '/var/vcap/bosh/etc/monitrc' must be owned by

you.

Indeed, /var/vcap/bosh/etc/monitrc is owned by user 'vcap'.

Thank you for your advices,

--
Cyrille Le Clerc
email & gtalk : cleclerc(a)cloudbees.com / mob: +33-6.61.33.69.86 / skype:
cyrille.leclerc
CloudBees, Inc
www.cloudbees.com

--

Vincent

Dear all,

To give more details,

* We understand that monit should run the control scripts as root - see
https://bosh.io/docs/vm-monit.html
* we have the feeling that on PCF 1.5.2 for AWS + stemcell ubuntu-3062,
monit is executed with different a user dependending on whether monit runs
for the first time on the server (creating a new server during a bosh
deploy) or restarts (updating the server during a bosh deploy).


We have a problem when monit tries to execute "docker_ctl" (1) during a
"bosh deploy" that updates an existing server

In /var/vcap/data/sys/log/monit/docker.err.log, we have "dpkg: error:
requested operation requires superuser privilege"

This lets us think that this docker_ctl is executed by monit as "vcap" and
not as root.

Cyrille


(1)
https://github.com/cf-platform-eng/docker-boshrelease/blob/master/jobs/docker/templates/bin/docker_ctl

On Fri, Sep 11, 2015 at 10:32 AM, Vincent Latombe <vlatombe(a)cloudbees.com>
wrote:

Hi,

I'm trying to debug an issue related to one of my jobs and I just want a

clarification regarding what user 'monit' is run as when executing the bosh
deployment.

My current environment, if that helps : PCF 1.5.2 - Stemcell 3062

In the documentation (https://bosh.io/docs/vm-monit.html#using-monit), it

seems monit is expected to run as root, but when ssh'ing to the box then
open a shell as root, 'monit summary' gives me back

monit: The control file '/var/vcap/bosh/etc/monitrc' must be owned by you.

Indeed, /var/vcap/bosh/etc/monitrc is owned by user 'vcap'.

Thank you for your advices,

--
Cyrille Le Clerc
email & gtalk : cleclerc(a)cloudbees.com / mob: +33-6.61.33.69.86 / skype:
cyrille.leclerc
CloudBees, Inc
www.cloudbees.com

Hi,

I'm trying to debug an issue related to one of my jobs and I just want a clarification regarding what user 'monit' is run as when executing the bosh deployment.

My current environment, if that helps : PCF 1.5.2 - Stemcell 3062

In the documentation (https://bosh.io/docs/vm-monit.html#using-monit), it seems monit is expected to run as root, but when ssh'ing to the box then open a shell as root, 'monit summary' gives me back
monit: The control file '/var/vcap/bosh/etc/monitrc' must be owned by you.

Indeed, /var/vcap/bosh/etc/monitrc is owned by user 'vcap'.

Thank you for your advices,

Hi, I am using 3029...I am unable to export it..It always gives me following error..Please advise

[root(a)ip-172-31-38-160 releases]# bosh export release cf/215 ubuntu-trusty/3029

Director task 624
Error 30011: Release cf/215 not found in deployment cf manifest

[root(a)ip-172-31-38-160 releases]# bosh releases
Acting as user 'admin' on 'bosh'

+------+----------+-------------+
| Name | Versions | Commit Hash |
+------+----------+-------------+
| cf | 215* | 2a4897df+ |
+------+----------+-------------+
(*) Currently deployed
(+) Uncommitted changes

Releases total: 1
[root(a)ip-172-31-38-160 releases]# bosh stemcells
Acting as user 'admin' on 'bosh'

+-----------------------------------------+---------------+---------+--------------------+
| Name | OS | Version | CID |
+-----------------------------------------+---------------+---------+--------------------+
| bosh-aws-xen-hvm-ubuntu-trusty-go_agent | ubuntu-trusty | 3029* | ami-49e04522 light |
| bosh-aws-xen-ubuntu-trusty-go_agent | ubuntu-trusty | 3000 | ami-6bf50e00 light |
| bosh-aws-xen-ubuntu-trusty-go_agent | ubuntu-trusty | 3029 | ami-cd97f9a8 |
+-----------------------------------------+---------------+---------+--------------------+

(*) Currently in-use

Stemcells total: 3
[root(a)ip-172-31-38-160 releases]# bosh deployments
Acting as user 'admin' on 'bosh'

+------+------------+----------------------------------------------+--------------+
| Name | Release(s) | Stemcell(s) | Cloud Config |
+------+------------+----------------------------------------------+--------------+
| cf | cf/215 | bosh-aws-xen-hvm-ubuntu-trusty-go_agent/3029 | none |
+------+------------+----------------------------------------------+--------------+

Deployments total: 1
[root(a)ip-172-31-38-160 releases]# bosh deployment
Current deployment is `/opt/cf/bosh/releases/cf-release/cf_np.yml'

like https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/bosh-lite-stubs/iaas-settings.yml

I just deployed cloud foundry in vsphere. I can cf login,create org, space etc. I can push app with —no -start flag. However, I cannot start the app. Once I start the app, “cf apps” does not work.(cf login still works). But after some time, the “cf apps” lists the apps until I again try to start the app.

The same app works fine when I deploy to bosh lite.

guests-MacBook-Pro:apps rsamban$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
first.jar started 0/1 1G 1G firstjar.192.168.1.103.xip.io
guests-MacBook-Pro:apps rsamban$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
first.jar started 0/1 1G 1G firstjar.192.168.1.103.xip.io
guests-MacBook-Pro:apps rsamban$ cf start first.jar
App first.jar is already started
guests-MacBook-Pro:apps rsamban$ cf restage first.jar
Restaging app first.jar in org yesVin / space dev as admin...
Warning: error tailing logs
Unauthorized error: You are not authorized. Error: Invalid authorization
FAILED
Server error, status code: 400, error code: 170001, message: Staging error: no available stagers

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$ 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$ cf apps
Getting apps in org yesVin / space dev as admin...
OK

name requested state instances memory disk urls
first.jar started 0/1 1G 1G firstjar.192.168.1.103.xip.io

I searched the log files of all the vms for errors (Search for "no available stagers”, "Invalid authorization" and "An unknown error occurred" strings in all the bosh jobs).
I can see “no available stagers” message in /var/vcap/sys/logs/cloud_controller_ng/cloud_controller_ng.log in api_z1 and other two strings are not found in any of the logs.

How would I find the problem. Not sure what I am missing.

Below are my logs and cf manifest.
https://gist.github.com/6c81bed0d8eb888da970.git

Can somebody help me,

thanks
Ramesh

Apologize if it is too much clutter, I wish the mailing list supports some kind of formatting (like markdown)

Lovely

On Thu, Sep 10, 2015 at 8:49 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Yes.
Sent from my iPhone

On Sep 10, 2015, at 8:28 AM, Dr Nic Williams <drnicwilliams(a)gmail.com> wrote:

Networking will be like normal networks? Rather than one /30 per job?

On Thu, Sep 10, 2015 at 8:23 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:
Networking configuration should be simpler as this would allow usage of bigger than /30 subnets. Otherwise everything stays the same, unless btrfs makes things faster.

Sent from my iPhone

On Sep 10, 2015, at 8:19 AM, Dr Nic Williams <drnicwilliams(a)gmail.com> wrote:

Will garden bring any new features/stability to bosh-lite?

On Thu, Sep 10, 2015 at 8:15 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:
Bosh-lite pipeline got moved to the main bosh CI: https://main.bosh-ci.cf-app.com/pipelines/bosh-lite

I'm making changes to bosh-lite to use official garden-linux release, and I'll update the README shortly.

Sent from my iPhone

On Sep 10, 2015, at 6:31 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The bosh-lite README points to http://lite.bosh-ci.cf-app.com:8080 as the concourse instance for CI. Can someone please verify that link as I'm unable to access it.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com

Hi all!

Two things about our upcoming CF Summit EU and CF Summit China:

Key dates for both... (The call for talk proposals for both are closing
soon):

*CF Summit EU - November 2nd & 3rd - Berlin*
CFP Closed: September 11, 2015 - http://berlin2015.cfsummit.com/program/cfp
CFP Notifications: September 29, 2015
Schedule Announced: October 1, 2015
Event Dates: November 2-3, 2015

*CF Summit China - December 2nd & 3rd - Shanghai*
CFP Closed: September 25, 2015 -
http://shanghai2015.cfsummit.com/program/cfp
CFP Notifications: October 13, 2015
Schedule Announced: October 15, 2015
Event Dates: December 2 & 3, 2015

For these events, we are providing a 25% discount code for registration to
contributors of CF projects. This is "trust-based", in that I'm sharing on
public lists. If you have contributed to the development of a CF project in
any way (docs, code, feature comments), feel free to use these codes.

Berlin: CFEU15CON

Shanghai: CFAS15CON


Chip Childers | VP Technology | Cloud Foundry Foundation

Yes.

Sent from my iPhone

Networking will be like normal networks? Rather than one /30 per job?

On Thu, Sep 10, 2015 at 8:23 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Networking configuration should be simpler as this would allow usage of bigger than /30 subnets. Otherwise everything stays the same, unless btrfs makes things faster.
Sent from my iPhone

On Sep 10, 2015, at 8:19 AM, Dr Nic Williams <drnicwilliams(a)gmail.com> wrote:

Will garden bring any new features/stability to bosh-lite?

On Thu, Sep 10, 2015 at 8:15 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:
Bosh-lite pipeline got moved to the main bosh CI: https://main.bosh-ci.cf-app.com/pipelines/bosh-lite

I'm making changes to bosh-lite to use official garden-linux release, and I'll update the README shortly.

Sent from my iPhone

On Sep 10, 2015, at 6:31 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The bosh-lite README points to http://lite.bosh-ci.cf-app.com:8080 as the concourse instance for CI. Can someone please verify that link as I'm unable to access it.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com