You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "jay vyas (JIRA)" <ji...@apache.org> on 2014/03/27 21:41:21 UTC

[jira] [Comment Edited] (BIGTOP-1263) Next vagrant iteration: Make easy to customize,maintain and a HA recipe.

    [ https://issues.apache.org/jira/browse/BIGTOP-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949904#comment-13949904 ] 

jay vyas edited comment on BIGTOP-1263 at 3/27/14 8:41 PM:
-----------------------------------------------------------

- For HA, yes you are right.
- But for some stuff, like EC2 provisioning, we need more than editing puppet confs.

In any case:  The main purpose here is to make it so that we can easily build bigtop clusters which are aimed at minimally representing a particaular feature or bug.  For example, on monday, maybe i want to test HA.  On tuesday, maybe im in HBase mode.  ....  So lets make these vagrant recipes more reusable, and easier to extend.  

Right now we just have one monolithic vagrant provisioner.

ill try to sketch a more concrete idea of what im thinking, but for now, something like this: 

{noformat}
bigtop/ 
    bigtop-deploy/
         vagrant/ 
              vagrant-puppet/
                      base-provisioner.sh
                        vagrant-HA-2nod-vbox/
                              custom-provisioner.sh
                        vagrant-EC2-10-node-cluster/
                              custom-provisioner.sh
                         BIGTOP-1221/
                              custom-provisioner.sh
{noformat}               

So basicallly, to play with a particular hadoop deployment, you just create a new subdirectory, and make some minor customizations and evans and I will try to maintain the base-provisioner script. 

In the end some of these sub directories might be great to contribute back to bigtop, some might just be private.  




was (Author: jayunit100):
- For HA, yes you are right.
- But for some stuff, like EC2 provisioning, we need more than editing puppet confs.

In any case:  The main purpose here is to make it so that we can easily build bigtop clusters which are aimed at minimally representing a particaular feature or bug.  For example, on monday, maybe i want to test HA.  On tuesday, maybe im in HBase mode.  ....  So lets make these vagrant recipes more reusable, and easier to extend.  

Right now we just have one monolithic vagrant provisioner.

ill try to sketch a more concrete idea of what im thinking, but for now, something like this: 

{noformat}
bigtop/ 
    bigtop-deploy/
         vagrant/ 
              vagrant-puppet
                      base-provisioner.sh
                        vagrant-HA-2nod-vbox
                              custom-provisioner.sh
                        vagrant-EC2-10-node-cluster
                              custom-provisioner.sh
                         BIGTOP-1221
                              custom-provisioner.sh
{noformat}               

So basicallly, to play with a particular hadoop deployment, you just create a new subdirectory, and make some minor customizations and evans and I will try to maintain the base-provisioner script. 

In the end some of these sub directories might be great to contribute back to bigtop, some might just be private.  



> Next vagrant iteration: Make easy to customize,maintain and a HA recipe.
> ------------------------------------------------------------------------
>
>                 Key: BIGTOP-1263
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1263
>             Project: Bigtop
>          Issue Type: Improvement
>          Components: VM
>    Affects Versions: backlog
>            Reporter: jay vyas
>
> BIGTOP-1261 now demonstrates the need for HA vagrant recipe for development and testing.   
> After we get BIGTOP-1178 in, Lets come up with a documentation on how to create custom vagrant recipes.  Specifically we want: 
> - HA HDFS cluster.  option to the vagrant recipes. 
> - vagrant based EC2 deployment
> others...
> Also in this JIRA we should generally review vagrant and think about the new features in the new Vagrant API (like the pull and push stuff). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)