FAQ
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





The Leading Platform as a Service


Mobile: 415 860 2185


Skype: nicwilliams


Twitter: @drnic

Search Discussions

  • Jeremy Voorhis at Jul 17, 2012 at 8:47 pm
    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 VoorhisSr 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





    The Leading Platform as a Service


    Mobile: 415 860 2185


    Skype: nicwilliams


    Twitter: @drnic

  • Robson Mendonça at Jul 18, 2012 at 2:43 pm
    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
    ------------------------------

  • Dr Nic Williams at Jul 18, 2012 at 5:10 pm
    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 (http://robsonmendonca.com.br/)


    2012/7/17 Jeremy Voorhis (mailto: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 VoorhisSr Engineer, appfog.com (http://appfog.com)
    503.319.0075 (tel: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





    The Leading Platform as a Service


    Mobile: 415 860 2185 (tel:415%20860%202185)


    Skype: nicwilliams


    Twitter: @drnic


  • Robson Mendonça at Jul 18, 2012 at 6:44 pm
    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
    ------------------------------






  • Brian McClain at Jul 18, 2012 at 8:53 pm
    Nic,

    Very, very cool stuff. I'll have to sit down and give this a go. Not too
    familiar with Vagrant, but looks like a good reason to get familiar with it
    :)

    Brian McClain
    @brianmmcclain
    On Wednesday, July 18, 2012 2:44:27 PM UTC-4, Robson Mendonça wrote:

    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
    ------------------------------







  • Anders R Sveen at Feb 12, 2013 at 1:18 pm
    Any progress on this? I'm just moving into this space and a bit
    disappointed of how few Vagrant setups I find. It's just awesome when it
    comes to development and repeatability, but also for easy testing.

    I have an initial try here at the VCAP
    setup: https://github.com/anderssv/cloudfoundry-vagrant

    Sadly there seems to be a recent bug in VCAP that makes it fail on some
    Chef dependencies, but I think it's a decent example any way.



    Cheers,
    Anders,
    On Tuesday, 17 July 2012 21:17:40 UTC+2, 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
    ------------------------------
  • Anders Sveen at Feb 12, 2013 at 1:34 pm
    I found the bosh-solo setup. https://github.com/drnic/bosh-solo

    Testing it, but at the moment I'm on OS X so I'm not too convinced the sm
    framework will work.



    Cheers,
    Anders,

    On Tuesday, 12 February 2013 14:18:06 UTC+1, Anders Sveen wrote:

    Any progress on this? I'm just moving into this space and a bit
    disappointed of how few Vagrant setups I find. It's just awesome when it
    comes to development and repeatability, but also for easy testing.

    I have an initial try here at the VCAP setup:
    https://github.com/anderssv/cloudfoundry-vagrant

    Sadly there seems to be a recent bug in VCAP that makes it fail on some
    Chef dependencies, but I think it's a decent example any way.



    Cheers,
    Anders,
    On Tuesday, 17 July 2012 21:17:40 UTC+2, 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
    ------------------------------
  • Dr Nic Williams at Feb 12, 2013 at 3:48 pm
    SM should work fine on your local machine for the thin generator of
    Vagrantfile. The rest of it is used inside vagrant VM.

    Not sure I'd package bosh-solo v2 using SM; but current bosh-solo should
    work as promised.
    On Tuesday, February 12, 2013, Anders Sveen wrote:

    I found the bosh-solo setup. https://github.com/drnic/bosh-solo

    Testing it, but at the moment I'm on OS X so I'm not too convinced the sm
    framework will work.



    Cheers,
    Anders,


    On Tuesday, 12 February 2013 14:18:06 UTC+1, Anders Sveen wrote:

    Any progress on this? I'm just moving into this space and a bit
    disappointed of how few Vagrant setups I find. It's just awesome when it
    comes to development and repeatability, but also for easy testing.

    I have an initial try here at the VCAP setup: https://github.com/**
    anderssv/cloudfoundry-vagrant<https://github.com/anderssv/cloudfoundry-vagrant>

    Sadly there seems to be a recent bug in VCAP that makes it fail on some
    Chef dependencies, but I think it's a decent example any way.



    Cheers,
    Anders,

    On Tuesday, 17 July 2012 21:17:40 UTC+2, 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 -
    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

Related Discussions

Discussion Navigation
viewthread | post
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