Date   
Reduce syslog redundancy in linux-stemcells

Dewald, Manuel
 

Hi all,

we observed that in the current configuration BOSH-deployed VMs consume a lot of disk space by writing redundant log files. As an example, currently syslog writes all output to /var/log/syslog and /var/log/messages. This seems to be due to the compatibility to CentOS and Ubuntu default behaviour.

To reduce the redundancy in the logs of bosh-deployed VMs, we want to change the rsyslog config file[1]. We propose the following changes:
- As default log file use /var/log/syslog on Ubuntu and /var/log/messages on CentOS
- Don't write debug, lpr.log, mail.*, user.log and news.* files.

Please review our PR[2] and let us know if you have any objections, which might be the case if you rely on the current behaviour.

[1] https://github.com/beyhan/bosh-linux-stemcell-builder/blob/master/stemcell_builder/stages/rsyslog_config/assets/rsyslog_50-default.conf
[2] https://github.com/cloudfoundry/bosh-linux-stemcell-builder/pull/75

Kind regards,
Kai & Manuel

Telemetry within BOSH

Mike Lloyd
 

Hey folks,

 

I have an interesting use case in front of me that I’m trying to figure out how to approach both sanely as well as sustainably. I have a use case where I want highly structured telemetry data from the BOSH director for downstream analytics. My target goal of this use case is to have a comprehensive and clear perspective into where BOSH is spending it’s time. I could see any type of telemetry data being immensely useful for operators and CFF developers as it can help give insight into where improvements can be made.

 

Currently I’m exploring 3 options:

  • Dump of the Director database.
    • Pro: Anything that’s logged to the database is available, can be used with external data visualisation solutions.
    • Con: Schema relations and changes with versions make this difficult to sustain; database schema isn’t well documented; potentially lots of SQL script maintenance; only visible for what’s stored in the database.
  • Adding telemetry hooks to the Director and BOSH Agent.
    • Pro: Every action the director takes can be tracked and measured through the majority of BOSH.
    • Cons: Immense amount of initial work; finding a telemetry framework; handling telemetry output.
  • Adding telemetry hooks to the BOSH CLI.
    • Pro: Every action the CLI takes can be tracked and measured.
    • Cons: Only CLI actions can be tracked; immense amount of initial work; finding a telemetry framework; handling telemetry output.

 

Looking across the industry, telemetry is very prevalent, and it’s almost always an opt-in model, so anything I explore . Since I haven’t seen anything like this discussed in the mailing lists before, I wanted to surface my explorations to get others’ thoughts and opinions on telemetry within BOSH.

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

Re: Telemetry within BOSH

Marco Voelz
 

Dear Mike,


Thanks for bringing this up. More insight in what the Director could definitely be helpful for a number of things. 


Concerning your use-case, I hope you can help me understand a few points:

  • What is it that you're trying to achieve? My current understanding is that you're trying to run some analytics on the data you want to gather. Let's say you have all the data for your Director – how are you going to use it, specifically?
  • At which level of granularity would you imagine this data to be gathered? When I'm reading 'where the Director spends its time', I'm understanding anything between 'each single statement in the code' to 'each interaction with the IaaS/CPI'.
  • To get a better understanding of where you're coming from: Have you looked at particular libraries/tools/software for this use-case that you want to share as examples when gathering telemetry data for other services you worked with?

Thanks and warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd <mike@...>
Sent: Thursday, December 13, 2018 1:12:41 AM
To: cf-bosh@...
Subject: [cf-bosh] Telemetry within BOSH
 

Hey folks,

 

I have an interesting use case in front of me that I’m trying to figure out how to approach both sanely as well as sustainably. I have a use case where I want highly structured telemetry data from the BOSH director for downstream analytics. My target goal of this use case is to have a comprehensive and clear perspective into where BOSH is spending it’s time. I could see any type of telemetry data being immensely useful for operators and CFF developers as it can help give insight into where improvements can be made.

 

Currently I’m exploring 3 options:

  • Dump of the Director database.
    • Pro: Anything that’s logged to the database is available, can be used with external data visualisation solutions.
    • Con: Schema relations and changes with versions make this difficult to sustain; database schema isn’t well documented; potentially lots of SQL script maintenance; only visible for what’s stored in the database.
  • Adding telemetry hooks to the Director and BOSH Agent.
    • Pro: Every action the director takes can be tracked and measured through the majority of BOSH.
    • Cons: Immense amount of initial work; finding a telemetry framework; handling telemetry output.
  • Adding telemetry hooks to the BOSH CLI.
    • Pro: Every action the CLI takes can be tracked and measured.
    • Cons: Only CLI actions can be tracked; immense amount of initial work; finding a telemetry framework; handling telemetry output.

 

Looking across the industry, telemetry is very prevalent, and it’s almost always an opt-in model, so anything I explore . Since I haven’t seen anything like this discussed in the mailing lists before, I wanted to surface my explorations to get others’ thoughts and opinions on telemetry within BOSH.

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

Re: Telemetry within BOSH

Damzog Jochen (CI/OSC1)
 

Hi Marco and Mike,

 

We have since long time a requirement that is similar. I have noted it down some time ago:

 

Subscription mechanism for events

bosh does have a notion of events, see http://bosh.io/docs/events. These events will be fired on each activity taken by the director o.a. deployments, creation and deletion of vms. These events could very well be used to trigger operations outside of bosh to either prepare or complement the action taken by the director. For example we would like to use these events to trigger creation or deletion of firewall configurations.

In order to use events to trigger external action we require to have a mechanism to subscribe for these events. There are multiple ways to achieve this. For example, the director could forward these events to a messaging system (like rabbitmq) or it could offer a mechanism to register webhooks. 

For our use case of setting up FW rules it would be useful to configure a synchronous coupling between the director action and the external action to ensure FW rules are applied before a particular vms is started. This feature, however, should remain configurable if implemented because many other use cases will probably prefer to be executed asynchronously.

 

 

Mit freundlichen Grüßen / Best regards

Jochen Damzog

Service Integration and Brokering (CI/OSC1)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY
| www.bosch.com
Tel. +49 711 811-18977 | Mobil +49 173 8673114 | Fax +49 711 811 |
Jochen.Damzog@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, Dr. Christian Fischer,
Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: cf-bosh@... <cf-bosh@...> Im Auftrag von Marco Voelz
Gesendet: Donnerstag, 13. Dezember 2018 16:46
An: cf-bosh@...
Betreff: Re: [cf-bosh] Telemetry within BOSH

 

Dear Mike,

 

Thanks for bringing this up. More insight in what the Director could definitely be helpful for a number of things. 

 

Concerning your use-case, I hope you can help me understand a few points:

  • What is it that you're trying to achieve? My current understanding is that you're trying to run some analytics on the data you want to gather. Let's say you have all the data for your Director – how are you going to use it, specifically?
  • At which level of granularity would you imagine this data to be gathered? When I'm reading 'where the Director spends its time', I'm understanding anything between 'each single statement in the code' to 'each interaction with the IaaS/CPI'.
  • To get a better understanding of where you're coming from: Have you looked at particular libraries/tools/software for this use-case that you want to share as examples when gathering telemetry data for other services you worked with?

 

Thanks and warm regards

Marco


From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd <mike@...>
Sent: Thursday, December 13, 2018 1:12:41 AM
To: cf-bosh@...
Subject: [cf-bosh] Telemetry within BOSH

 

Hey folks,

 

I have an interesting use case in front of me that I’m trying to figure out how to approach both sanely as well as sustainably. I have a use case where I want highly structured telemetry data from the BOSH director for downstream analytics. My target goal of this use case is to have a comprehensive and clear perspective into where BOSH is spending it’s time. I could see any type of telemetry data being immensely useful for operators and CFF developers as it can help give insight into where improvements can be made.

 

Currently I’m exploring 3 options:

  • Dump of the Director database.
    • Pro: Anything that’s logged to the database is available, can be used with external data visualisation solutions.
    • Con: Schema relations and changes with versions make this difficult to sustain; database schema isn’t well documented; potentially lots of SQL script maintenance; only visible for what’s stored in the database.
  • Adding telemetry hooks to the Director and BOSH Agent.
    • Pro: Every action the director takes can be tracked and measured through the majority of BOSH.
    • Cons: Immense amount of initial work; finding a telemetry framework; handling telemetry output.
  • Adding telemetry hooks to the BOSH CLI.
    • Pro: Every action the CLI takes can be tracked and measured.
    • Cons: Only CLI actions can be tracked; immense amount of initial work; finding a telemetry framework; handling telemetry output.

 

Looking across the industry, telemetry is very prevalent, and it’s almost always an opt-in model, so anything I explore . Since I haven’t seen anything like this discussed in the mailing lists before, I wanted to surface my explorations to get others’ thoughts and opinions on telemetry within BOSH.

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

CF BOSH PMC: BOSH Core Europe Call for Nominations

Marco Voelz
 

Dear Friends of BOSH,


I'm rotating into a different role within SAP, which means I'm stepping down from the BOSH Core Europe PM position.

Therefore, the BOSH Core Europe team operating out of Walldorf, Germany, has an opening for its PM. Please send nominations directly to me or in reply to this message no later than 23:59 GMT on Thursday, December 20, 2018.


At the same time, I'd like to stay as BOSH PMC lead. A big part of my new role at SAP is concerned with defining and shaping an opinion about the future of BOSH, which should fit nicely to the PMC lead position. If you have any concerns about this, please don't hesitate to contact me.


If you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks and warm regards
Marco


Re: [CAUTION] [cf-bosh] CF BOSH PMC: BOSH Core Europe Call for Nominations

Marco Voelz
 

Dear Friends of BOSH,

 

SAP is nominating Felix Riegger as PM for the BOSH Europe Team. Felix has been a developer in the team since 2015 and has been pairing with me for the last few weeks to guarantee a smooth transitioning.

 

Please send any other nominations directly to me or in reply to this message no later than 23:59 GMT on Thursday, December 20, 2018.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Friday, 14. December 2018 at 14:31
To: "cf-bosh@..." <cf-bosh@...>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [CAUTION] [cf-bosh] CF BOSH PMC: BOSH Core Europe Call for Nominations

 

Dear Friends of BOSH,

 

I'm rotating into a different role within SAP, which means I'm stepping down from the BOSH Core Europe PM position.

Therefore, the BOSH Core Europe team operating out of Walldorf, Germany, has an opening for its PM. Please send nominations directly to me or in reply to this message no later than 23:59 GMT on Thursday, December 20, 2018.

 

At the same time, I'd like to stay as BOSH PMC lead. A big part of my new role at SAP is concerned with defining and shaping an opinion about the future of BOSH, which should fit nicely to the PMC lead position. If you have any concerns about this, please don't hesitate to contact me.

 

If you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco

 

 

BOSH vision and strategy

Frédéric Desbiens
 

 

Hi BOSH community!


When Marco, Morgan and myself started in our roles in the BOSH project management committee (PMC), one of our primary objectives was to give the community more visibility into our roadmap. It took us a bit more time than expected, but we finally put together a document that explains our vision and strategy for BOSH. It is my pleasure to finally share it with you today. You can access it here: https://docs.google.com/document/d/1pa-d7aC707dK9vvZUYIu9iytYzM9oM8YK-0M4vTp1rA/edit?usp=sharing


By making this document public, we hope to start a conversation with you. We wish to make sure we are building the right features for our users. This will be impossible without your comments and suggestions. Please let us know what you think.  


Priorities evolve over time. A roadmap is never set in stone; we want to evolve ours according to your feedback. We aim to publish new versions of the document on a regular basis to let you know where we are headed.


Thank you for reading this, and for being a part of the BOSH community!


Best Regards,  


Frédéric Desbiens

Product Manager

Project Lead, BOSH Core Toronto project


Re: BOSH vision and strategy

Mike Youngstrom
 

I think this looks great.  Nice work!  +1 for IPv6 support.  Getting iIPv6 into bosh will hopefully help bubble support for that up the stack and into CF.

Mike



On Wed, Dec 19, 2018 at 6:15 AM Frédéric Desbiens <fdesbiens@...> wrote:
 

Hi BOSH community!


When Marco, Morgan and myself started in our roles in the BOSH project management committee (PMC), one of our primary objectives was to give the community more visibility into our roadmap. It took us a bit more time than expected, but we finally put together a document that explains our vision and strategy for BOSH. It is my pleasure to finally share it with you today. You can access it here: https://docs.google.com/document/d/1pa-d7aC707dK9vvZUYIu9iytYzM9oM8YK-0M4vTp1rA/edit?usp=sharing


By making this document public, we hope to start a conversation with you. We wish to make sure we are building the right features for our users. This will be impossible without your comments and suggestions. Please let us know what you think.  


Priorities evolve over time. A roadmap is never set in stone; we want to evolve ours according to your feedback. We aim to publish new versions of the document on a regular basis to let you know where we are headed.


Thank you for reading this, and for being a part of the BOSH community!


Best Regards,  


Frédéric Desbiens

Product Manager

Project Lead, BOSH Core Toronto project


Moving BPM out of Incubation

Christopher Brown
 

Hi everyone,

We'd like to propose moving the BPM project from the incubator into general availability during the next BOSH PMC meeting. 

bpm-release version 1.0 was released in November last year and is being used by many releases to provide a consistent and isolated sandbox environment for BOSH jobs.

What do you think?

Thanks,
Christopher

Unconference in Philadelphia - Talks Please!

Daniel Jones
 

Hi lovely CF peeps,

We're seeking short talk proposals for the CF Summit NA 2019 Unconference. If you've got something cool, off-the-wall, or maybe that didn't quite fit the main conference criteria, then please make a proposal! 

We want to have a couple of scheduled talks so that potential attendees have some certainty about what knowledge will be imparted upon them. Other than that, we'll be allowing plenty of time for open space discussions (more than in Basel!).

In Basel last year a whopping 20% of all summit attendees came to the Unconference, so it's a great opportunity to engage your peers in conversation and learn from each other. Whilst SAP are already sponsors, we're looking for more - so if you want a way to reach a large portion of the summit audience directly, please get in touch.

We're also bringing the Cloud Foundry Pub Quiz to North America for the first time - expect beer, rubbish jokes, obscure trivia, and lively debates about whether the questions make sense!



Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists

Re: Unconference in Philadelphia - Talks Please!

Dr Nic Williams
 

Hurray for the Unconference!

Nic

 


From: cf-bosh@... on behalf of Daniel Jones <daniel.jones@...>
Sent: Thursday, January 24, 2019 10:11 am
To: Discussions about Cloud Foundry projects and the system overall.; Discussions about the Cloud Foundry BOSH project.
Subject: [cf-bosh] Unconference in Philadelphia - Talks Please!
 
Hi lovely CF peeps,

We're seeking short talk proposals for the CF Summit NA 2019 Unconference. If you've got something cool, off-the-wall, or maybe that didn't quite fit the main conference criteria, then please make a proposal! 

We want to have a couple of scheduled talks so that potential attendees have some certainty about what knowledge will be imparted upon them. Other than that, we'll be allowing plenty of time for open space discussions (more than in Basel!).

In Basel last year a whopping 20% of all summit attendees came to the Unconference, so it's a great opportunity to engage your peers in conversation and learn from each other. Whilst SAP are already sponsors, we're looking for more - so if you want a way to reach a large portion of the summit audience directly, please get in touch.

We're also bringing the Cloud Foundry Pub Quiz to North America for the first time - expect beer, rubbish jokes, obscure trivia, and lively debates about whether the questions make sense!



Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists

Re: Moving BPM out of Incubation

Marco Voelz
 

Dear Christopher,

 

Thanks for the proposal! Sorry for not following up on this sooner. A question which currently comes to my mind given the proposed transition to an 'active' project is: How active is BPM nowadays? What does the current BPM team look like and how much time do the team members spend on BPM?

 

I'll reach out to the individual PMC members and get their vote on the issue in the next week.

 

Thanks and warm regards

Marco

 

From: <cf-bosh@...> on behalf of Christopher Brown <cbrown@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Thursday, 17. January 2019 at 20:32
To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh@...>
Cc: aram price <aprice@...>, James Myers <jmyers@...>
Subject: [cf-bosh] Moving BPM out of Incubation

 

Hi everyone,

 

We'd like to propose moving the BPM project from the incubator into general availability during the next BOSH PMC meeting. 

 

bpm-release version 1.0 was released in November last year and is being used by many releases to provide a consistent and isolated sandbox environment for BOSH jobs.

 

What do you think?

 

Thanks,

Christopher

Re: Moving BPM out of Incubation

Christopher Brown
 

I work on it 1-2 days per week. BPM v1 is pretty much feature complete and I anticipate that most of the work from now on will be refinements.

At some point we'll start seriously considering what the next steps for v2 are. At that point I expect the time spent on it and the feature work to ramp back up again.

Thanks and all the best,
Christopher

Reminder about our CoC and a change to the slack configuration

Chip Childers
 

All,

Over the weekend, there were several reports of inappropriate content being shared within the CF community's slack team in various channels. These messages have been removed and the accounts that posted them have been disabled.

We'd like to take this opportunity to remind everyone that we take breaches of our code of conduct very seriously. Our code of conduct can be found here: https://www.cloudfoundry.org/code-of-conduct/ 

While these occurrences were likely caused by people outside of our community taking advantage of the fact that our slack instance is open to everyone, it's important for community members to help ensure that we have a welcoming and inclusive environment.

If you see any inappropriate content posted to slack or have any code of conduct concerns, we ask that you reach out to the CFF via conduct@...We also ask that those that have administrative access to the slack team help with policing when / if they see something. If you do have administrative access and see inappropriate content, please help by (1) deleting the messages, (2) capturing a screenshot of the offending content and (3) notifying the CFF staff at conduct@....

Also note: due to reports of similar activity in other community slack teams having included tagging @channel and @here in postings of inappropriate content, we have disabled the use of those for non-admin users. This is to reduce the impact of any bad actor's actions.

Please reach out to me directly (cchilders@...) or the conduct@ email address if you have any questions or concerns.

Chip Childers, CTO
Cloud Foundry Foundation

Which OpenStack version is supported by Cloud Foundry?

R M
 

Folks,

I am trying to determine which version of OpenStack is supported by Cloud Foundry.  As per https://bosh.io/docs/init-openstack/ it mentions Liberty/Mikata/Newton as being supported and actively tested.  Does this still hold as all of the mentioned releases are EOL?

As per https://github.com/cloudfoundry/bosh-openstack-cpi-release#supported-openstack-versions - it mentions upstream OpenStack policy which seems to contradict with what is listed on bosh.io.

Thanks for any insight you can provide.


Re: Which OpenStack version is supported by Cloud Foundry?

Marco Voelz
 

Hey,

 

Thanks for pointing out that the docs at per https://bosh.io/docs/init-openstack/ are outdated. We will fix that hopefully soon and link to the correct documents.

The information at  https://github.com/cloudfoundry/bosh-openstack-cpi-release#supported-openstack-versions is correct: we test against the officially supported versions of OpenStack.

 

Let me know if you have further questions.

 

Warm regards

Marco

 

 

From: <cf-bosh@...> on behalf of R M <rishi.investigate@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Friday, 8. February 2019 at 23:31
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Which OpenStack version is supported by Cloud Foundry?

 

Folks,

 

I am trying to determine which version of OpenStack is supported by Cloud Foundry.  As per https://bosh.io/docs/init-openstack/ it mentions Liberty/Mikata/Newton as being supported and actively tested.  Does this still hold as all of the mentioned releases are EOL?

 

As per https://github.com/cloudfoundry/bosh-openstack-cpi-release#supported-openstack-versions - it mentions upstream OpenStack policy which seems to contradict with what is listed on bosh.io.

 

Thanks for any insight you can provide.

 

 

Can't renew bosh-director certificate

Jan-Henrik Christophersen
 

Hello all,

we failed to renew our director and mbus certificate before they expired and wanted to do that now by using the create-env command. I removed the "director_ssl" and "mbus_bootstrap_ssl" sections and used bosh int with the --vars-store flag to regenerate them. I've manually checked that the certificates are valid for another year.
To deploy this change, I ran the bosh create-env command but I am now running into this issue:

Command:
```
bosh create-env bosh-director/bosh.yml
    --state=xxx/state.json
    --vars-store=xxx/credentials.yml
    -o bosh-director/cpi.yml
    -v access_key_id=xxxxxxx
    -v secret_access_key=xxxxxxx
    -v director_name=bosh-director 
    -v director_instance_profile=xxx
    -v internal_cidr=10.118.132.0/24 
    -v internal_dns=10.118.128.2 
    -v internal_gw=10.118.132.1 
    -v internal_ip=10.118.132.9 
    -v subnet_id=subnet-04a2xxx
    -v region=eu-central-1 
    -v az=eu-central-1a 
    -v default_key_name=bosh
    -v default_security_groups=sg-e88axxx
    -v concourse_security_group=sg-679xxx
    -v concourse_elb=elb
    --ca-cert (interpolated ca cert) # tried with and without this parameter
    --var-file private_key=xxxxxxx.pem
```

Output:
```
Started validating
  Downloading release 'bosh'... Skipped [Found in local cache] (00:00:00)
  Validating release 'bosh'... Finished (00:00:00)
  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:00)
 
Started installing CPI
  Compiling package 'ruby_aws_cpi/c6ba8a1e1b53b94ee9caf13d2d749c40cecfa038'... Finished (00:00:00)
  Compiling package 'bosh_aws_cpi/137cfc70652337ff1d3fca795e6d9ddd6e7e68dd'... Finished (00:00:00)
  Installing packages... Finished (00:00:01)
  Rendering job templates... Finished (00:00:00)
  Installing job 'aws_cpi'... Finished (00:00:00)
Finished installing CPI (00:00:02)
 
Starting registry... Finished (00:00:00)
Uploading stemcell 'bosh-aws-xen-hvm-ubuntu-trusty-go_agent/3421.9'... Skipped [Stemcell already uploaded] (00:00:00)
 
Started deploying
  Waiting for the agent on VM 'i-099931a2d9xxxxx'... Failed (00:00:00)
  Deleting VM 'i-099931a2d9xxxxx'... Finished (00:00:41)
  Creating VM for instance 'bosh/0' from stemcell 'ami-f7349398 light'... Finished (00:00:38)
  Waiting for the agent on VM 'i-07711bc8a06xxxxx' to be ready...
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused
...
 Failed (00:00:34)
Failed deploying (00:02:05)
 
Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)

Deploying:
  Creating instance 'bosh/0':
    Waiting until instance is ready:
      Post https://mbus:<redacted>@10.118.132.9:6868/agent: x509: certificate has expired or is not yet valid
```

bosh-director/bosh.yml
```
---
name: bosh
 
releases:
- name: bosh
  version: "262.3"
  url: https://s3.amazonaws.com/bosh-compiled-release-tarballs/bosh-262.3-ubuntu-trusty-3421.9-20170706-183731-831697577-20170706183736.tgz?versionId=7GmwKfufgb5JwWhJ.cwIWLnejOtm2Hu4
  sha1: 1eae3f06282417e54ebb199656458f9d6c38e2af
 
resource_pools:
- name: vms
  network: default
  env:
    bosh:
      password: '*'
      mbus:
        cert: ((mbus_bootstrap_ssl))
 
disk_pools:
- name: disks
  disk_size: 32_768
 
networks:
- name: default
  type: manual
  subnets:
  - range: ((internal_cidr))
    gateway: ((internal_gw))
    static: [((internal_ip))]
    dns: [((internal_dns))]
 
instance_groups:
- name: bosh
  instances: 1
  jobs:
  - {name: nats, release: bosh}
  - {name: postgres-9.4, release: bosh}
  - {name: blobstore, release: bosh}
  - {name: director, release: bosh}
  - {name: health_monitor, release: bosh}
  resource_pool: vms
  persistent_disk_pool: disks
  networks:
  - name: default
    static_ips: [((internal_ip))]
  properties:
    nats:
      address: 127.0.0.1
      user: nats
      password: ((nats_password))
    postgres: &db
      listen_address: 127.0.0.1
      host: 127.0.0.1
      user: postgres
      password: ((postgres_password))
      database: bosh
      adapter: postgres
    blobstore:
      address: ((internal_ip))
      port: 25250
      provider: dav
      director:
        user: director
        password: ((blobstore_director_password))
      agent:
        user: agent
        password: ((blobstore_agent_password))
    director:
      address: 127.0.0.1
      name: ((director_name))
      db: *db
      flush_arp: true
      enable_post_deploy: true
      generate_vm_passwords: true
      enable_dedicated_status_worker: true
      enable_nats_delivered_templates: true
      workers: 4
      events:
        record_events: true
      ssl:
        key: ((director_ssl.private_key))
        cert: ((director_ssl.certificate))
      user_management:
        provider: local
        local:
          users:
          - name: admin
            password: ((admin_password))
          - name: hm
            password: ((hm_password))
    hm:
      director_account:
        user: hm
        password: ((hm_password))
        ca_cert: ((director_ssl.ca))
      resurrector_enabled: true
    ntp: &ntp
    - time1.google.com
    - time2.google.com
    - time3.google.com
    - time4.google.com
    agent:
      mbus: nats://nats:((nats_password))@((internal_ip)):4222
 
cloud_provider:
  mbus: https://mbus:((mbus_bootstrap_password))@((internal_ip)):6868
  cert: ((mbus_bootstrap_ssl))
  properties:
    agent: {mbus: "https://mbus:((mbus_bootstrap_password))@0.0.0.0:6868"}
    blobstore: {provider: local, path: /var/vcap/micro_bosh/data/cache}
    ntp: *ntp
 
variables:
- name: admin_password
  type: password
- name: blobstore_director_password
  type: password
- name: blobstore_agent_password
  type: password
- name: hm_password
  type: password
- name: mbus_bootstrap_password
  type: password
- name: nats_password
  type: password
- name: postgres_password
  type: password
- name: default_ca
  type: certificate
  options:
    is_ca: true
    common_name: ca
- name: mbus_bootstrap_ssl
  type: certificate
  options:
    ca: default_ca
    common_name: ((internal_ip))
    alternative_names: [((internal_ip))]
- name: director_ssl
  type: certificate
  options:
    ca: default_ca
    common_name: ((internal_ip))
    alternative_names: [((internal_ip))]
```

Can anyone point out what I am doing wrong here? I only have limited experience with bosh and didn't have to regenerate certificates before. The person who originally deployed this is also not around.

Thanks,
Jan

Re: Can't renew bosh-director certificate

Jan-Henrik Christophersen
 

Turns out I didn't regenerate the "default_ca". After regenerating all of them the deployment worked. I'll leave this up hoping it will help someone else if they encounter this.

upload custom windows stemcell issue

Atil Sensalduz
 

Hi folks,

When I was trying upload custom windows server 2012R2 stemcell I got the error like this: image-tar: disk1.vmdk: wrote only 7680 of 10240 bytes.
My stemcell tar file size is 12 GB. I have increased client_mac_body_size in the ngnx.conf and blobstore.conf at the director. Which did I stick in the limitation?

best regards

Re: upload custom windows stemcell issue

Danny Berger
 

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 overhead, and it might store an additional copy of the image on disk while it's processing).

If increasing the size of ephemeral disk doesn't help, can you please provide the full error message that you're seeing?

Danny


On Sun, Feb 17, 2019 at 10:54 AM Atil Sensalduz <atil.sensalduz@...> wrote:
Hi folks,

When I was trying upload custom windows server 2012R2 stemcell I got the error like this: image-tar: disk1.vmdk: wrote only 7680 of 10240 bytes.
My stemcell tar file size is 12 GB. I have increased client_mac_body_size in the ngnx.conf and blobstore.conf at the director. Which did I stick in the limitation?

best regards



--
Danny Berger