FAQ
Hi Dr. Nic,

I'm facing your early days at Engine Yard, though, hehehe. Because, this is
the first time that I really need to understand what happen in the server
side, in a linux administration perspective. So, I'm inside of a storm of
knowledge, and trying to keeps the things running. Fortunately, I'm working
within local VMs, but this intended to be used in a production cloud. So
Bosh seems to be a perfect tool for handle it.

TDD for shell script? This is totally new for me. But seems to be very
helpful. At least for me, that think the shell script is a little complex
to understand. And dangerous to be tested on the fly. (a friend of mine,
deleted the /etc folder, because a script fails)

I've tried to use chef, but I still like to use shell scripts, so Bosh is a
very good tool to manage that.

Thanks for sharing!

Best regards.
--
Robson Mendonça
Técnico em Análise e Programação Senior
T&T Engenheiros Associados Ltda. <http://tet.com.br/>
http://robsonmendonca.com.br

2012/7/18 Dr Nic Williams <drnicwilliams@gmail.com>
Anything's possible - its all just code :)

I also don't have a background in configuring linux machines; but 2 years
at Engine Yard means I've seen my fair share of scripts, chef recipes, and
AWS provisioning. I have to look up everything on the ole Google Machine
(which then redirects me to Stack Overflow or some ugly Linux Users forum)
to figure out which flags to use on each executable. Hence being able to
iterate on anything within a local VM against my development codebase means
I get to try scripts faster.

Currently I'm experimenting with the roundup project [1] for authoring
tests, so I can automate even more of the "does my bosh release (or
whatever devops thing I'm doing) still work?". TDD for my BOSH releases :)

[1] https://github.com/bmizerany/roundup

Dr Nic Williams - VP Developer Evangelism
Engine Yard
The Leading Platform as a Service
Mobile: +1 415 860 2185
Skype: nicwilliams
Twitter: @drnic

On Wednesday, July 18, 2012 at 7:43 AM, Robson Mendonça wrote:

Hi!

This is really cool Dr. Nic, I'm facing several problems to install bosh
because I'm not so familiar with system administration.
I'm learning a lot with cloud foundry community, and this video gave me
several ideas about how simple and automated could be the bosh installation.

I've tried to install vcap using the vcap_dev_setup with vagrant but, I'm
not so lucky. Nevertheless, you show me that it could be possible.

Very nice! =D

Best regards.
--
Robson Mendonça
Técnico em Análise e Programação Senior
T&T Engenheiros Associados Ltda. <http://tet.com.br/>
http://robsonmendonca.com.br


2012/7/17 Jeremy Voorhis <jeremy@appfog.com>

I haven't gotten very far, but I toyed with building a VirtualBox CPI. An
even better idea would be to develop a Warden CPI that could run on a build
server within IaaS, where you can't deploy a hypervisor and don't want to
manage a lab.

Shortening the feedback loop and reducing the initial barrier are Good
Things.

Jeremy Voorhis
Sr Engineer, appfog.com
503.319.0075

On Tuesday, July 17, 2012 at 12:17 PM, Dr Nic Williams wrote:

I think the experience of developing a BOSH release sucks. As it also
sucks to develop a system stack in any other universe (including such
nicenesses as chef or puppet). You change a piece of config, you need to
redeploy it all into a real environment. You change a start script, you
need to redeploy it all into a real environment. You still need to learn to
configure/run postgresql. You still need to learn Linux.

I needed a way to develop a bosh release faster. Specifically, I need to
be able to fail faster, because when I'm writing a shell script that's
going to run as root to launch a postgres server that's going to run as a
different user, I'm going to fail a lot.

I think a local virtual environment is the best starting point for a
solution. It can be tied to your host machine (your laptop) - file system
sharing and port forwarding - so you can change source/release files,
create a new release, compile/render it, restart processes, and tail log
files all on your local machine.

Here is a quick demo (4 mins instead of the 30 mins in real life) of
"deploying" (package compilation, job template rendering, monit starting
multiple jobs) a bosh release within Vagrant [1]

https://vimeo.com/45918717

There are no running parts of BOSH in this demo. No blobstore and no
agent. I'm not sure if this is a good thing or not. But it does re-use the
BOSH source code from the most outer points that I could manage (so its
relatively immune to internal refactorings / API changes).

I'll do another little video to demo how much easier it makes
developing/fixing a release another day.

I guess the point of this video is to show that its possible to take all
the raw ingredients in a BOSH release (blobs, source files, templates,
monit scripts, and deployment manifest properties) and run them in a single
VM without BOSH itself running. The next video will show why this is very
handy.

I'll release the scripts/ folder when I figure out how to
distribute/version a bunch of ruby/bash scripts for everyone's different
BOSH releases. For the moment, they are stuck inside my own project. Sorry.

[1] Vagrant http://vagrantup.com/ is a CLI for managing a local virtual
environment. Currently it supports VirtualBox, but I believe work is
underway for desktop VMWare support.



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

Dr Nic Williams - VP Developer Evangelism

[image: Engine Yard]

The Leading Platform as a Service

Mobile: 415 860 2185

Skype: nicwilliams

Twitter: @drnic
------------------------------






Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 9 | next ›
Discussion Overview
groupbosh-users @
postedJul 17, '12 at 7:17p
activeFeb 12, '13 at 3:48p
posts9
users6

People

Translate

site design / logo © 2022 Grokbase