May I go further and ask that snapshots be kept after bosh delete deployment, but be also garbage collected after retention period? Also asking for a friend, I never accidentally deleted data either.

Aristoteles Neto
dds.neto(a)gmail.com

Great idea. Can I request that disks are kept in the same garbage collection pool after "bosh delete deployment"? Asking for a friend. I definitely never accidentally deleted production data.

On Wed, Sep 30, 2015 at 3:19 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Summary: We want to avoid accidental data loss so we are thinking to keep
persistent disks around after deployment is modified. Persistent disks will
be regularly garbage collected and you can potentially reattach disks if
necessary.
https://github.com/cloudfoundry/bosh-notes/blob/master/persistent-disk-mgmt.md
Thoughts?

Summary: We want to avoid accidental data loss so we are thinking to keep
persistent disks around after deployment is modified. Persistent disks will
be regularly garbage collected and you can potentially reattach disks if
necessary.

https://github.com/cloudfoundry/bosh-notes/blob/master/persistent-disk-mgmt.md

Thoughts?

This is apparently the same issue as in "Warning: don't use bosh-init with Ruby 1.9.3. " (https://github.com/cloudfoundry/bosh-init/pull/46)

Hi, I'm a total newbie.
I've been following the instructions on http://bosh.io/docs/init-aws.html for deploying CF on AWS. I've used the same settings expect for the time-zone which "us-east-1b" and I've updated the bosh.yml accordingly.

The log for "bosh-init deploy ./bosh.yml" can be seen below (I just couldn't get a clue this time):

ubuntu(a)ip-10-0-0-194:~/my-bosh$ bosh-init deploy ./bosh.yml
Deployment manifest: '/home/ubuntu/my-bosh/bosh.yml'
Deployment state: '/home/ubuntu/my-bosh/bosh-state.json'

Started validating
Downloading release 'bosh'... Skipped [Found in local cache] (00:00:00)
Validating release 'bosh'... Finished (00:00:04)
Downloading release 'bosh-aws-cpi'... Skipped [Found in local cache] (00:00:00)
Validating release 'bosh-aws-cpi'... Finished (00:00:00)
Validating cpi release... Finished (00:00:00)
Validating deployment manifest... Finished (00:00:00)
Downloading stemcell... Skipped [Found in local cache] (00:00:00)
Validating stemcell... Finished (00:00:00)
Finished validating (00:00:05)

Started installing CPI
Compiling package 'ruby_aws_cpi/a5b66d011ce1b31642ff148ea2c9097af65ff78c'... Finished (00:02:01)
Compiling package 'bosh_aws_cpi/0a3d63be846294c825914d40800b738323359fab'... Finished (00:01:12)
Installing packages... Finished (00:00:03)
Rendering job templates... Finished (00:00:00)
Installing job 'cpi'... Finished (00:00:00)
Finished installing CPI (00:03:18)

Starting registry... Finished (00:00:00)
Uploading stemcell 'bosh-aws-xen-hvm-ubuntu-trusty-go_agent/3012'... Finished (00:00:05)

Started deploying
Creating VM for instance 'bosh/0' from stemcell 'ami-5728e73c light'... Finished (00:00:44)
Waiting for the agent on VM 'i-0f540aaf' to be ready... Finished (00:01:41)
Creating disk... Finished (00:00:20)
Attaching disk 'vol-2c8824d6' to VM 'i-0f540aaf'... Finished (00:00:25)
Rendering job templates... Failed (00:00:00)
Failed deploying (00:03:12)

Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)

Command 'deploy' failed:
Deploying:
Building state for instance 'bosh/0':
Rendering job templates for instance 'bosh/0':
Rendering templates for job 'director/abad62506b6f8b419fdc8f42a9e9967045057b45':
Rendering template src: director.yml.erb.erb, dst: config/director.yml.erb:
Rendering template src: /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/bosh-init-release355238454/extracted_jobs/director/templates/director.yml.erb.erb, dst: /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/rendered-jobs027702391/config/director.yml.erb:
Running ruby to render templates:
Running command: 'ruby /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/erb-renderer802392987/erb-render.rb /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/erb-renderer802392987/erb-context.json /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/bosh-init-release355238454/extracted_jobs/director/templates/director.yml.erb.erb /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/rendered-jobs027702391/config/director.yml.erb', stdout: '', stderr: '/home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/erb-renderer802392987/erb-render.rb:180:in `rescue in render': Error filling in template '/home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/bosh-init-release355238454/extracted_jobs/director/templates/director.yml.erb.erb' for director/0 (line 136: #<JSON::GeneratorError: only generation of JSON objects or
arrays allowed>) (RuntimeError)
from /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/erb-renderer802392987/erb-render.rb:166:in `render'
from /home/ubuntu/.bosh_init/installations/c1c25dc7-ba60-4606-70d6-820fd4083e46/tmp/erb-renderer802392987/erb-render.rb:191:in `<main>'
':
exit status 1

The short answer is “yes”. Yes, BOSH blocks the whole deployment while you run errand [1].

As far as I see, the main reason hear is consideration that BOSH errand job can perform operations on deployment. For instance you can take admin-ui tool, that use errand job to register himself into UAA [2]. Performing any updates on the deployment that runs errands can cause errors that are hard to debug.

[1] https://github.com/cloudfoundry/bosh/blob/dad748d39a1e4b9558b7ee7f72661657d1729d9e/bosh-director/lib/bosh/director/jobs/run_errand.rb#L28
[2] https://github.com/cloudfoundry-community/admin-ui-boshrelease/tree/master/jobs/register_admin_ui

Best Regards,
Alex L.

Gwenn,

is the any list of bosh tasks that require a lock available?

Why do we need to lock running different errands? They are independent.

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov
www.altoros.com <http://www.altoros.com/> | blog.altoros.com <http://blog.altoros.com/> | twitter.com/altoros <http://twitter.com/altoros>

Yes except this kind of task .. bosh deploy lock for example...


On Wed, Sep 30, 2015 at 4:13 PM, Aleksey Zalesov <
aleksey.zalesov(a)altoros.com> wrote:

Bosh doesn’t lock on any task - while running tests I can list vms using
`bosh vms` and ssh to vm using `bosh ssh`.

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov
www.altoros.com | blog.altoros.com | twitter.com/altoros

On 30 Sep 2015, at 04:12, Gwenn Etourneau <getourneau(a)pivotal.io> wrote:

I will say no, bosh lock for any task and running errand is a task.

On Tue, Sep 29, 2015 at 9:54 PM, Aleksey Zalesov <
aleksey.zalesov(a)altoros.com> wrote:

Hello!

Can I run two bosh errands simultaneously?

Currently I get `Error 100: Bosh::Director::Lock::TimeoutError` when
trying to run the second errand while the first errand is running.

Bosh doesn’t lock on any task - while running tests I can list vms using `bosh vms` and ssh to vm using `bosh ssh`.

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov
www.altoros.com <http://www.altoros.com/> | blog.altoros.com <http://blog.altoros.com/> | twitter.com/altoros <http://twitter.com/altoros>

I will say no, bosh lock for any task and running errand is a task.

On Tue, Sep 29, 2015 at 9:54 PM, Aleksey Zalesov <
aleksey.zalesov(a)altoros.com> wrote:

Hello!

Can I run two bosh errands simultaneously?

Currently I get `Error 100: Bosh::Director::Lock::TimeoutError` when
trying to run the second errand while the first errand is running.

Hi all,

I'd like to propose tuning a couple kernel parameters related to tcp
performance:

# TCP_FIN_TIMEOUT
# This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse
# its resources. During this TIME_WAIT state, reopening the connection to
the client costs less than establishing
# a new connection. By reducing the value of this entry, TCP/IP can release
closed connections faster, making more
# resources available for new connections. Adjust this in the presence of
many connections sitting in the
# TIME_WAIT state:

echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout

# TCP_TW_REUSE
# This allows reusing sockets in TIME_WAIT state for new connections when
it is safe from protocol viewpoint.
# Default value is 0 (disabled). It is generally a safer alternative to
tcp_tw_recycle

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Currently, these parameters are set by certain jobs in cf-release,
diego-release, and perhaps others. Any VM needing to establish a high
number of incoming/outgoing tcp connections in a short period of time will
be unable to establish new connections without changing these parameters.

We believe these parameters are safe to change across the board, and will
be generally beneficial. The existing defaults made sense for much older
networks, but can be greatly optimized for modern systems.

Please share with the mailing lists if you have any questions or feedback
about this proposal. If you maintain a bosh release and would like to see
how these changes would affect your release, you can create a job which
simply does the above in its startup scripts, and colocate that job with
all the other jobs in a deployment of your release.

Thanks,

Amit Gupta
Cloud Foundry PM, OSS Release Integration team

Hello!

Can I run two bosh errands simultaneously?

Currently I get `Error 100: Bosh::Director::Lock::TimeoutError` when trying to run the second errand while the first errand is running.

I have changed resource pool size for small_errand from 1 to 2 and run `bosh deploy`. Before change I have run `bosh deploy` and verified that no pending changes are available (actually, then I canceled task).

I expect bosh to resize errand pool only. But before it updated health_z1 job from medum_z1 pool that was unchanged.

Can you explain this behaviour? How can I learn what changes bosh is going to implement (e.g. terraform plan)?

Hi Marco,

Thank you Marco! Yes indeed, the problem in the Github issue is the exact same Problem I have.

The provided solution in the issue works. Thanks for referencing me to the Github issue and your fast answer.

Bests,
Fabian

From: "Voelz, Marco" <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>>
Reply-To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Date: Monday, September 28, 2015 at 8:22 PM
To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Subject: [cf-bosh] Re: bosh ssh sudo commands

Dear Fabian,

your problem might be the same as seen in this github issue: https://github.com/cloudfoundry/bosh/issues/964<https://github.com/cloudfoundry/bosh/issues/964#event-420594944>

`bosh ssh` sets up users which need a password to execute `sudo`. Therefore, you would need to provide the password on the commandline in which you want to execute the command, just as Dmitriy answered in the github issue.

Until the users are setup with password-less sudo, this is pretty much the best you can do, I guess.

Warm regards
Marco

We have made IAM instance profile support available in latest
bosh-aws-cpi-release. See
https://bosh.io/docs/aws-iam-instance-profiles.html on how to use it.

Dear Fabian,

your problem might be the same as seen in this github issue: https://github.com/cloudfoundry/bosh/issues/964<https://github.com/cloudfoundry/bosh/issues/964#event-420594944>

`bosh ssh` sets up users which need a password to execute `sudo`. Therefore, you would need to provide the password on the commandline in which you want to execute the command, just as Dmitriy answered in the github issue.

Until the users are setup with password-less sudo, this is pretty much the best you can do, I guess.

Warm regards
Marco

I have a 2 job (vm) deployment, client and server. In the client, I'm referencing the server host via <index>.<job>.<network>.<deployment>.microbosh, ex. 0.serverNode.default.client-server-deployment.microbosh.

This all works great. I was testing Bosh handling of failover, so I killed the server vm. Bosh correctly restarted the vm. The VM came up with a new IP address.

However, the dns entry for that hostname was not changed after the restart. Now, my client can't connect to the server via that name.

Is this expected behavior? Am I doing something wrong?

Hi bosh-freaks,

I do have a technical bosh question regarding bosh ssh . I am curious if you do have any solutions to the problem below or ideas for alternative. Please let me know in case this is the wrong mailing list.

I am currently trying to automate the recovery of an existing snapshot. The snapshot is a backup for a my own bosh-release for a database technology. The boshrelease will have OpenStack as IaaS. I am using several cinder/nova commands (Openstack specific) and then I want to execute several commands on the bosh-vm. Therefore I do need to execute several commands on the bosh-VM where the database is running from the host VM.

In order to do that, I am using bosh ssh "<command>" for example

bosh ssh mongodb/0 “echo blub”

This is working perfectly fine. However, when I automate the recovery a backup, there are a few commands that do need root access. One command could be this one, for example:

bosh ssh mongodb/0 "sudo mount -t ext4 /dev/vdc1 /var/vcap/store_snapshot”

Unfortunately, this is not working. I get a error

sudo: no tty present and no askpass program specified

Does anyone have any help/ideas on how to solve this issue?
Am I using bosh ssh in the wrong way?
Is bosh ssh not made to execute such commands?
Can I solve this by writing an errand and calling the errand in automation script?

I am happy about every idea that helps me solving this issue or letting me better understand the problem.

Thanks a lot in advance,
Cheers,
Fabian

Still very interested in getting this working.
I hope the hiccups pass soon!

Tom

On Fri, Sep 25, 2015 at 1:57 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

We had a hiccup in our CI pipeline regarding this feature. Will update as
soon we have it.

Sent from my iPhone

On Sep 19, 2015, at 4:48 AM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

Hi,

How can AWS temporary security credentials be used with bosh in place of

the access_key_id and secret_access_key? Reviewing manifests and
documentation, I find no mention of aws_session_token. How would bosh
refresh the token? Does an IAM role on the instance make it work?

I'm just diving into the AWS identity and access area. A kickstart in

the right direction, much appreciated.

(I've successfully deployed bosh/cf in an AWS regular account. I am now

switching to a federated and temporary security creds environment.)

We had a hiccup in our CI pipeline regarding this feature. Will update as soon we have it.

Sent from my iPhone