Hi, Without seeing the full error message, you may want to start by making sure that the ephemeral disk of your director is sufficiently large enough to receive the large stemcell file (+ some overhea

Hi Arpit - this message is fairly specific to the Cloud Foundry releases, so you might have better luck emailing the cf-dev@... where there's more experience deploying CF and seeing

Hi - you may want to verify that your director has connectivity to the internet and AWS API in the us-east-1 region. Perhaps you can try running the following after SSH'ing to the director. $ curl -vv

Hi - the cloudfoundry/bosh repository is a regular BOSH release, so once you have made your changes, you can create a new release tarball with `bosh create-release --tarball=/tmp/bosh-dev.tgz`. If you

BOSH, prior to v258, reported a stemcell-style version number. If you remove the first and last piece of the version and prefix it with "stable-", you can generally cross-reference it with the git rel

Hi - welcome to Cloud Foundry! That error probably means you have an incorrect version of Vagrant/VirtualBox installed (e.g. a version for 14.04 vs 14.10), or you're missing the correct kernel modules

Hi! It might be the case that VirtualBox shutdown the VM, so it's no longer running. If so, it's probably easiest to rerun the `bosh create-env` or `vagrant recreate` to get it back. If your VirtualBo

I agree this could be a bit confusing to both newcomers and others. I'm not sure renaming the `disk_types.cloud_properties.type` is the correct solution though. The values in `cloud_properties` should

Hi Krishnan - the stemcell-related code was split off into a separate repo, https://github.com/cloudfoundry/bosh-linux-stemcell-builder. It has an updated README.md should contain all the files you're

Instead of `lbtargetgroups`, try `lb_target_groups` - the markup formatting on the bosh.io docs page is rendering poorly. Danny

It sounds like consul may not be healthy on your CC VM. Perhaps ssh there and take a look at the logs in /var/vcap/sys/log/**/*.log for a few more hints. Specifically you might want to take a look at

Typically the release would generate those values dynamically based on the `spec` variable (e.g. `<%= spec.job.name %>`. This way the values don't need to be hard-coded anywhere, and they're compatibl

This sounds fairly specific to cf-release. You might want to raise an issue at https://github.com/cloudfoundry/cf-release for a more targeted audience. It will also be helpful to them if you include w

Sounds like you may have forgotten to initialize the submodules in your repository. Try executing `git submodule update --init` and running the build again. Otherwise, take a closer look in go/src/git

This is often due to losing the director-state.json file that bosh-init created after your initial deploy. That file keeps track of the existing instance and disk CIDs. It uses those values during an

This sounds like a generic AWS/API permissions error and not necessarily specific to cn-north-1. Maybe double check your Access Key ID, Secret Access Key, bucket configuration, and that your time/NTP

This behavior is hard-coded in the bosh-agent preinstalled by the stemcell (code https://github.com/cloudfoundry/bosh-agent/blob/develop/platform/linux_platform.go#L779). Recent work has gone into mou

Hi - you can't currently define dependencies between jobs. monit has a very primitive notion of dependencies, but they are not reliable with the stemcell's monit. I think the recommended approach woul

bosh-init doesn't support rendering ERB templates like the bosh_cli does. You'll want to pass it regular YAML files (or pre-parse your manifest with some other tool before passing it to bosh-init). vi

Hi - interesting question, but since it seems fairly CF-specific, you might find better help from the cf-dev list ( https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/). You