Date   

Re: CF install failing on OpenStack

eoghank
 

Thanks Guillaume, it looks like DNS resolution of the Cinder endpoint was
causing the volume failure.

Eoghan



--
View this message in context: http://cf-bosh.70367.x6.nabble.com/cf-bosh-CF-install-failing-on-OpenStack-tp117p125.html
Sent from the CF BOSH mailing list archive at Nabble.com.


Re: cf-stub.yml example with minimum or required info

Ali
 

Thanks Joseph for your help, please see the error below:

20JXXW:cf-release ali00$ ./generate_deployment_manifest vsphere cf-stub.yml > cf-deployment.yml
2015/06/04 13:34:50 error generating manifest: unresolved nodes:
(( static_ips(12) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[5].networks.[0].static_ips
(( static_ips(16) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[8].networks.[0].static_ips
(( static_ips(14, 15) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[15].networks.[0].static_ips
(( static_ips(17, 18, 19) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[17].networks.[0].static_ips
(( jobs.postgres_z1.networks.cf1.static_ips.[0] )) in dynaml properties.databases.address
(( properties.databases.address )) in dynaml properties.ccdb.address
(( properties.databases.address )) in dynaml properties.uaadb.address
M-2XX0JW:cf-release ali00$


I do not want to bug cf-bosh alias with every error I run into so my ask is to find a sample of cf-stub.yml with all minimum required values, Im sure Im missing a lot :), the sample online here http://docs.cloudfoundry.org/deploying/cf-stub-vsphere.html, when I first run it I got an error regarding “Error 40001: Required property `range' was not specified in object”, then after I added “range” property I got the error above.

Im looking for building a POC CF with minimum effort, do have one network (10.166.166.0/23) and vSphere 5.x, I want to use it for both CF networks (cf1 and cf2), not sure how many Ips I need on each network, and if I have to specify nodes spec and vsphere info in cf-stub since I do not see section for it?

I also tried bosh-lite and it worked fine on Ubuntu 14.

Here is my cf-stub.yml in case you want to have a look


# The following line helps maintain current documentation at http://docs.cloudfoundry.org.
# code_snippet cf-stub-vsphere start
---
name: cloudfoundry
director_uuid: b9a1bf7b-952f-48e1-a496-f6543d7a782c

releases:
- name: cf-210
version: latest


networks:

- name: cf1

subnets:

- range: 10.166.166.0/23

gateway: 10.195.76.1

static:

- 10.166.166.104 - 10.166.166.115

reserved:

# .1 is special

- 10.166.166.2 - 10.166.166.101

- 10.166.166.120 - 10.194.167.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.166.166.x'

- name: cf2

subnets:

- range: 10.166.166.0/23

gateway: 10.166.166.1

static:

- 10.166.166.120 - 10.166.166.140

reserved:

# .1 is special

- 10.166.166.2 - 10.166.166.101

- 10.166.166.120 - 10.195.167.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.166.166.x'

jobs:
ha_proxy_z1:
properties:
ha_proxy:
disable_http: true
properties:
cc:
droplets:
droplet_directory_key: the_key
buildpacks:
buildpack_directory_key: bd_key
staging_upload_user: username
staging_upload_password: password
bulk_api_password: password
db_encryption_key: the_key
dea_next:
disk_mb: 2048
memory_mb: 1024
loggregator_endpoint:
shared_secret: loggregator_endpoint_secret
nats:
user: nats_user
password: nats_password
router:
enable_ssl: true
ssl_cert: |
-----BEGIN CERTIFICATE-----
MIIDBjCCAe4CCQCz3nn1SWrDdTANBgkqhkiG9w0BAQUFADBFMQswCQYDVQQGEwJB
VTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0
cyBQdHkgTHRkMB4XDTE1MDMwMzE4NTMyNloXDTE2MDMwMjE4NTMyNlowRTELMAkG
A1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0
IFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKtTK9xq/ycRO3fWbk1abunYf9CY6sl0Wlqm9UPMkI4j0itY2OyGyn1YuCCiEdM3
b8guGSWB0XSL5PBq33e7ioiaH98UEe+Ai+TBxnJsro5WQ/TMywzRDhZ4E7gxDBav
88ZY+y7ts0HznfxqEIn0Gu/UK+s6ajYcIy7d9L988+hA3K1FSdes8MavXhrI4xA1
fY21gESfFkD4SsqvrkISC012pa7oVw1f94slIVcAG+l9MMAkatBGxgWAQO6kxk5o
oH1Z5q2m0afeQBfFqzu5lCITLfgTWCUZUmbF6UpRhmD850/LqNtryAPrLLqXxdig
OHiWqvFpCusOu/4z1uGC5xECAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAV5RAFVQy
8Krs5c9ebYRseXO6czL9/Rfrt/weiC1XLcDkE2i2yYsBXazMYr58o4hACJwe2hoC
bihBZ9XnVpASEYHDLwDj3zxFP/bTuKs7tLhP7wz0lo8i6k5VSPAGBq2kjc/cO9a3
TMmLPks/Xm42MCSWGDnCEX1854B3+JK3CNEGqSY7FYXU4W9pZtHPZ3gBoy0ymSpg
mpleiY1Tbn5I2X7vviMW7jeviB5ivkZaXtObjyM3vtPLB+ILpa15ZhDSE5o71sjA
jXqrE1n5o/GXHX+1M8v3aJc30Az7QAqWohW/tw5SoiSmVQZWd7gFht9vSzaH2WgO
LwcpBC7+cUJEww==
-----END CERTIFICATE-----
ssl_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAq1Mr3Gr/JxE7d9ZuTVpu6dh/0JjqyXRaWqb1Q8yQjiPSK1jY
7IbKfVi4IKIR0zdvyC4ZJYHRdIvk8Grfd7uKiJof3xQR74CL5MHGcmyujlZD9MzL
DNEOFngTuDEMFq/zxlj7Lu2zQfOd/GoQifQa79Qr6zpqNhwjLt30v3zz6EDcrUVJ
16zwxq9eGsjjEDV9jbWARJ8WQPhKyq+uQhILTXalruhXDV/3iyUhVwAb6X0wwCRq
0EbGBYBA7qTGTmigfVnmrabRp95AF8WrO7mUIhMt+BNYJRlSZsXpSlGGYPznT8uo
22vIA+ssupfF2KA4eJaq8WkK6w67/jPW4YLnEQIDAQABAoIBAQCDVqpcOoZKK9K8
Bt3eXQKEMJ2ji2cKczFFJ5MEm9EBtoJLCryZbqfSue3Fzpj9pBUEkBpk/4VT5F7o
0/Vmc5Y7LHRcbqVlRtV30/lPBPQ4V/eWtly/AZDcNsdfP/J1fgPSvaoqCr2ORLWL
qL/vEfyIeM4GcWy0+JMcPbmABslw9O6Ptc5RGiP98vCLHQh/++sOtj6PH1pt+2X/
Uecv3b1Hk/3Oe+M8ySorJD3KA94QTRnKX+zubkxRg/zCAki+as8rQc/d+BfVG698
ylUT5LVLNuwbWnffY2Zt5x5CDqH01mJnHmxzQEfn68rb3bGFaYPEn9EP+maQijv6
SsUM9A3lAoGBAODRDRn4gEIxjPICp6aawRrMDlRc+k6IWDF7wudjxJlaxFr2t7FF
rFYm+jrcG6qMTyq+teR8uHpcKm9X8ax0L6N6gw5rVzIeIOGma/ZuYIYXX2XJx5SW
SOas1xW6qEIbOMv+Xu9w2SWbhTgyRmtlxxjr2e7gQLz9z/vuTReJpInnAoGBAMMW
sq5lqUfAQzqxlhTobQ7tnB48rUQvkGPE92SlDj2TUt9phek2/TgRJT6mdcozvimt
JPhxKg3ioxG8NPmN0EytjpSiKqlxS1R2po0fb75vputfpw16Z8/2Vik+xYqNMTLo
SpeVkHu7fbtNYEK2qcU44OyOZ/V+5Oo9TuBIFRhHAoGACkqHhwDRHjaWdR2Z/w5m
eIuOvF3lN2MWZm175ouynDKDeoaAsiS2VttB6R/aRFxX42UHfoYXC8LcTmyAK5zF
8X3SMf7H5wtqBepQVt+Gm5zGSSqLcEnQ3H5c+impOh105CGoxt0rk4Ui/AeRIalv
C70AJOcvD3eu5aFq9gDe/1ECgYBAhkVbASzYGnMh+pKVH7rScSxto8v6/XBYT1Ez
7JOlMhD667/qvtFJtgIHkq7qzepbhnTv5x3tscQVnZY34/u9ILpD1s8dc+dibEvx
6S/gYLVorB5ois/DLMqaobRcew6Gs+XX9RPwmLahOJpZ9mh4XrOmCgPAYtP71YM9
ExpHCQKBgQCMMDDWGMRdFMJgXbx1uMere7OoniBdZaOexjbglRh1rMVSXqzBoU8+
yhEuHGAsHGWQdSBHnqRe9O0Bj/Vlw2VVEaJeL1ewRHb+jXSnuKclZOJgMsJAvgGm
SOWIahDrATA4g1T6yLBWQPhj3ZXD3eCMxT1Q3DvpG1DjgvXwmXQJAA==
-----END RSA PRIVATE KEY-----
cipher_suites: TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_CBC_SHA
status:
user: router_user
password: router_password
login:
logout:
redirect:
parameter:
disable: false
uaa:
admin:
client_secret: admin_secret
batch:
username: batch_username
password: batch_password
cc:
client_secret: cc_client_secret
clients:
app-direct:
secret: app-direct_secret
developer_console:
secret: developer_console_secret
login:
secret: login_client_secret
notifications:
secret: notification_secret
doppler:
secret: doppler_secret
cloud_controller_username_lookup:
secret: cloud_controller_username_lookup_secret
gorouter:
secret: gorouter_secret

jwt:
verification_key: vk
signing_key: sk
scim:
users:
- admin|fakepassword|scim.write,scim.read,openid,cloud_controller.admin,doppler.firehose

# code_snippet cf-stub-vsphere end
# The previous line helps maintain current documentation at http://docs.cloudfoundry.org.




Thank you

Ahmed





From: CF Runtime <cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>>
Reply-To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Date: Wednesday, June 3, 2015 at 5:40 PM
To: "cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>" <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Subject: Re: [cf-bosh] cf-stub.yml example with minimum or required info

Hi Ali,

We try to keep those docs up to date, but it is possible they are missing some pieces.

Can you tell me what errors you are getting?

Joseph Palermo
CF Runtime Team


Job is not running after update - agent/monit race issue?

Danny Berger <dpb587@...>
 

Frequently when doing a deploy (happens in multiple deployments) a job will
randomly fail with "job/0 is not running after update" for no logical
reason. I can just rerun `bosh deploy` and it will succeed on that job and
move onto the next job for update (which might also fail). Alternatively, I
can SSH in and monit will show one or more processes as "not monitored",
yet if I run `monit start all` it does start the remaining processes
without fail. Looking into this behavior more today, I think it might be
some strange interaction between bosh-agent and monit.

In a good job, everything updates/restarts as expected (logs here [1]), but
on a problem job, I've noticed a key difference: monit receives `start
service` very early [2] but never actually invokes the start action for it.
In the bad log [3] you'll see there are only 3 "start: " and "start action
done" messages, yet there are 4 "start service" messages. In the good job
logs, there would always be 4 of each of those messages. Here is a second
example [4] where two services fail to start.

In all cases that I'm seeing, if the "start service" call(s) are logged
before those final "monit HTTP server stopped/started" occur, then they
appear to get lost and the start command never run. Theorizing... is it
possible that bosh-agent is asynchronously sending start commands alongside
SIGHUP? Or perhaps that monit is randomly, strangely slow to process the
SIGHUP vs HTTP request? Or perhaps those monit starts are just sent to
quickly after a reload?

These logs were from a deployment using
bosh-aws-xen-ubuntu-trusty-go_agent/2798 with the logsearch +
logsearch-shipper releases. Sorry the stemcell isn't newer - looking
through bosh-agent and bosh commit logs though I don't see messages which
reference a fix for this sort of thing, so hopefully the log details are
still relevant. I don't think it's release or deployment specific given the
log message, but I don't have much experience deploying many other things
to know for sure.

If anybody has any insight into this strangeness, I'd definitely appreciate
it. The while loop workaround we've been using works, but it's not so great
for automation.

Thanks!

Danny

[1]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-good-summary-log
[2]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad-log-L44
[3] https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad-log
[4] https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad2-log


--
Danny Berger
http://dpb587.me


Re: Job is not running after update - agent/monit race issue?

Dmitriy Kalinin
 

Do you use 'depends on' directives? Are you sure you have configured
`update` options for your deployment giving enough time for the monit to
spin up processes and have them running?

On Thu, Jun 4, 2015 at 4:31 PM, Danny Berger <dpb587(a)gmail.com> wrote:

Frequently when doing a deploy (happens in multiple deployments) a job
will randomly fail with "job/0 is not running after update" for no logical
reason. I can just rerun `bosh deploy` and it will succeed on that job and
move onto the next job for update (which might also fail). Alternatively, I
can SSH in and monit will show one or more processes as "not monitored",
yet if I run `monit start all` it does start the remaining processes
without fail. Looking into this behavior more today, I think it might be
some strange interaction between bosh-agent and monit.

In a good job, everything updates/restarts as expected (logs here [1]),
but on a problem job, I've noticed a key difference: monit receives `start
service` very early [2] but never actually invokes the start action for it.
In the bad log [3] you'll see there are only 3 "start: " and "start action
done" messages, yet there are 4 "start service" messages. In the good job
logs, there would always be 4 of each of those messages. Here is a second
example [4] where two services fail to start.

In all cases that I'm seeing, if the "start service" call(s) are logged
before those final "monit HTTP server stopped/started" occur, then they
appear to get lost and the start command never run. Theorizing... is it
possible that bosh-agent is asynchronously sending start commands alongside
SIGHUP? Or perhaps that monit is randomly, strangely slow to process the
SIGHUP vs HTTP request? Or perhaps those monit starts are just sent to
quickly after a reload?

These logs were from a deployment using
bosh-aws-xen-ubuntu-trusty-go_agent/2798 with the logsearch +
logsearch-shipper releases. Sorry the stemcell isn't newer - looking
through bosh-agent and bosh commit logs though I don't see messages which
reference a fix for this sort of thing, so hopefully the log details are
still relevant. I don't think it's release or deployment specific given the
log message, but I don't have much experience deploying many other things
to know for sure.

If anybody has any insight into this strangeness, I'd definitely
appreciate it. The while loop workaround we've been using works, but it's
not so great for automation.

Thanks!

Danny

[1]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-good-summary-log
[2]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad-log-L44
[3] https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad-log
[4]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad2-log


--
Danny Berger
http://dpb587.me

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


Re: Job is not running after update - agent/monit race issue?

Danny Berger <dpb587@...>
 

Thanks for the suggestions. No `depends on` directives though, and
canary/update watch times were set to `30000-120000`.

I was thinking it was more an issue of monit not getting a chance to finish
responding to and executing the start call before the monit process
reloaded itself.

On Thu, Jun 4, 2015 at 6:42 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:

Do you use 'depends on' directives? Are you sure you have configured
`update` options for your deployment giving enough time for the monit to
spin up processes and have them running?

On Thu, Jun 4, 2015 at 4:31 PM, Danny Berger <dpb587(a)gmail.com> wrote:

Frequently when doing a deploy (happens in multiple deployments) a job
will randomly fail with "job/0 is not running after update" for no logical
reason. I can just rerun `bosh deploy` and it will succeed on that job and
move onto the next job for update (which might also fail). Alternatively, I
can SSH in and monit will show one or more processes as "not monitored",
yet if I run `monit start all` it does start the remaining processes
without fail. Looking into this behavior more today, I think it might be
some strange interaction between bosh-agent and monit.

In a good job, everything updates/restarts as expected (logs here [1]),
but on a problem job, I've noticed a key difference: monit receives `start
service` very early [2] but never actually invokes the start action for it.
In the bad log [3] you'll see there are only 3 "start: " and "start action
done" messages, yet there are 4 "start service" messages. In the good job
logs, there would always be 4 of each of those messages. Here is a second
example [4] where two services fail to start.

In all cases that I'm seeing, if the "start service" call(s) are logged
before those final "monit HTTP server stopped/started" occur, then they
appear to get lost and the start command never run. Theorizing... is it
possible that bosh-agent is asynchronously sending start commands alongside
SIGHUP? Or perhaps that monit is randomly, strangely slow to process the
SIGHUP vs HTTP request? Or perhaps those monit starts are just sent to
quickly after a reload?

These logs were from a deployment using
bosh-aws-xen-ubuntu-trusty-go_agent/2798 with the logsearch +
logsearch-shipper releases. Sorry the stemcell isn't newer - looking
through bosh-agent and bosh commit logs though I don't see messages which
reference a fix for this sort of thing, so hopefully the log details are
still relevant. I don't think it's release or deployment specific given the
log message, but I don't have much experience deploying many other things
to know for sure.

If anybody has any insight into this strangeness, I'd definitely
appreciate it. The while loop workaround we've been using works, but it's
not so great for automation.

Thanks!

Danny

[1]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-good-summary-log
[2]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad-log-L44
[3]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad-log
[4]
https://gist.github.com/dpb587/ad44bb34aabab1c4a98e#file-monit-bad2-log


--
Danny Berger
http://dpb587.me

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

--
Danny Berger
http://dpb587.me


Re: Migrating a full-stack bosh deployment to bosh-init

Allan Espinosa
 

Thanks Gwenn, Dmitry

I'll try this out.

-----Original Message-----
From: Espinosa, Allan | Allan | OPS
Sent: Mierkoles, Hunyo 03, 2015 11:48 AM
To: 'cf-bosh(a)lists.cloudfoundry.org'
Subject: Migrating a full-stack bosh deployment to bosh-init

Hi,

We currently have a binary bosh [1] setup. However we would like to
transition to bosh-init to prevent having to manage multiple bosh
deployments.

I'm looking at how to regenerate the state file described in [2]. I can find my
VM CID from "bosh vms bosh-meta --details" but can't get the other
information from the director. Is there other places to retrieve the
information? Or do I have to poke things below the cpi (vSphere in our case).

We're using the vsphere cpi for our deployment.

Thanks
Allan

[1] https://blog.starkandwayne.com/2014/07/10/resurrecting-bosh-with-
binary-boshes/
[2] https://bosh.io/docs/using-bosh-init.html#recover-deployment-state


Best practices on bosh release distribution

Sumanth Yamala <Sumanth.Yamala@...>
 

Hi,

I have a process which creates a bosh release -> which has all the artifacts and use a microbosh instance to create my release. It all works great! As I move to the next step to distribute my releases to cross departments and external customers - what are the best practices around this? How do we distribute bosh releases?

Thanks,
Sumanth


Re: Best practices on bosh release distribution

Gwenn Etourneau
 

If you OpenSource your bosh-release you can ask to be added to
https://github.com/cloudfoundry-community/ and you will be able to ask for
the community s3 bucket to put your final release and maybe be added to the
bosh.io website.

Or/and you can create a tarball of the full release and distribute this
tarball and of course the documentation for the bosh deployment manifest.

create release [<manifest_file>] [--force] [--final] [--with-tarball]
[--dry-run] [--name NAME] [--version VERSION]
Create release (assumes current directory to be a release repository)
--force bypass git dirty state check
--final create final release
* --with-tarball* create release tarball
--dry-run stop before writing release manifest
--name NAME specify a custom release name
--version VERSION specify a custom version number
(ex: 1.0.0 or 1.0-beta.2+dev.10)

On Sat, Jun 6, 2015 at 12:12 AM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

Hi,



I have a process which creates a bosh release -> which has all the
artifacts and use a microbosh instance to create my release. It all works
great! As I move to the next step to distribute my releases to cross
departments and external customers – what are the best practices around
this? How do we distribute bosh releases?



Thanks,

Sumanth

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


CF Router and openstack Neutron problem

Armin Ranjbar
 

Hello everyone,

I have been playing with CF installation, and i have noticed that during
DNS binding stage of deployment, BOSH tries to create an instance (zrouter)
that directly connects to External network (floating).

and as this is clearly doesn't work, bosh will not be able to ping the
router on EXT ip and installation aborted.

AFAIK directly attaching instances to external network (without using
neutron router) is impossible, how is this supposed to work then?

---
Armin ranjbar


Re: cf-stub.yml example with minimum or required info

CF Runtime
 

Hi Ahmed,

It looks like you haven't allocated enough IPs in your network. The line
for reserved IPs "10.166.166.104 - 10.166.166.115" should be increased to
have at least 19 IPs. You'll need to decrease the number of reserved
addresses as well in order to increase the number of available IPs in your
network. We recommend "10.166.166.104 - 10.166.166.123" for available IPs
and "10.166.166.124 - 10.194.167.254" for your reserved range. If you're
tracking our current develop branch and not the final releases you should
look in cf-release/spec/fixtures/vsphere/cf-stub.yml for the stub that we
use to do our vsphere acceptance tests.

Best,
Zachary Auerbach + Dan Lavine CF Runtime Team

On Thu, Jun 4, 2015 at 2:18 PM, Ahmed Ali (ahmeali) <ahmeali(a)cisco.com>
wrote:

Thanks Joseph for your help, please see the error below:

20JXXW:cf-release ali00$ ./generate_deployment_manifest vsphere
cf-stub.yml > cf-deployment.yml
2015/06/04 13:34:50 error generating manifest: unresolved nodes:
(( static_ips(12) )) in
./templates/cf-infrastructure-vsphere.yml
jobs.[5].networks.[0].static_ips
(( static_ips(16) )) in
./templates/cf-infrastructure-vsphere.yml
jobs.[8].networks.[0].static_ips
(( static_ips(14, 15) )) in
./templates/cf-infrastructure-vsphere.yml
jobs.[15].networks.[0].static_ips
(( static_ips(17, 18, 19) )) in
./templates/cf-infrastructure-vsphere.yml
jobs.[17].networks.[0].static_ips
(( jobs.postgres_z1.networks.cf1.static_ips.[0] )) in dynaml
properties.databases.address
(( properties.databases.address )) in dynaml
properties.ccdb.address
(( properties.databases.address )) in dynaml
properties.uaadb.address
M-2XX0JW:cf-release ali00$


I do not want to bug cf-bosh alias with every error I run into so my ask
is to find a sample of cf-stub.yml with all minimum required values, Im
sure Im missing a lot :), the sample online here
http://docs.cloudfoundry.org/deploying/cf-stub-vsphere.html, when I first
run it I got an error regarding “Error 40001: Required property `range' was
not specified in object”, then after I added “range” property I got the
error above.

Im looking for building a POC CF with minimum effort, do have one
network (10.166.166.0/23) and vSphere 5.x, I want to use it for both CF
networks (cf1 and cf2), not sure how many Ips I need on each network, and
if I have to specify nodes spec and vsphere info in cf-stub since I do not
see section for it?

I also tried bosh-lite and it worked fine on Ubuntu 14.

Here is my cf-stub.yml in case you want to have a look


# The following line helps maintain current documentation at
http://docs.cloudfoundry.org.
# code_snippet cf-stub-vsphere start
---
name: cloudfoundry
director_uuid: b9a1bf7b-952f-48e1-a496-f6543d7a782c

releases:
- name: cf-210
version: latest

networks:

- name: cf1

subnets:

- range: 10.166.166.0/23

gateway: 10.195.76.1

static:

- 10.166.166.104 - 10.166.166.115

reserved:

# .1 is special

- 10.166.166.2 - 10.166.166.101

- 10.166.166.120 - 10.194.167.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.166.166.x'

- name: cf2

subnets:

- range: 10.166.166.0/23

gateway: 10.166.166.1

static:

- 10.166.166.120 - 10.166.166.140

reserved:

# .1 is special

- 10.166.166.2 - 10.166.166.101

- 10.166.166.120 - 10.195.167.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.166.166.x'

jobs:
ha_proxy_z1:
properties:
ha_proxy:
disable_http: true
properties:
cc:
droplets:
droplet_directory_key: the_key
buildpacks:
buildpack_directory_key: bd_key
staging_upload_user: username
staging_upload_password: password
bulk_api_password: password
db_encryption_key: the_key
dea_next:
disk_mb: 2048
memory_mb: 1024
loggregator_endpoint:
shared_secret: loggregator_endpoint_secret
nats:
user: nats_user
password: nats_password
router:
enable_ssl: true
ssl_cert: |
-----BEGIN CERTIFICATE-----
MIIDBjCCAe4CCQCz3nn1SWrDdTANBgkqhkiG9w0BAQUFADBFMQswCQYDVQQGEwJB
VTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0
cyBQdHkgTHRkMB4XDTE1MDMwMzE4NTMyNloXDTE2MDMwMjE4NTMyNlowRTELMAkG
A1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0
IFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKtTK9xq/ycRO3fWbk1abunYf9CY6sl0Wlqm9UPMkI4j0itY2OyGyn1YuCCiEdM3
b8guGSWB0XSL5PBq33e7ioiaH98UEe+Ai+TBxnJsro5WQ/TMywzRDhZ4E7gxDBav
88ZY+y7ts0HznfxqEIn0Gu/UK+s6ajYcIy7d9L988+hA3K1FSdes8MavXhrI4xA1
fY21gESfFkD4SsqvrkISC012pa7oVw1f94slIVcAG+l9MMAkatBGxgWAQO6kxk5o
oH1Z5q2m0afeQBfFqzu5lCITLfgTWCUZUmbF6UpRhmD850/LqNtryAPrLLqXxdig
OHiWqvFpCusOu/4z1uGC5xECAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAV5RAFVQy
8Krs5c9ebYRseXO6czL9/Rfrt/weiC1XLcDkE2i2yYsBXazMYr58o4hACJwe2hoC
bihBZ9XnVpASEYHDLwDj3zxFP/bTuKs7tLhP7wz0lo8i6k5VSPAGBq2kjc/cO9a3
TMmLPks/Xm42MCSWGDnCEX1854B3+JK3CNEGqSY7FYXU4W9pZtHPZ3gBoy0ymSpg
mpleiY1Tbn5I2X7vviMW7jeviB5ivkZaXtObjyM3vtPLB+ILpa15ZhDSE5o71sjA
jXqrE1n5o/GXHX+1M8v3aJc30Az7QAqWohW/tw5SoiSmVQZWd7gFht9vSzaH2WgO
LwcpBC7+cUJEww==
-----END CERTIFICATE-----
ssl_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAq1Mr3Gr/JxE7d9ZuTVpu6dh/0JjqyXRaWqb1Q8yQjiPSK1jY
7IbKfVi4IKIR0zdvyC4ZJYHRdIvk8Grfd7uKiJof3xQR74CL5MHGcmyujlZD9MzL
DNEOFngTuDEMFq/zxlj7Lu2zQfOd/GoQifQa79Qr6zpqNhwjLt30v3zz6EDcrUVJ
16zwxq9eGsjjEDV9jbWARJ8WQPhKyq+uQhILTXalruhXDV/3iyUhVwAb6X0wwCRq
0EbGBYBA7qTGTmigfVnmrabRp95AF8WrO7mUIhMt+BNYJRlSZsXpSlGGYPznT8uo
22vIA+ssupfF2KA4eJaq8WkK6w67/jPW4YLnEQIDAQABAoIBAQCDVqpcOoZKK9K8
Bt3eXQKEMJ2ji2cKczFFJ5MEm9EBtoJLCryZbqfSue3Fzpj9pBUEkBpk/4VT5F7o
0/Vmc5Y7LHRcbqVlRtV30/lPBPQ4V/eWtly/AZDcNsdfP/J1fgPSvaoqCr2ORLWL
qL/vEfyIeM4GcWy0+JMcPbmABslw9O6Ptc5RGiP98vCLHQh/++sOtj6PH1pt+2X/
Uecv3b1Hk/3Oe+M8ySorJD3KA94QTRnKX+zubkxRg/zCAki+as8rQc/d+BfVG698
ylUT5LVLNuwbWnffY2Zt5x5CDqH01mJnHmxzQEfn68rb3bGFaYPEn9EP+maQijv6
SsUM9A3lAoGBAODRDRn4gEIxjPICp6aawRrMDlRc+k6IWDF7wudjxJlaxFr2t7FF
rFYm+jrcG6qMTyq+teR8uHpcKm9X8ax0L6N6gw5rVzIeIOGma/ZuYIYXX2XJx5SW
SOas1xW6qEIbOMv+Xu9w2SWbhTgyRmtlxxjr2e7gQLz9z/vuTReJpInnAoGBAMMW
sq5lqUfAQzqxlhTobQ7tnB48rUQvkGPE92SlDj2TUt9phek2/TgRJT6mdcozvimt
JPhxKg3ioxG8NPmN0EytjpSiKqlxS1R2po0fb75vputfpw16Z8/2Vik+xYqNMTLo
SpeVkHu7fbtNYEK2qcU44OyOZ/V+5Oo9TuBIFRhHAoGACkqHhwDRHjaWdR2Z/w5m
eIuOvF3lN2MWZm175ouynDKDeoaAsiS2VttB6R/aRFxX42UHfoYXC8LcTmyAK5zF
8X3SMf7H5wtqBepQVt+Gm5zGSSqLcEnQ3H5c+impOh105CGoxt0rk4Ui/AeRIalv
C70AJOcvD3eu5aFq9gDe/1ECgYBAhkVbASzYGnMh+pKVH7rScSxto8v6/XBYT1Ez
7JOlMhD667/qvtFJtgIHkq7qzepbhnTv5x3tscQVnZY34/u9ILpD1s8dc+dibEvx
6S/gYLVorB5ois/DLMqaobRcew6Gs+XX9RPwmLahOJpZ9mh4XrOmCgPAYtP71YM9
ExpHCQKBgQCMMDDWGMRdFMJgXbx1uMere7OoniBdZaOexjbglRh1rMVSXqzBoU8+
yhEuHGAsHGWQdSBHnqRe9O0Bj/Vlw2VVEaJeL1ewRHb+jXSnuKclZOJgMsJAvgGm
SOWIahDrATA4g1T6yLBWQPhj3ZXD3eCMxT1Q3DvpG1DjgvXwmXQJAA==
-----END RSA PRIVATE KEY-----
cipher_suites: TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_CBC_SHA
status:
user: router_user
password: router_password
login:
logout:
redirect:
parameter:
disable: false
uaa:
admin:
client_secret: admin_secret
batch:
username: batch_username
password: batch_password
cc:
client_secret: cc_client_secret
clients:
app-direct:
secret: app-direct_secret
developer_console:
secret: developer_console_secret
login:
secret: login_client_secret
notifications:
secret: notification_secret
doppler:
secret: doppler_secret
cloud_controller_username_lookup:
secret: cloud_controller_username_lookup_secret
gorouter:
secret: gorouter_secret

jwt:
verification_key: vk
signing_key: sk
scim:
users:
-
admin|fakepassword|scim.write,scim.read,openid,cloud_controller.admin,doppler.firehose

# code_snippet cf-stub-vsphere end
# The previous line helps maintain current documentation at
http://docs.cloudfoundry.org.




Thank you

Ahmed





From: CF Runtime <cfruntime(a)gmail.com>
Reply-To: "Discussions about the Cloud Foundry BOSH project." <
cf-bosh(a)lists.cloudfoundry.org>
Date: Wednesday, June 3, 2015 at 5:40 PM
To: "cf-bosh(a)lists.cloudfoundry.org" <cf-bosh(a)lists.cloudfoundry.org>
Subject: Re: [cf-bosh] cf-stub.yml example with minimum or required info

Hi Ali,

We try to keep those docs up to date, but it is possible they are
missing some pieces.

Can you tell me what errors you are getting?

Joseph Palermo
CF Runtime Team

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


Re: cf-stub.yml example with minimum or required info

Ali
 

That fixed the error, thank you!

And run into another error :)

M-20JW:cf-release ali00$ bosh deployment cf-deployment.yml
Deployment set to `/Users/ali00/deployments/cf-release/cf-deployment.yml'
M-20JW:cf-release ali00$ ./generate_deployment_manifest vsphere cf-stub.yml > cf-deployment.yml
M-20JW:cf-release ali00$ bosh deploy

Processing deployment manifest
------------------------------
Getting deployment properties from director...
Compiling deployment manifest...
Please review all changes carefully

Deploying
---------
Deployment name: `cf-deployment.yml'
Director name: `bosh2'
Are you sure you want to deploy? (type 'yes' to continue): yes

Director task 38
Started unknown
Started unknown > Binding deployment. Done (00:00:00)

Error 140002: Template `consul_agent' (job `consul_z1') references an unknown release `cf'

Task 38 error

For a more detailed error report, run: bosh task 38 --debug
M-20JW:cf-release ali00$


How can construct the section in cf-stub to provide correct cf release which I think should be cf-210 in my case (not sure)?


Modified networks part in my cf-stub.yml
-------------------------------------------------------
releases:
- name: cf-210
version: latest


networks:

- name: cf1

subnets:

- range: 10.195.166.0/23

gateway: 10.195.166.1

static:

- 10.195.166.104 - 10.195.166.125

reserved:

# .1 is special

- 10.195.166.2 - 10.195.166.101

- 10.195.166.147 - 10.194.177.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.195.166.x'

- name: cf2

subnets:

- range: 10.195.166.0/23

gateway: 10.195.166.1

static:

- 10.195.166.126 - 10.195.166.146

reserved:

# .1 is special

- 10.195.166.2 - 10.195.166.101

- 10.195.166.147 - 10.194.177.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.195.166.x'


------------------------------------------------




Thanks
Ali


From: CF Runtime <cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>>
Reply-To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Date: Friday, June 5, 2015 at 10:11 AM
To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Subject: Re: [cf-bosh] cf-stub.yml example with minimum or required info

Hi Ahmed,

It looks like you haven't allocated enough IPs in your network. The line for reserved IPs "10.166.166.104 - 10.166.166.115" should be increased to have at least 19 IPs. You'll need to decrease the number of reserved addresses as well in order to increase the number of available IPs in your network. We recommend "10.166.166.104 - 10.166.166.123" for available IPs and "10.166.166.124 - 10.194.167.254" for your reserved range. If you're tracking our current develop branch and not the final releases you should look in cf-release/spec/fixtures/vsphere/cf-stub.yml for the stub that we use to do our vsphere acceptance tests.

Best,
Zachary Auerbach + Dan Lavine CF Runtime Team

On Thu, Jun 4, 2015 at 2:18 PM, Ahmed Ali (ahmeali) <ahmeali(a)cisco.com<mailto:ahmeali(a)cisco.com>> wrote:
Thanks Joseph for your help, please see the error below:

20JXXW:cf-release ali00$ ./generate_deployment_manifest vsphere cf-stub.yml > cf-deployment.yml
2015/06/04 13:34:50 error generating manifest: unresolved nodes:
(( static_ips(12) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[5].networks.[0].static_ips
(( static_ips(16) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[8].networks.[0].static_ips
(( static_ips(14, 15) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[15].networks.[0].static_ips
(( static_ips(17, 18, 19) )) in ./templates/cf-infrastructure-vsphere.yml jobs.[17].networks.[0].static_ips
(( jobs.postgres_z1.networks.cf1.static_ips.[0] )) in dynaml properties.databases.address
(( properties.databases.address )) in dynaml properties.ccdb.address
(( properties.databases.address )) in dynaml properties.uaadb.address
M-2XX0JW:cf-release ali00$


I do not want to bug cf-bosh alias with every error I run into so my ask is to find a sample of cf-stub.yml with all minimum required values, Im sure Im missing a lot :), the sample online here http://docs.cloudfoundry.org/deploying/cf-stub-vsphere.html, when I first run it I got an error regarding “Error 40001: Required property `range' was not specified in object”, then after I added “range” property I got the error above.

Im looking for building a POC CF with minimum effort, do have one network (10.166.166.0/23<http://10.166.166.0/23>) and vSphere 5.x, I want to use it for both CF networks (cf1 and cf2), not sure how many Ips I need on each network, and if I have to specify nodes spec and vsphere info in cf-stub since I do not see section for it?

I also tried bosh-lite and it worked fine on Ubuntu 14.

Here is my cf-stub.yml in case you want to have a look


# The following line helps maintain current documentation at http://docs.cloudfoundry.org.
# code_snippet cf-stub-vsphere start
---
name: cloudfoundry
director_uuid: b9a1bf7b-952f-48e1-a496-f6543d7a782c

releases:
- name: cf-210
version: latest


networks:

- name: cf1

subnets:

- range: 10.166.166.0/23<http://10.166.166.0/23>

gateway: 10.195.76.1

static:

- 10.166.166.104 - 10.166.166.115

reserved:

# .1 is special

- 10.166.166.2 - 10.166.166.101

- 10.166.166.120 - 10.194.167.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.166.166.x'

- name: cf2

subnets:

- range: 10.166.166.0/23<http://10.166.166.0/23>

gateway: 10.166.166.1

static:

- 10.166.166.120 - 10.166.166.140

reserved:

# .1 is special

- 10.166.166.2 - 10.166.166.101

- 10.166.166.120 - 10.195.167.254

# .255 is special

dns: [10.166.168.183]

cloud_properties:

name: '10.166.166.x'

jobs:
ha_proxy_z1:
properties:
ha_proxy:
disable_http: true
properties:
cc:
droplets:
droplet_directory_key: the_key
buildpacks:
buildpack_directory_key: bd_key
staging_upload_user: username
staging_upload_password: password
bulk_api_password: password
db_encryption_key: the_key
dea_next:
disk_mb: 2048
memory_mb: 1024
loggregator_endpoint:
shared_secret: loggregator_endpoint_secret
nats:
user: nats_user
password: nats_password
router:
enable_ssl: true
ssl_cert: |
-----BEGIN CERTIFICATE-----
MIIDBjCCAe4CCQCz3nn1SWrDdTANBgkqhkiG9w0BAQUFADBFMQswCQYDVQQGEwJB
VTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0
cyBQdHkgTHRkMB4XDTE1MDMwMzE4NTMyNloXDTE2MDMwMjE4NTMyNlowRTELMAkG
A1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0
IFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKtTK9xq/ycRO3fWbk1abunYf9CY6sl0Wlqm9UPMkI4j0itY2OyGyn1YuCCiEdM3
b8guGSWB0XSL5PBq33e7ioiaH98UEe+Ai+TBxnJsro5WQ/TMywzRDhZ4E7gxDBav
88ZY+y7ts0HznfxqEIn0Gu/UK+s6ajYcIy7d9L988+hA3K1FSdes8MavXhrI4xA1
fY21gESfFkD4SsqvrkISC012pa7oVw1f94slIVcAG+l9MMAkatBGxgWAQO6kxk5o
oH1Z5q2m0afeQBfFqzu5lCITLfgTWCUZUmbF6UpRhmD850/LqNtryAPrLLqXxdig
OHiWqvFpCusOu/4z1uGC5xECAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAV5RAFVQy
8Krs5c9ebYRseXO6czL9/Rfrt/weiC1XLcDkE2i2yYsBXazMYr58o4hACJwe2hoC
bihBZ9XnVpASEYHDLwDj3zxFP/bTuKs7tLhP7wz0lo8i6k5VSPAGBq2kjc/cO9a3
TMmLPks/Xm42MCSWGDnCEX1854B3+JK3CNEGqSY7FYXU4W9pZtHPZ3gBoy0ymSpg
mpleiY1Tbn5I2X7vviMW7jeviB5ivkZaXtObjyM3vtPLB+ILpa15ZhDSE5o71sjA
jXqrE1n5o/GXHX+1M8v3aJc30Az7QAqWohW/tw5SoiSmVQZWd7gFht9vSzaH2WgO
LwcpBC7+cUJEww==
-----END CERTIFICATE-----
ssl_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAq1Mr3Gr/JxE7d9ZuTVpu6dh/0JjqyXRaWqb1Q8yQjiPSK1jY
7IbKfVi4IKIR0zdvyC4ZJYHRdIvk8Grfd7uKiJof3xQR74CL5MHGcmyujlZD9MzL
DNEOFngTuDEMFq/zxlj7Lu2zQfOd/GoQifQa79Qr6zpqNhwjLt30v3zz6EDcrUVJ
16zwxq9eGsjjEDV9jbWARJ8WQPhKyq+uQhILTXalruhXDV/3iyUhVwAb6X0wwCRq
0EbGBYBA7qTGTmigfVnmrabRp95AF8WrO7mUIhMt+BNYJRlSZsXpSlGGYPznT8uo
22vIA+ssupfF2KA4eJaq8WkK6w67/jPW4YLnEQIDAQABAoIBAQCDVqpcOoZKK9K8
Bt3eXQKEMJ2ji2cKczFFJ5MEm9EBtoJLCryZbqfSue3Fzpj9pBUEkBpk/4VT5F7o
0/Vmc5Y7LHRcbqVlRtV30/lPBPQ4V/eWtly/AZDcNsdfP/J1fgPSvaoqCr2ORLWL
qL/vEfyIeM4GcWy0+JMcPbmABslw9O6Ptc5RGiP98vCLHQh/++sOtj6PH1pt+2X/
Uecv3b1Hk/3Oe+M8ySorJD3KA94QTRnKX+zubkxRg/zCAki+as8rQc/d+BfVG698
ylUT5LVLNuwbWnffY2Zt5x5CDqH01mJnHmxzQEfn68rb3bGFaYPEn9EP+maQijv6
SsUM9A3lAoGBAODRDRn4gEIxjPICp6aawRrMDlRc+k6IWDF7wudjxJlaxFr2t7FF
rFYm+jrcG6qMTyq+teR8uHpcKm9X8ax0L6N6gw5rVzIeIOGma/ZuYIYXX2XJx5SW
SOas1xW6qEIbOMv+Xu9w2SWbhTgyRmtlxxjr2e7gQLz9z/vuTReJpInnAoGBAMMW
sq5lqUfAQzqxlhTobQ7tnB48rUQvkGPE92SlDj2TUt9phek2/TgRJT6mdcozvimt
JPhxKg3ioxG8NPmN0EytjpSiKqlxS1R2po0fb75vputfpw16Z8/2Vik+xYqNMTLo
SpeVkHu7fbtNYEK2qcU44OyOZ/V+5Oo9TuBIFRhHAoGACkqHhwDRHjaWdR2Z/w5m
eIuOvF3lN2MWZm175ouynDKDeoaAsiS2VttB6R/aRFxX42UHfoYXC8LcTmyAK5zF
8X3SMf7H5wtqBepQVt+Gm5zGSSqLcEnQ3H5c+impOh105CGoxt0rk4Ui/AeRIalv
C70AJOcvD3eu5aFq9gDe/1ECgYBAhkVbASzYGnMh+pKVH7rScSxto8v6/XBYT1Ez
7JOlMhD667/qvtFJtgIHkq7qzepbhnTv5x3tscQVnZY34/u9ILpD1s8dc+dibEvx
6S/gYLVorB5ois/DLMqaobRcew6Gs+XX9RPwmLahOJpZ9mh4XrOmCgPAYtP71YM9
ExpHCQKBgQCMMDDWGMRdFMJgXbx1uMere7OoniBdZaOexjbglRh1rMVSXqzBoU8+
yhEuHGAsHGWQdSBHnqRe9O0Bj/Vlw2VVEaJeL1ewRHb+jXSnuKclZOJgMsJAvgGm
SOWIahDrATA4g1T6yLBWQPhj3ZXD3eCMxT1Q3DvpG1DjgvXwmXQJAA==
-----END RSA PRIVATE KEY-----
cipher_suites: TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_CBC_SHA
status:
user: router_user
password: router_password
login:
logout:
redirect:
parameter:
disable: false
uaa:
admin:
client_secret: admin_secret
batch:
username: batch_username
password: batch_password
cc:
client_secret: cc_client_secret
clients:
app-direct:
secret: app-direct_secret
developer_console:
secret: developer_console_secret
login:
secret: login_client_secret
notifications:
secret: notification_secret
doppler:
secret: doppler_secret
cloud_controller_username_lookup:
secret: cloud_controller_username_lookup_secret
gorouter:
secret: gorouter_secret

jwt:
verification_key: vk
signing_key: sk
scim:
users:
- admin|fakepassword|scim.write,scim.read,openid,cloud_controller.admin,doppler.firehose

# code_snippet cf-stub-vsphere end
# The previous line helps maintain current documentation at http://docs.cloudfoundry.org.




Thank you

Ahmed





From: CF Runtime <cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>>
Reply-To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Date: Wednesday, June 3, 2015 at 5:40 PM
To: "cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>" <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
Subject: Re: [cf-bosh] cf-stub.yml example with minimum or required info

Hi Ali,

We try to keep those docs up to date, but it is possible they are missing some pieces.

Can you tell me what errors you are getting?

Joseph Palermo
CF Runtime Team

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


Re: Best practices on bosh release distribution

Dmitriy Kalinin
 

Typically releases are distributed to end users via release tarballs or
release git repo:

- to generate release tarball use `bosh create release --with-tarball` or
for the existing release `bosh create release
releases/some-release/some-release-7.yml --with-tarball`; users then upload
release to the Director via `bosh upload release some-release-7.tgz`
- alternatively, you can tell users to checkout git repo and run `bosh
upload release releases/some-release/some-release-7.yml`

On Fri, Jun 5, 2015 at 8:45 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

If you OpenSource your bosh-release you can ask to be added to
https://github.com/cloudfoundry-community/ and you will be able to ask
for the community s3 bucket to put your final release and maybe be added to
the bosh.io website.

Or/and you can create a tarball of the full release and distribute this
tarball and of course the documentation for the bosh deployment manifest.

create release [<manifest_file>] [--force] [--final] [--with-tarball]
[--dry-run] [--name NAME] [--version VERSION]
Create release (assumes current directory to be a release repository)
--force bypass git dirty state check
--final create final release
* --with-tarball* create release tarball
--dry-run stop before writing release
manifest
--name NAME specify a custom release name
--version VERSION specify a custom version number
(ex: 1.0.0 or 1.0-beta.2+dev.10)

On Sat, Jun 6, 2015 at 12:12 AM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

Hi,



I have a process which creates a bosh release -> which has all the
artifacts and use a microbosh instance to create my release. It all works
great! As I move to the next step to distribute my releases to cross
departments and external customers – what are the best practices around
this? How do we distribute bosh releases?



Thanks,

Sumanth

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


Re: CF Router and openstack Neutron problem

Dmitriy Kalinin
 

Can you share your manifest? I dont quite understand your setup.

On Fri, Jun 5, 2015 at 9:39 AM, Armin Ranjbar <zoup(a)zoup.org> wrote:

Hello everyone,

I have been playing with CF installation, and i have noticed that during
DNS binding stage of deployment, BOSH tries to create an instance (zrouter)
that directly connects to External network (floating).

and as this is clearly doesn't work, bosh will not be able to ping the
router on EXT ip and installation aborted.

AFAIK directly attaching instances to external network (without using
neutron router) is impossible, how is this supposed to work then?

---
Armin ranjbar


_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


Re: CF Router and openstack Neutron problem

Armin Ranjbar
 

With pleasure, it's quite possible that i didn't understand my setup as
well :)

since the neutron issue, i have noticed that my floating network had static
range stuff, so i have changed the type to VIP, which i think is correct.
now problem is :
Started creating bound missing vms
Started creating bound missing vms > router_z1/0
Started creating bound missing vms > router_z1/1
Failed creating bound missing vms > router_z1/0: OpenStack API Bad
Request (Fixed IP address 192.168.112.10 is already in use on instance
17410b87-c8df-4e3d-9224-fff82ac19740.). Check task debug log for details.
(00:00:36)

no matter which ip address that i choose, error is the same for all of
them, and i can't find any vm on openstack side using that address...


---
Armin ranjbar

On Sat, Jun 6, 2015 at 5:01 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:

Can you share your manifest? I dont quite understand your setup.

On Fri, Jun 5, 2015 at 9:39 AM, Armin Ranjbar <zoup(a)zoup.org> wrote:

Hello everyone,

I have been playing with CF installation, and i have noticed that during
DNS binding stage of deployment, BOSH tries to create an instance (zrouter)
that directly connects to External network (floating).

and as this is clearly doesn't work, bosh will not be able to ping the
router on EXT ip and installation aborted.

AFAIK directly attaching instances to external network (without using
neutron router) is impossible, how is this supposed to work then?

---
Armin ranjbar


_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


Re: CF Router and openstack Neutron problem

Armin Ranjbar
 

OK it's fixed now, for the record, Oddly enough, apparently it was related
to the fact that external ip address was not assigned to project. truly
misleading error message :I


---
Armin ranjbar

On Sat, Jun 6, 2015 at 10:15 AM, Armin Ranjbar <zoup(a)zoup.org> wrote:

With pleasure, it's quite possible that i didn't understand my setup as
well :)

since the neutron issue, i have noticed that my floating network had
static range stuff, so i have changed the type to VIP, which i think is
correct.
now problem is :
Started creating bound missing vms
Started creating bound missing vms > router_z1/0
Started creating bound missing vms > router_z1/1
Failed creating bound missing vms > router_z1/0: OpenStack API Bad
Request (Fixed IP address 192.168.112.10 is already in use on instance
17410b87-c8df-4e3d-9224-fff82ac19740.). Check task debug log for details.
(00:00:36)

no matter which ip address that i choose, error is the same for all of
them, and i can't find any vm on openstack side using that address...


---
Armin ranjbar


On Sat, Jun 6, 2015 at 5:01 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Can you share your manifest? I dont quite understand your setup.

On Fri, Jun 5, 2015 at 9:39 AM, Armin Ranjbar <zoup(a)zoup.org> wrote:

Hello everyone,

I have been playing with CF installation, and i have noticed that during
DNS binding stage of deployment, BOSH tries to create an instance (zrouter)
that directly connects to External network (floating).

and as this is clearly doesn't work, bosh will not be able to ping the
router on EXT ip and installation aborted.

AFAIK directly attaching instances to external network (without using
neutron router) is impossible, how is this supposed to work then?

---
Armin ranjbar


_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


How the BOSH Packckage be installed in target machine?

Xue Zhi Yong <zhiyxue@...>
 

This is a package script sample from https://bosh.io/docs/create-release.html#pkg-scripts
set -e -x

cp -a ardo_app/* ${BOSH_INSTALL_TARGET}

cd ${BOSH_INSTALL_TARGET}

/var/vcap/packages/ruby_1.9.3/bin/bundle install \
--local \
--deployment \
--without development test
The documents said the packaging scrpit will be run in a compiling VM, not the target VM.
I have two questions about this script:
1. Where is the target after execute command "cd ${BOSH_INSTALL_TARGET}" ?
2. If there's a job depend on this package. How the package will be installed to the job target VM?


Deployment manifest not recognized by BOSH

Kinjal Doshi
 

Hi,

I am trying to use manifest that is generated using the to_yaml
transformation technique in Ruby.

However, this deployment manifest is not recognized by bosh because it has
comments that detail the class names like:

*--- !ruby/object:DeploymentManifest *
*networks: *
*- !ruby/object:AWSDynamicNetworkBean *
* type: dynamic*
* cloud_properties: !ruby/object:AWSNetworkCPBean *
* security_groups: *
* - docker*
* - bosh*
* subnet: *
* name: default*
*- !ruby/object:AWSDynamicNetworkBean *
* type: vip*
* cloud_properties: {}*

As can be seen in above snippet, to_yaml adds object description using '!'
sign.

On using the command:

bosh deployment <manifest_file_path>

The following error is observed:

Usage: deployment [<filename>]

Removing the object details starting at '!' seems to resolve this error.

However, this was not happening with previous version of bosh_cli. I don't
remember the previous version that I was using. Current version being used
by me is: bosh cli-1.2978.0

Would be great if some one can please help me with this matter.


Regards,
Kinjal


how to add openjdk 1.8 to my project

ramonskie
 

i'm trying to create a bosh release that needs openjdk 1.8
but i have no clue on how to do this

i know that you can do it with bosh-gen --apt option
and then it downloads a massive amount of dependencies

but when i check other projects they all depend on openjdk-*.*.tar.gz
and i searched that net but i can't find them so i assume that you need to
create the package yourself
so i'm wondering if we have some global packages?
or maby point me in to the right directions of how you should do it



--
View this message in context: http://cf-bosh.70367.x6.nabble.com/how-to-add-openjdk-1-8-to-my-project-tp142.html
Sent from the CF BOSH mailing list archive at Nabble.com.


Re: how to add openjdk 1.8 to my project

James Bayer
 

the uaa needs java

the java buildpack builds and hosts the openjdk jre's on a repository:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/repository.yml

you'll just need some help to find out where exactly. hopefully someone can
point out how to do it.

On Mon, Jun 8, 2015 at 6:28 AM, ramonskie <ramon.makkelie(a)klm.com> wrote:

i'm trying to create a bosh release that needs openjdk 1.8
but i have no clue on how to do this

i know that you can do it with bosh-gen --apt option
and then it downloads a massive amount of dependencies

but when i check other projects they all depend on openjdk-*.*.tar.gz
and i searched that net but i can't find them so i assume that you need to
create the package yourself
so i'm wondering if we have some global packages?
or maby point me in to the right directions of how you should do it



--
View this message in context:
http://cf-bosh.70367.x6.nabble.com/how-to-add-openjdk-1-8-to-my-project-tp142.html
Sent from the CF BOSH mailing list archive at Nabble.com.
_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh
--
Thank you,

James Bayer


Re: How the BOSH Packckage be installed in target machine?

Sabha
 

The BOSH_INSTALL_TARGET would be /var/vcap/packages/<nameofPackage>.
The files under this folder would be saved from the compilation vm onto the
target vm with the same path if the job has a reference to the package (in
the job spec file).



--
View this message in context: http://cf-bosh.70367.x6.nabble.com/cf-bosh-How-the-BOSH-Packckage-be-installed-in-target-machine-tp140p144.html
Sent from the CF BOSH mailing list archive at Nabble.com.