Could each person who doesn't want to use bosh to deploy CF please drop a
couple of bullets in a reply and outline their objections and/or
requirements for how they want to deploy/own/operate/upgrade/scale
CloudFoundry, CF services, etc?

I'm interested to understand the requirements that IT/ops people have, and
determine if there are some alternate experiences of bosh/cf-release that
could be created; or if we can continue to improve bosh and it's UX and its
support of IaaSes and you'll be super happy in the future.


--
Dr Nic Williams
http://drnicwilliams.com
cell +1 (415) 860-2185

Search Discussions

  • David Laing at Jan 28, 2013 at 7:56 pm
    Before CF chef was my devops tool of choice. As I began to get my head
    around CF, I found myself trying to reduce the complexity by avoiding also
    learning BOSH.

    Perhaps many newcomers to CF hav a similar reaction to me. Lacking a
    succinct "this is why using BOSH is simplier in the long run rather than
    Chef" post, I think many people gravitate towards the dev_chef recipes.

    Anyone else have the same experiences?
    On Monday, January 28, 2013, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop a
    couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have, and
    determine if there are some alternate experiences of bosh/cf-release that
    could be created; or if we can continue to improve bosh and it's UX and its
    support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
    --
    David Laing
    Open source @ City Index - github.com/cityindex
    http://davidlaing.com
    Twitter: @davidlaing
  • Adam C. Greenfield at Jan 28, 2013 at 8:56 pm
    For me, I see it as a benefit of CloudFoundry that it is agnostic to what types of systems it runs on (VMs, bare metal, etc). I've deployed CloudFoundry using my existing Operational Support Tools to virtualized and physical (and in some cases mixed) environments.

    BOSH (by necessity) means accepting more constraints and having broad access to the underlying Infrastructure providers. If we don't offer automation, documentation and resources for deploying CloudFoundry any other way - it makes those effective constraints of CloudFoundry. It benefits CloudFoundry to be made to work in as many situations as possible, even if BOSH isn't realistic for a given environment or use case. It seems that simple methods to deploy CloudFoundry (like micro), potentially chef recipes, or a dev_setup like install system all have merit in lowering the barrier to entry.

    That said, part of the beauty of this being open source is that anyone who wants those alternative methods is free to contribute them. To your point I would hope that they could be created and integrated in the project. I also hope that BOSH continues to improve and support additional platforms. Both of these projects seem to have a huge amount of merit and potential.

    --
    Adam C. Greenfield

    On Monday, January 28, 2013 at 1:22 PM, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop a couple of bullets in a reply and outline their objections and/or requirements for how they want to deploy/own/operate/upgrade/scale CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have, and determine if there are some alternate experiences of bosh/cf-release that could be created; or if we can continue to improve bosh and it's UX and its support of IaaSes and you'll be super happy in the future.

    --
    Dr Nic Williams
    http://drnicwilliams.com (http://drnicwilliams.com/)
    cell +1 (415) 860-2185
  • Jawaid Ekram at Jan 29, 2013 at 2:20 am
    We initially used Chef but after six migrated to BOSH as
    our deployment tool. The key thing about BOSH is that it is an IT/Ops
    framework that provides full operational life cycle from initial deployment
    to upgrade. It dose it for most part without taking the service down. You
    need BOSH or BOSH like tool in you want to run 7x24 service. People running
    Dev. / Test cloud can away without BOSH. I just do not see how one can run
    an online service with some thing like BOSH.
    On Monday, January 28, 2013 10:22:49 AM UTC-8, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop a
    couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have, and
    determine if there are some alternate experiences of bosh/cf-release that
    could be created; or if we can continue to improve bosh and it's UX and its
    support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
  • Andrea Campi at Jan 29, 2013 at 12:23 pm
    Many organizations have or are evaluating a configuration management tool
    to configure and deploy at least parts of the infrastructure.
    When bringing CF into the picture, it likely needs to integrate with that
    for some support functions; be it the CCDB (that may be provisioned on an
    existing PostgreSQL cluster), backup, monitoring and so on.


    The argument here is twofold, technical and organizational.

    From an organizational point of view, if they are already running Chef (or
    Puppet for that matter), BOSH is an extra piece that they will only use for
    CF; and that increases the "total cost of ownership" (hardware, software,
    staffing, training).
    And even if they are not yet, most of our customers would rather introduce
    something that they can reuse.


    From a technical point of view, Chef allows us to "mix and match" a CF
    cluster with existing infrastructure in a loosely-coupled, dynamic way.
    E.g. you can configure an external, shared LB to point to only the CF
    routers that you are alive at this time, based on "labels" (roles, in Chef
    parlance) that you attach to nodes. And again, maybe that's side by side
    with other non-CF sites.



    Note this is based mostly on our conversations with relatively small teams
    in non-mission-critical environments; startups of course, but also software
    development and QA teams in banks and smaller telcos and service providers.
    I realize my arguments may be moot for e.g. larger telcos where they care
    more about the "turnkey", more predictable, more controlled environment of
    BOSH.

    That's kind of similar to a "CF vs AppDirector" argument--there's place for
    both :)
  • Yssk22 at Jan 29, 2013 at 3:01 pm
    we actually use our custom chef script and automation framework on top of
    Chef in our company.

    - We need to integrate existent assets with our new cloudfoundry based
    architecture. We have not evaluate Bosh is useful for that purpose or not.
    - We are in charge of CF deployment but do not have full access control of
    VM/Network layer so that Bosh cannot be used (especially for CPI part).
    - We need to understand what are changed in CF. CF team don't provide any
    release notes, change logs, or there are no tags except for cf-releases so
    far. To learn CF changes, not only viewing diffs but also make a custom
    deployment script is useful.
    - Chef is so common that we can reuse know-hows everywhere. it's important
    to educate ops people.

    and in terms of CF services, it actually don't scale at the view point of
    applications. e.g. MongoDB does not have replica-set nor sharding feature.
    so we are developing a custom cluster support services though it is not
    Bosh issue but CF architecture issue.

    2013年1月29日火曜日 3時22分49秒 UTC+9 Dr Nic Williams:
    Could each person who doesn't want to use bosh to deploy CF please drop a
    couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have, and
    determine if there are some alternate experiences of bosh/cf-release that
    could be created; or if we can continue to improve bosh and it's UX and its
    support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
  • Joel Eric at Jan 29, 2013 at 3:19 pm
    The instructions at https://github.com/cloudfoundry/vcap are for
    vcap_dev_setup.sh. If this is out of date as mentioned in recent threads
    then the instructions should point to bosh. Getting started with CF.org is
    a little tricky because there isn't anything that tells you where to begin.
    On Monday, January 28, 2013 12:22:49 PM UTC-6, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop a
    couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have, and
    determine if there are some alternate experiences of bosh/cf-release that
    could be created; or if we can continue to improve bosh and it's UX and its
    support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
  • James Bayer at Jan 29, 2013 at 6:07 pm
    "Where to begin?" - This is a known pain that Matt Reider is helping to
    coordinate a solution for with the docs repo [1] that is currently hosted
    on GitHub pages [2] that we will promote to be the one place for all docs
    on docs.cloudfoundry.com. They have already made a bunch of progress since
    last week.

    [1] https://github.com/cloudfoundry/docs
    [2] http://cloudfoundry.github.com/
    On Tuesday, January 29, 2013 7:19:34 AM UTC-8, Joel Eric wrote:

    The instructions at https://github.com/cloudfoundry/vcap are for
    vcap_dev_setup.sh. If this is out of date as mentioned in recent threads
    then the instructions should point to bosh. Getting started with CF.org is
    a little tricky because there isn't anything that tells you where to begin.
    On Monday, January 28, 2013 12:22:49 PM UTC-6, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop a
    couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have,
    and determine if there are some alternate experiences of bosh/cf-release
    that could be created; or if we can continue to improve bosh and it's UX
    and its support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
  • Matt Reider at Jan 29, 2013 at 6:39 pm
    Thanks for the plug James. Rajdeep Dua plopped most of the existing BOSH
    docs over there already. When we have everything over there, we'll end of
    life the myriad destinations for documentation - both Cloud Foundry and
    BOSH.

    Dr. Nic, who happens to be sitting next to me, attempting not to catch my
    cold, has committed to writing a little, as will our support team,
    developer relations team, and you - our community. But it's not happening
    fast enough. Let's go! Velocity! All hands on deck!

    - Captain Reider

    On Tue, Jan 29, 2013 at 10:07 AM, James Bayer wrote:

    "Where to begin?" - This is a known pain that Matt Reider is helping to
    coordinate a solution for with the docs repo [1] that is currently hosted
    on GitHub pages [2] that we will promote to be the one place for all docs
    on docs.cloudfoundry.com. They have already made a bunch of progress
    since last week.

    [1] https://github.com/cloudfoundry/docs
    [2] http://cloudfoundry.github.com/

    On Tuesday, January 29, 2013 7:19:34 AM UTC-8, Joel Eric wrote:

    The instructions at https://github.com/**cloudfoundry/vcap<https://github.com/cloudfoundry/vcap>are for vcap_dev_setup.sh. If this is out of date as mentioned in recent
    threads then the instructions should point to bosh. Getting started with
    CF.org is a little tricky because there isn't anything that tells you where
    to begin.
    On Monday, January 28, 2013 12:22:49 PM UTC-6, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop
    a couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/**scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have,
    and determine if there are some alternate experiences of bosh/cf-release
    that could be created; or if we can continue to improve bosh and it's UX
    and its support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
  • Dr Nic Williams at Jan 29, 2013 at 7:49 pm
    My every intention is to write the same docs twice - once in my own "voice"
    (that is, with sentences that start with "And.." and jokes at the end of
    sentences) and contribute the same content into the new docs.

    My priority has been to kill the need for docs for new people with the
    bosh-bootstrap & bosh-cloudfoundry tools. I'm assuming that people want to
    see everything running and fall in love with it before they are going to
    crack open the Cloud Foundry & BOSH docs on their kindle in bed :)

    *On the original thread topic* - I'm appreciating reading the replies
    people are giving. Any more perspectives or agreements with other emails?

    NIc

    On Tue, Jan 29, 2013 at 10:39 AM, Matt Reider wrote:

    Thanks for the plug James. Rajdeep Dua plopped most of the existing BOSH
    docs over there already. When we have everything over there, we'll end of
    life the myriad destinations for documentation - both Cloud Foundry and
    BOSH.

    Dr. Nic, who happens to be sitting next to me, attempting not to catch my
    cold, has committed to writing a little, as will our support team,
    developer relations team, and you - our community. But it's not happening
    fast enough. Let's go! Velocity! All hands on deck!

    - Captain Reider

    On Tue, Jan 29, 2013 at 10:07 AM, James Bayer wrote:

    "Where to begin?" - This is a known pain that Matt Reider is helping to
    coordinate a solution for with the docs repo [1] that is currently hosted
    on GitHub pages [2] that we will promote to be the one place for all docs
    on docs.cloudfoundry.com. They have already made a bunch of progress
    since last week.

    [1] https://github.com/cloudfoundry/docs
    [2] http://cloudfoundry.github.com/

    On Tuesday, January 29, 2013 7:19:34 AM UTC-8, Joel Eric wrote:

    The instructions at https://github.com/**cloudfoundry/vcap<https://github.com/cloudfoundry/vcap>are for vcap_dev_setup.sh. If this is out of date as mentioned in recent
    threads then the instructions should point to bosh. Getting started with
    CF.org is a little tricky because there isn't anything that tells you where
    to begin.
    On Monday, January 28, 2013 12:22:49 PM UTC-6, Dr Nic Williams wrote:

    Could each person who doesn't want to use bosh to deploy CF please drop
    a couple of bullets in a reply and outline their objections and/or
    requirements for how they want to deploy/own/operate/upgrade/**scale
    CloudFoundry, CF services, etc?

    I'm interested to understand the requirements that IT/ops people have,
    and determine if there are some alternate experiences of bosh/cf-release
    that could be created; or if we can continue to improve bosh and it's UX
    and its support of IaaSes and you'll be super happy in the future.


    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185

    --
    Dr Nic Williams
    http://drnicwilliams.com
    cell +1 (415) 860-2185
  • Lajos papp at Jan 29, 2013 at 9:37 pm
    We started to use CF mainly for internal projects, meaning the user base is
    right now around 800 but as it gets momentum it might spread in the whole
    company, meaning several thousands users.

    Unfortunately I don't have access to the virtualisation layer so BOSH is
    out of question, although i'd love to give it a try, as updating the
    dev_setup
    is quite frustrating.

    It's also a big question: where can the community store custom chef
    recipes. For example I guess adding https support to nginx is quite common,
    but it needs a modified cookbook. I even tried to send a pullrequest,
    honestly it's even a bit euphemistic to call it a pullrequest, as it's a
    1-liner ;) but it's still in the 'review in progress' state since november
    (http://reviews.cloudfoundry.org/#/c/11479/)
  • Manipvl at Jan 30, 2013 at 12:22 pm
    How about providing user interface for administration, provisioning,
    monitoring of cf-services using RESTful URL's which in-turn can invoke BOSH
    scripts for any changes needed build into CF

    Another point is also, CF can start marketplace just what it is done for
    Application Director
    (https://solutionexchange.vmware.com/store/content/getting-started-with-vmware-cloud-application-management-marketplace)
    or a similar initiative so community can start uploading BOSH scripts,
    plugins etc for knowledge sharing

    There is should also be case study or white papers of deployment of CF in
    various forums like You tube, VMware, Cloudfoundry.com, which iterate how
    the deployment is done, which IaaS, how to achieve scalability, monitoring,
    database cluster deployment using postgres. I could see lot of articles and
    you tube videos for vFabric but not for cloud foundry

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedJan 28, '13 at 6:22p
activeJan 30, '13 at 12:22p
posts12
users11

People

Translate

site design / logo © 2021 Grokbase