[
https://issues.apache.org/jira/browse/BIGTOP-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838252#comment-13838252
]
Sean Mackrory commented on BIGTOP-1072:
---------------------------------------
A couple of other thoughts:
* We should also `hadoop fs -mkdir /user/vagrant && hadoop fs -chown
vagrant:vagrant /user/vagrant` to give the default SSH user a home directory to
run jobs, etc.
* It looks like the config directory is not actually used. If that's the case,
might I suggest just removing that line altogether or renaming it to something
generic to represent it's just a shared directory?
The Hadoop PI job keeps timing out on me. I'll have to investigate why. Given
that this is entirely new and will certainly undergo more development I don't
think we need to wait until everything's perfect to commit it though.
> Vagrant scripts for spinning up and "hydrating" bigtop vms
> -----------------------------------------------------------
>
> Key: BIGTOP-1072
> URL: https://issues.apache.org/jira/browse/BIGTOP-1072
> Project: Bigtop
> Issue Type: Bug
> Reporter: jay vyas
> Priority: Minor
> Attachments: BIGTOP-1072.1.patch
>
>
> Vagrant is a tool that spins up VMs for you and destroys them. The only real
> requirement it has is that a "base box" has been created before hand.
> At that point, you can install the VM using different provider hosts
> (kvm,virtualbox,etc...).
> The goal of vagrant is to unify VM environments for developers with
> production env. This is very similar to what bigtop aims at providing.
> Vagrant adds host/guest shared directories, static ips, and allthe other
> goodies that one has to configure manually, into vm provisioning in a vendor
> neutral fashion: Essentially giving a declarative API to VM creation.
> I would like to suggest that bigtop provides / maintains vagrant startup
> scripts that layer hadoop tools on top of a "base box" vm. This is slightly
> different than the current strategy which creates a full blown VM with hadoop
> on it. The vagrant approach provides a means for more developer
> customization of the vm artifacts being used without adding any real overhead
> (other than having vagrant installed and understanding the very simply
> vagrant recipe for creating a vm).
> Probably in the begining this could be complimentary to the boxgrinder
> created VMs, and over time, maybe people would migrated to using the vagrant
> provisioned VMs as they become more popular and use of vagrant gets more
> common in the community.
--
This message was sent by Atlassian JIRA
(v6.1#6144)