FAQ
I'd like to propose a future direction for the bosh_agent & stemcell
builder:

* a single stemcell for all infrastructures (currently we export one
stemcell per infrastructure per bosh_agent release)
* the bosh agent itself converts/finishes the VM for the target
infrastructure when it launches (via bundled chef cookbook)
* the bosh agent auto-detects what infrastructure it is running on (say via
uname)
* a plugin system for infrastructure implementations (currently all coded
into bosh_agent)
* a plugin system for platform implementations (currently all coded into
bosh_agent & stemcell_builder)
* allow bosh_agent to be upgraded on a running bosh deployment (when the
bosh director itself is upgrade); rather than require VM replacement to do
a stemcell upgrade - the agent & director would be kept in sync; the
stemcell would not need to be replaced regularly; it'd also support agent
upgrades on bare metal servers
* re-use existing stemcell/imaging tools rather than the bespoke
stemcell_builder

If any one part is more interesting than the other, I can start a new
thread so we can discuss that feature.

Anyone see any downsides or have any fears about these proposal bullet
points? Anything else to add?

Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

Search Discussions

  • Jeff Peckham at May 30, 2013 at 4:02 pm
    There are a lot of good ideas here.

    The agent update is being worked on already and is available as a dev
    testing tool.

    Infrastructure detection would be great and I'm sure there are tools off
    the shelf that we can use (I know that there are for detecting the
    hypervisor for example).

    As for the 1 stemcell for all infrastructures we'd have to first determine
    what the common format is. It could just be that the stemcell is a root
    directory tree as a tarball and the cpi always has to consume that and
    create the correct image. I feel like this is the feature that would be the
    most challenging right now.

    ~Jeff
    On May 30, 2013 8:44 AM, "Dr Nic Williams" wrote:

    I'd like to propose a future direction for the bosh_agent & stemcell
    builder:

    * a single stemcell for all infrastructures (currently we export one
    stemcell per infrastructure per bosh_agent release)
    * the bosh agent itself converts/finishes the VM for the target
    infrastructure when it launches (via bundled chef cookbook)
    * the bosh agent auto-detects what infrastructure it is running on (say
    via uname)
    * a plugin system for infrastructure implementations (currently all coded
    into bosh_agent)
    * a plugin system for platform implementations (currently all coded into
    bosh_agent & stemcell_builder)
    * allow bosh_agent to be upgraded on a running bosh deployment (when the
    bosh director itself is upgrade); rather than require VM replacement to do
    a stemcell upgrade - the agent & director would be kept in sync; the
    stemcell would not need to be replaced regularly; it'd also support agent
    upgrades on bare metal servers
    * re-use existing stemcell/imaging tools rather than the bespoke
    stemcell_builder

    If any one part is more interesting than the other, I can start a new
    thread so we can discuss that feature.

    Anyone see any downsides or have any fears about these proposal bullet
    points? Anything else to add?

    Nic

    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
  • Dr Nic Williams at May 31, 2013 at 3:31 am
    I did assume that the stemcells (tgz format) were all the same; pending use by a bosh CPI to create a machine image; and that their differences were only internal.


    ​But I guess each IaaS may have different bootstrap processes (user-data etc) so perhaps it's not possible?

    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic
    On Thu, May 30, 2013 at 9:02 AM, Jeff Peckham wrote:

    There are a lot of good ideas here.
    The agent update is being worked on already and is available as a dev
    testing tool.
    Infrastructure detection would be great and I'm sure there are tools off
    the shelf that we can use (I know that there are for detecting the
    hypervisor for example).
    As for the 1 stemcell for all infrastructures we'd have to first determine
    what the common format is. It could just be that the stemcell is a root
    directory tree as a tarball and the cpi always has to consume that and
    create the correct image. I feel like this is the feature that would be the
    most challenging right now.
    ~Jeff
    On May 30, 2013 8:44 AM, "Dr Nic Williams" wrote:
    I'd like to propose a future direction for the bosh_agent & stemcell
    builder:

    * a single stemcell for all infrastructures (currently we export one
    stemcell per infrastructure per bosh_agent release)
    * the bosh agent itself converts/finishes the VM for the target
    infrastructure when it launches (via bundled chef cookbook)
    * the bosh agent auto-detects what infrastructure it is running on (say
    via uname)
    * a plugin system for infrastructure implementations (currently all coded
    into bosh_agent)
    * a plugin system for platform implementations (currently all coded into
    bosh_agent & stemcell_builder)
    * allow bosh_agent to be upgraded on a running bosh deployment (when the
    bosh director itself is upgrade); rather than require VM replacement to do
    a stemcell upgrade - the agent & director would be kept in sync; the
    stemcell would not need to be replaced regularly; it'd also support agent
    upgrades on bare metal servers
    * re-use existing stemcell/imaging tools rather than the bespoke
    stemcell_builder

    If any one part is more interesting than the other, I can start a new
    thread so we can discuss that feature.

    Anyone see any downsides or have any fears about these proposal bullet
    points? Anything else to add?

    Nic

    --
    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-dev @
postedMay 30, '13 at 3:44p
activeMay 31, '13 at 3:31a
posts3
users2

2 users in discussion

Dr Nic Williams: 2 posts Jeff Peckham: 1 post

People

Translate

site design / logo © 2021 Grokbase