cloudfoundry / docs-bosh Goto Github PK

https://bosh.io/docs/job-logs.html#errand-logs

V2 schema docs for 'releases':

https://bosh.io/docs/manifest-v2.html#releases

There is no mention of attributes 'url' and 'sha1' although these seem to be valid (used in the cf manifest at least: https://github.com/cloudfoundry/cf-deployment/blob/master/cf-deployment.yml )

The docs in this section, generate certs that use
Signature Algorithm: sha1WithRSAEncryption. Among other things it also sends yes "" for all answers for certificate generation input. It should use sha256 at least.

/cc @ishustava @bblincoe @bijukunjummen

The bosh_cli instructions mention that ruby 2+ is required, but the instructions for Ubuntu trusty install ruby 1.9.

Instead of ruby and ruby-dev, ruby2.0 and ruby2.0-dev should be installed. Instead of calling gem to install, gem2.0 should be used.

I followed instructions in this tutorial and all cf instances have only private ip. So they can't download buildpacks and use S3 storage.

To prevent this user should explicitly change Auto-assign Public IP subnet property to yes.

On the tips page (https://bosh.io/docs/tips.html) about debugging "unreachable vms", there is mention about a "plan to introduce a feature in the Director to leave unreachable VMs for easier debugging". This feature exists and the text should be updated and point to this page:

https://bosh.io/jobs/director?source=github.com/cloudfoundry/bosh#p=director.debug.keep_unreachable_vms

The elastic IP required by the AWS docs (https://github.com/cloudfoundry/docs-bosh/blob/master/init-aws.html.md.erb) seem to be superfluous; is that correct?

On [this page][http://docs.cloudfoundry.org/bosh/deploy-microbosh-to-aws.html] under the Create a Virtual Private Cloud header the flow for the wizard has changed substantially and has become much simpler. Here is a screenshot of the new style:

BOSH post deployments api returns back task and isn't a redirect to new url

https://bosh.io/docs/director-api-v1.html#post-deployment

From cloudfoundry/cf-docs#210:

Here docs/running/bosh/reference/jobs.html.md mentioned the “prepare" script, but didn't mention the "post_install" script which gets invoked after BOSH Agent installs the job. This script might be very helpful for some cases which need to do some post install work.

Here is the implementation: https://github.com/cloudfoundry/bosh/blob/master/bosh_agent/lib/bosh_agent/apply_plan/job.rb#L145

/cc @JimmyMa

As discussed on https://groups.google.com/a/cloudfoundry.org/d/msg/bosh-users/RHFPYaEy9FE/SKEo8SAICskJ

The bosh sample manifest has invalid default disk sizing

The net effect is that stemcell upload and release upload fail (silently), making it harder for new users to debug and diagnose the issue.

 $ bosh upload stemcell ~/code/bosh-stemcell-1471_2-vsphere-esxi-ubuntu.tgz 
Verifying stemcell...
File exists and readable                                     OK
Verifying tarball...
Read tarball                                                 OK
Manifest exists                                              OK
Stemcell image file                                          OK
Stemcell properties                                          OK
Stemcell info
-------------
Name:    bosh-vsphere-esxi-ubuntu
Version: 1471.2
Checking if stemcell already exists...
No
Uploading stemcell...
bosh-stemcell: 100% |ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo| 395.9MB 617.5KB/s Time: 00:10:56

gberche@ruby-desktop2 ~/code/integration-configuration-reference/configuration-reference-qa/bosh/deployments/cf04 (master) $ bosh stemcells
No stemcells
gberche@ruby-desktop2 ~/code/integration-configuration-reference/configuration-

What about moving the sample manifests out of docs-bosh into https://github.com/cloudfoundry/bosh/tree/master/release/examples and make sure that they get tested as part of CI ?

Also wouldn't it be safer to suggest new users to use ubuntu stemcells rather than centos ones on which there might be less confidences (I'm not sure how to read the status of the centos epic on https://www.pivotaltracker.com/s/projects/956238 and whether it's actually complete)

The page https://bosh.io/docs/init-azure.html references STORAGE-ACCESS-KEY in Step 2 but the sample manifest does not contain that placeholder.

This line states that Jobs never depend on other jobs. But with the introduction of links, seems a bit misleading.

Hey, all.

I've always wanted to ask if you are planning to add tags for BOSH versions to your docs? Sometimes it is hard to keep track of the version of BOSH that is described in articles. Hope this will solve this problem.

Thank you,
Alex L.

We use:

https://github.com/pivotal-cf-experimental/bosh-bootloader/blob/fbb54ff/aws/cloudformation/templates/bosh_iam_template_builder.go#L17-L52

Copied from:

http://bosh.io/docs/aws-iam-users.html#create (Step 10)

Needed to add stuff around registering image.

Original issue that surfaced this:

cloudfoundry/bosh-bootloader#16

Hi,
The name of the director suggested in this example:
https://github.com/cloudfoundry/docs-bosh/blob/master/bosh-lite.html.md.erb#L52
is not compatible with Credhub - if you add Credhub to your bosh deployment and then try to deploy something using Credhub to generates credentials, it fails because by default credentials will be located under /director_name/deployment_name/credential_name and "Bosh Lite Director" is not a valid path (spaces are not allowed).

The docs for the CLI V2 clearly state that the V2 cli ignores this attribute:

bosh deploy no longer checks or requires director_uuid in the deployment manifest to achieve similar safety make sure to give unique deployment names across environments

This is in contradiction with what the schema docs are saying:

Here: https://bosh.io/docs/deployment-manifest.html#deployment
and here: https://bosh.io/docs/manifest-v2.html#deployment

director_uuid [String, required]: This string must match the UUID of the currently targeted Director for the CLI to allow any operations on the deployment.

I'm guessing this is at least wrong for the V2 schema, not so sure about the V1 schema. Please clarify the docs around when, if ever, the director_uuid property is required.

Hi -

Trying to create a concourse / BOSH on a GCP VM. Would work, except that VT-X isn't available, so the process fails with:

Deploying:
Creating instance 'concourse/0':
Creating VM:
Creating vm with stemcell cid 'sc-275e94b1-daf9-4b1d-5d80-a272d93994e4':
CPI 'create_vm' method responded with error: CmdError{"type":"Bosh::Clouds::CloudError","message":"Creating VM with agent ID '{{b3afbdc5-52dc-4300-62ac-9819f32f2708}}': Starting VM: Retried '30' times: Running command: 'VBoxManage startvm vm-8263717c-e371-4bf8-6ef1-62e75e6a9121 --type headless', stdout: 'Waiting for VM "vm-8263717c-e371-4bf8-6ef1-62e75e6a9121" to power on...\n', stderr: 'VBoxManage: error: VT-x is not available (VERR_VMX_NO_VMX)\nVBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole\n': exit status 1","ok_to_retry":false}

Exit code 1

Unfortunately I can't manually modify the VM once it is in the loop for starting. Is there any way to insert the appropriate "VBoxManage modifyvm.. " commands after creating the VM but before starting it? There is no way to define a global default for no VT-X on vbox.

It would be nice to have this documented, as well as some explanation of the nuances around what this means in practice when there are multiple AZs. In fact, those nuances even for the integer (non-percentage) case would be nice to have documented as well.

All the major components of bosh are defined under bosh-components.html.md.erb. Currently this is reference under 'Running Director' as 'General Architecture' in table of contents. It will be helpful for someone starting with bosh to get an overview of general architecture before creating an environment.

The template file used for OpenStack needs a property tenant to work properly. The tenant is apparently the same as project, so maybe this changed and project is no longer required?

I found it quite hard to find docs for google-cpi on the site, the docs are there - they are just not linked to.

In the documentation [1] the REST endpoint of "/events", which outputs the same as "bosh events" is not documented. Is this by intentation or simply missing ?

http://docs.cloudfoundry.org/bosh/create-manifest.html#networks is currently lacking some useful Iaas independent details that are still available at
https://github.com/cloudfoundry-attic/oss-docs/blob/master/bosh/documentation/bosh_deployments.md#network-spec such as the difference between manual and dynamic networks, and the static and dynamic ip pools

The Iaas specific pages don't document these common parts

Had a question from a release developer—they followed the create-release doc which suggests they use a local blobstore, but then were getting ready to share their release outside their workstation. Suggested S3 and following s3-create-release, but there's no docs guiding how to switch blobstore. I think it's not just bosh upload blobs since blobs/* is full of symlinks already.

The sample manifest includes private_key: ./bosh.pem # Path relative to this manifest file. However, if we put the path as relative to the manifest and run bosh-init from a different directory, it fails. When we cd into the correct directory and do not modify our manifest, it works.

I would expect bosh-init deploy to work regardless of where my $PWD is, or for the comment in the manifest to specify that the $PWD is important.

The relevant part of my manifest is:

  ssh_tunnel:
    host: 52.0.17.215 # <--- Replace with your Elastic IP address
    port: 22
    user: vcap
    private_key: keypair/bosh2.pem # Path relative to this manifest file

The terminal output showing the error, fix, and correct behavior is:

in ~/workspace/my-project
→ bosh-init deploy my-environment/deployments/bosh/bosh.yml
Deployment manifest: '/Users/my-user/workspace/my-project/my-environment/deployments/bosh/bosh.yml'
Deployment state: '/Users/my-user/workspace/my-project-/my-environment/deployments/bosh/bosh-state.json'

[output trimmed]

Started deploying
  Deleting VM 'i-44b538ad'... Skipped [VM not found] (00:00:08)
  Creating VM for instance 'bosh/0' from stemcell 'ami-5728e73c light'... Finished (00:00:50)
  Waiting for the agent on VM 'i-9054643c' to be ready... Failed (00:00:00)
Failed deploying (00:01:06)

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

Command 'deploy' failed:
  Deploying:
    Creating instance 'bosh/0':
      Waiting until instance is ready:
        Starting SSH tunnel:
          Reading private key file '/Users/my-user/workspace/my-project/keypair/bosh2.pem':
            open /Users/my-user/workspace/my-project/keypair/bosh2.pem: no such file or directory

in ~/workspace/my-project
± dw+gc |master ↑1 S:3 U:7 ?:1 ✗| → cd my-environment/

in ~/workspace/my-project/my-environment
± dw+gc |master ↑1 S:3 U:7 ?:1 ✗| → bosh-init deploy deployments/bosh/bosh.yml
Deployment manifest: '/Users/my-user/workspace/my-project/my-environment/deployments/bosh/bosh.yml'
Deployment state: '/Users/my-user/workspace/my-project/my-environment/deployments/bosh/bosh-state.json'

[output trimmed]

Started deploying
  Waiting for the agent on VM 'i-9054643c'... Failed (00:00:09)
  Deleting VM 'i-9054643c'... Finished (00:01:12)
  Creating VM for instance 'bosh/0' from stemcell 'ami-5728e73c light'... Finished (00:00:51)
  Waiting for the agent on VM 'i-d4417178' to be ready... Finished (00:01:43)

[output trimmed]

The cloud config page states "Warning: Once you opt into using cloud config all deployments must be converted to use new format. There is no way to opt out of the cloud config once you opt in.".

We were using director v257.3 (the latest at the time of writing) and found that this does not seem to be true, we can redeploy old-style (no cloud config) manifests once cloud config has been uploaded.

i.e. this isn't documented on http://bosh.io/docs/deployment-manifest.html#releases

The doc says that it is required here:

But this sample file, which I assume is a correct manifest has an example where 'properties' is not specified. So I gather that 'properties' isn't really required:

...
  jobs:
  - name: consul_agent
    release: consul
    consumes:
      consul_common: {from: consul_common_link}
      consul_server: nil
      consul_client: {from: consul_client_link}
  - name: nats
...

Hi,

On the way to run a bosh-init on my OpenStack Icehouse platform, I've encountered this error:

Command 'deploy' failed: Deploying: Creating instance 'bosh/0': Creating VM: Creating vm with stemcell cid 'af76d776-4712-418b-986b-72e5f26017af': CPI 'create_vm' method responded with error: CmdError{"type":"Bosh::Clouds::VMCreationFailed","message":"OpenStack API Bad Request (Error. Unable to associate floating ip). Check task debug log for details.","ok_to_retry":true}

And in the neutron-server.log I see:

2016-04-22 18:29:52.262 27227 INFO neutron.api.v2.resource [req-7e26624a-a425-4db2-ab85-3afa4ec9b0eb None] update failed (client error): External network e87b37df-5d6a-4408-b71f-fa20beb8a206 is not reachable from subnet 4f9edede-85c5-4510-860c-622e06b09030. Therefore, cannot associate Port 01553ac5-a254-4c84-a2f3-d2764c39b543 with a Floating IP.

I've not seen in the documentation that we have to create a router between public and private network (I followed the tutorial like a nice boy). From the time I've created the router, all is OK. I suggest to add this step in the documentation.

Thank you!

In the Google CPI documentation relating to vm-types the service_account parameter is not mentioned at all. This option is necessary for bosh to be able to launch an instance with the permissions of a service account. This option is described in the bosh resource pool options section of the Google CPI README.

I'm not sure anymore what variations are supported anymore in the various CLI versions. At one point, it used to be:

• can specify latest, and it will just use what's on the director
• can specify version, and it will use it if it's on the director
• can specify remote tarball URL, along with version and SHA1
• can specify local tarball file:/// URL, along with version (no need for SHA1)
• can specify local release directory path, along with version create, and it will create the release and upload it for you.

I think at minimum all versions of the CLI support the remote URL specification, though not sure whether they treat version and SHA1 the same. Either way, would be nice to have all the supported fields in the releases block of the manifest documented.

/cc @tinygrasshopper

http://docs.cloudfoundry.org/bosh/terminology.html

On the terminology page for BOSH, under Jumpbox, it says "Note: An Inception Server can be used as a jumpbox.", but there is no description of what an "Inception Server" is.

e.g. azs

Asked in:

• https://cloudfoundry.slack.com/archives/C02HPPYQ2/p1510255494000132

It would be helpful to be able so search the docs.

Hi,

I noticed that there is a typo/missing words in the description of templates and how they are related to jobs.

Here is the line in the docs: https://github.com/cloudfoundry/docs-bosh/blob/master/jobs.html.md.erb#L54
Here is the section of the web page on bosh.io: https://bosh.io/docs/jobs.html#templates

Hi there, https://github.com/cloudfoundry/docs-bosh/blob/4ba9ee2e4129f476cafb5fbf0b52534001519e7e/cli-ops-files.html.md.erb mentions a remove command but doesn't show any examples. Can there be one or two provided?

The contents of https://bosh.io/docs/azure-cpi.html is older than https://github.com/cloudfoundry/docs-bosh/blob/master/azure-cpi.html.md.erb

I was mainly confused around how / why aliases needed to be configured and some of the syntactical sugar around how you can match an alias.

I'd like to see this documented.

e.g. http://docs.cloudfoundry.org/bosh/deploy-microbosh-to-aws.html

The manifest on this page is missing a section to configure HM to talk to the director. A bosh user needs to be created manually for this to work; i.e. using bosh create user hm.

This needs to be configured correctly for the resurrector and agent metrics reporting to work correctly.

This process is similar to replacing the built in an admin account, which also doesn't appear to be described anywhere at this time.

Installing the v2 CLI on a standard Ubuntu machine using the binaries from [this page][1] doesn't work, due to missing packages. We should include a list of thing to install for this CLI to work, similar to https://bosh.io/docs/bosh-cli.html
[1]:https://bosh.io/docs/cli-v2.html

http://bosh.io/docs/stemcell.html

Is this correct?

"In addition to being generic, stemcells for one OS (e.g. all Ubuntu Trusty stemcells) are exactly the same for all infrastructures. This property of stemcells allows BOSH users to quickly and reliably switch between different infrastructures without worrying about the differences between OS images."

"Reusing base Operating System images across different IaaS"

Doesn't bosh.io have different downloads of a stemcell based on the IAAS ?

From reading the update block docs it is unclear whether the update_watch_time includes post-start script running. It doesn't seem to, and that's understandable, but it might be worth pointing this out explicitly in the docs.

Sam & @craigfurman

Hi,
Chapters "Configuring external blobstore" and "Configuring external database" have the same title (Connecting the Director to an External Postgres Database).
In fact, the following text should be not the "External Postgres Database", and "External Blobstore" is better.

---
title: Connecting the Director to an External Postgres Database

---

If you conform it, I will submit the PR for "https://github.com/cloudfoundry/docs-bosh/blob/master/director-configure-blobstore.html.md.erb".