FAQ
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





The Leading Platform as a Service


Mobile: 415 860 2185


Skype: nicwilliams


Twitter: @drnic

Search Discussions

  • Martin Englund at Jul 6, 2012 at 4:09 pm
    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
    ------------------------------

    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Dr Nic Williams at Jul 6, 2012 at 4:26 pm
    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 (mailto:nwilliams@engineyard.com)> 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





    The Leading Platform as a Service


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


    Skype: nicwilliams


    Twitter: @drnic



    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Dr Nic Williams at Jul 6, 2012 at 4:30 pm
    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

    On Friday, July 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 (mailto:nwilliams@engineyard.com)> 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





    The Leading Platform as a Service


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


    Skype: nicwilliams


    Twitter: @drnic



    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Martin Englund at Jul 6, 2012 at 4:35 pm

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

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

    Yes.
    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)?

    We plan to publish the micro bosh AMI in all regions, I just have to iron
    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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Dr Nic Williams at Jul 6, 2012 at 4:43 pm
    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

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


    On Fri, Jul 6, 2012 at 9:26 AM, Dr Nic Williams (mailto:drnicwilliams@gmail.com)> wrote:
    Theoretically, the creation of an AMI only needs to be done once per IaaS/region per micro-cloud-stemcell version? Yes.
    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)?
    We plan to publish the micro bosh AMI in all regions, I just have to iron 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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Martin Englund at Jul 6, 2012 at 4:50 pm

    On Fri, Jul 6, 2012 at 9:43 AM, Dr Nic Williams wrote:
    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"?
    Correct :)

    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Hugues Malphettes at Jul 10, 2012 at 1:42 am
    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

    On Sat, Jul 7, 2012 at 12:35 AM, Martin Englund wrote:


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

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

    Yes.
    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)?

    We plan to publish the micro bosh AMI in all regions, I just have to iron
    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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."
  • Martin Englund at Jul 10, 2012 at 3:53 am
    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:
    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

    On Sat, Jul 7, 2012 at 12:35 AM, Martin Englund wrote:



    On Fri, Jul 6, 2012 at 9:26 AM, Dr Nic Williams <drnicwilliams@gmail.com>
    wrote:
    Theoretically, the creation of an AMI only needs to be done once per
    IaaS/region per micro-cloud-stemcell version? Yes.
    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)?
    We plan to publish the micro bosh AMI in all regions, I just have to iron
    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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."


    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Hugues Malphettes at Jul 10, 2012 at 4:13 am
    Great. Thanks a lot!
    Let me know if you want me to test something.
    Hugues
    On Tue, Jul 10, 2012 at 11:53 AM, Martin Englund wrote:

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

    On Sat, Jul 7, 2012 at 12:35 AM, Martin Englund wrote:



    On Fri, Jul 6, 2012 at 9:26 AM, Dr Nic Williams <
    drnicwilliams@gmail.com>
    wrote:
    Theoretically, the creation of an AMI only needs to be done once per
    IaaS/region per micro-cloud-stemcell version? Yes.
    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)?
    We plan to publish the micro bosh AMI in all regions, I just have to
    iron
    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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."


    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."
  • Martin Englund at Aug 22, 2012 at 12:56 am
    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:
    Great. Thanks a lot!
    Let me know if you want me to test something.
    Hugues
    On Tue, Jul 10, 2012 at 11:53 AM, Martin Englund wrote:

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


    On Sat, Jul 7, 2012 at 12:35 AM, Martin Englund <menglund@vmware.com>
    wrote:


    On Fri, Jul 6, 2012 at 9:26 AM, Dr Nic Williams
    <drnicwilliams@gmail.com>
    wrote:
    Theoretically, the creation of an AMI only needs to be done once per
    IaaS/region per micro-cloud-stemcell version? Yes.
    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)?
    We plan to publish the micro bosh AMI in all regions, I just have to
    iron
    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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."


    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."


    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Hugues Malphettes at Aug 22, 2012 at 1:04 am
    Thanks for the heads-up Martin.
    Cheers,
    Hugues
    On Wed, Aug 22, 2012 at 8:56 AM, Martin Englund wrote:

    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:
    Great. Thanks a lot!
    Let me know if you want me to test something.
    Hugues

    On Tue, Jul 10, 2012 at 11:53 AM, Martin Englund <menglund@vmware.com>
    wrote:
    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:
    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


    On Sat, Jul 7, 2012 at 12:35 AM, Martin Englund <menglund@vmware.com>
    wrote:


    On Fri, Jul 6, 2012 at 9:26 AM, Dr Nic Williams
    <drnicwilliams@gmail.com>
    wrote:
    Theoretically, the creation of an AMI only needs to be done once per
    IaaS/region per micro-cloud-stemcell version? Yes.
    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)?
    We plan to publish the micro bosh AMI in all regions, I just have to
    iron
    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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."


    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."


    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."
  • Bedzinski Waldemar at Jul 10, 2012 at 1:03 pm
    2012707/10//15.01//<w.r.bedzinski@gmail.com>
    thanks for you//zona 1//aB//EVRY BODY in "o"^?<<!>>
    wrb
    On 10 July 2012 03:42, Hugues Malphettes wrote:

    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

    On Sat, Jul 7, 2012 at 12:35 AM, Martin Englund wrote:


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

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

    Yes.
    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)?

    We plan to publish the micro bosh AMI in all regions, I just have to
    iron 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
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid
    enough."
  • Vadim Spivak at Jul 6, 2012 at 4:37 pm
    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
    ------------------------------




    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Dr Nic Williams at Jul 6, 2012 at 4:40 pm
    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

    On Friday, July 6, 2012 at 9:37 AM, Vadim Spivak wrote:

    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 (mailto:drnicwilliams@gmail.com)> 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 (mailto:nwilliams@engineyard.com)> 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





    The Leading Platform as a Service


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


    Skype: nicwilliams


    Twitter: @drnic



    --
    cheers,
    /Martin
    --
    Martin Englund, Staff Engineer, Cloud Foundry, VMware Inc.
    "The question is not if you are paranoid, it is if you are paranoid enough."
  • Ferdy at Jul 6, 2012 at 9:46 pm

    On Friday, July 6, 2012 6:09:14 PM UTC+2, 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
    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
  • Bedzinski Waldemar at Jul 6, 2012 at 4:44 pm
    2012/07/06//18.43//<w.r.bedzinski@gmail.com>
    thanks!
    On 6 July 2012 17:53, 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
    ------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupbosh-users @
postedJul 6, '12 at 3:53p
activeAug 22, '12 at 1:04a
posts17
users7

People

Translate

site design / logo © 2022 Grokbase