[bosh-users] inception VM must be in same account/region as micro_bosh?

Yes, as it attaches an ebs volume it writes the stemcell to, which then is
turned into an AMI:
https://github.com/cloudfoundry/bosh/blob/master/aws_cpi/lib/cloud/aws/cloud.rb#L283

/M

Ok.

Theoretically, the creation of an AMI only needs to be done once per IaaS/region per micro-cloud-stemcell version?

Could we add an optional step to the micro-bosh-stemcell release process and allow for the created AMI to be made public and reusable by others? Or is it better to continue with each IaaS/region/account requiring a minimum of 2 VMs (the microbosh VM for the IaaS/region/account and the inception VM for that microbosh)?

In my mind, one BOSH per region/account is already excessive (I understand it comes from the need to manage its own stemcells; rather than use a public stemcell/AMI).

Requiring one Inception VM per region/account is doubly excessive.

Since April release of BOSH, there has been only one AWS stemcell version (bosh-stemcell-aws-0.5.1.tgz). If a BOSH could use a public AMI instead of building its own AMIs, then a BOSH could conceptually manage multiple IaaS/region/accounts. The properties.aws / properties.pistoncloud configuration would move from the BOSH configuration into the Deployment Manifest.

I understand its a big refactoring. For my own understanding, is it technically possible to have (one BOSH & one Inception VM) managing multiple IaaS/region/account combinations, if it were using public images rather than building its own (which are identical to each other because they come from the same stemcell version)?

Nic

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

I mentioned 'Since April release of BOSH, there has been only one AWS stemcell version (bosh-stemcell-aws-0.5.1.tgz)' without saying why I mentioned it :)

Let me rewrite that sentence :)

Since April release of BOSH, there has been only one AWS stemcell version (bosh-stemcell-aws-0.5.1.tgz) which suggests they aren't being released every week, rather they are relatively stagnant base OS definitions. We could optimize the BOSH workflow by pushing the stemcells out into public AMIs; and allow BOSH deployment manifests to use public images (e.g. AMIs, built from stemcell definitions).

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

out all wrinkles in it with the new stemcell builder before i can release
it. If you want access to my work-in-progress, use ami-0743ef6e. Note that
it requires the un-merged change:
http://reviews.cloudfoundry.org/#/c/6960/

and you need to add this to your micro_bosh.yml
cloud:
properties:
stemcell:
kernel_id: aki-b4aa75dd
root_device_name: /dev/sda1

cheers,
/Martin

In a world with micro bosh AMIs, what is the "bosh micro" command sequence?

Currently, the argument to "bosh micro deploy" is a local stemcell.tgz path.

Would it be: "bosh micro deploy ami-0743ef6e"?

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

Correct :)

cheers,
/Martin

Hi Martin,

I have followed the Dr Nic's tutorial and attempted to deploy the
micro-bosh-stemcell in the ap-southeast-1 region.
As there is no AMI for this region I am using the public stemcell isntead.
The AMI is created but the instance fails to boot.

I suspect I am not choosing the proper kernel.
I have tried canonical's kernel for lucid and precise and also the kernel
mentioned in another thread for this region.

Could you give me a hint?

In the default region the microbosh-stemcell does boot.

Thanks,
Hugues

Hi Hugues!

Once I merge my latest AWS CPI change[1] I'll be able to release a new
set of gems, a new AMI and a new stemcell, which will make life easier
for you. Mike is also working on a script to make the AMI available in
all regions.

[1] <http://reviews.cloudfoundry.org/#/c/6960/>

Cheers,
/Martin

On Mon, Jul 9, 2012 at 6:42 PM, Hugues Malphettes
wrote:

Great. Thanks a lot!
Let me know if you want me to test something.
Hugues

Hugues,

it took a while, but here is the how you get started with bosh on aws:
https://groups.google.com/a/cloudfoundry.org/d/msg/bosh-users/AbD_BapJZR4/05u_MJDe3GQJ

/M

On Mon, Jul 9, 2012 at 9:13 PM, Hugues Malphettes
wrote:

Thanks for the heads-up Martin.
Cheers,
Hugues

2012707/10//15.01//<[email protected]>

Yes, we want to publish public AMIs for both the stemcell and
deployer-stemcell.

Regarding having one deployer target multiple regions, I think it will
require mostly work on the registry side since I think it will require a
registry per region.

Also, I'm not sure what to do regarding the message bus since the latency
cross regions starts getting higher.

Is your goal to have a single deployment span regions? Or one deployment
per region?

-Vadim

On Jul 6, 2012, at 9:26 AM, Dr Nic Williams wrote:

Ok.

Theoretically, the creation of an AMI only needs to be done once per
IaaS/region per micro-cloud-stemcell version?

Could we add an optional step to the micro-bosh-stemcell release process
and allow for the created AMI to be made public and reusable by others? Or
is it better to continue with each IaaS/region/account requiring a minimum
of 2 VMs (the microbosh VM for the IaaS/region/account and the inception VM
for that microbosh)?

In my mind, one BOSH per region/account is already excessive (I understand
it comes from the need to manage its own stemcells; rather than use a
public stemcell/AMI).

Requiring one Inception VM per region/account is doubly excessive.

Since April release of BOSH, there has been only one AWS stemcell version
(bosh-stemcell-aws-0.5.1.tgz). If a BOSH could use a public AMI instead of
building its own AMIs, then a BOSH could conceptually manage multiple
IaaS/region/accounts. The properties.aws / properties.pistoncloud
configuration would move from the BOSH configuration into the Deployment
Manifest.

I understand its a big refactoring. For my own understanding, is it
technically possible to have (one BOSH & one Inception VM) managing
multiple IaaS/region/account combinations, if it were using public images
rather than building its own (which are identical to each other because
they come from the same stemcell version)?

Nic

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

On Friday, July 6, 2012 at 9:09 AM, Martin Englund wrote:

Yes, as it attaches an ebs volume it writes the stemcell to, which then is
turned into an AMI:
https://github.com/cloudfoundry/bosh/blob/master/aws_cpi/lib/cloud/aws/cloud.rb#L283

/M

On Fri, Jul 6, 2012 at 8:53 AM, Dr Nic Williams wrote:

When I create a micro BOSH, must the inception VM (where "bosh micro
deploy" is run) be in the same IaaS account/region (that is, effectively
have the same properties.aws)?

Nic


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

Dr Nic Williams - VP Developer Evangelism

[image: Engine Yard]

The Leading Platform as a Service

Mobile: 415 860 2185

Skype: nicwilliams

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

Goal is to have one deployment per region; I wasn't even so ambitious as to ponder multi-region deployments yet :)

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

Martin, you can specify different aws attributes at the deploy manifest
file (credentials, endpoint, ...) and all the process (create, mount disk
and copy stemcell) are performed in the micro-bosh vm not in the inception
vm as the stemcell is upload to the micro-bosh. So in theory you can deploy
a micro.bosh in a different account/region, or am I missing something?

What I assume is that when you have a micro-bosh (director), all the
releases must be deployed in the same account/region.

- Ferdy

2012/07/06//18.43//<[email protected]>