[
https://issues.apache.org/jira/browse/KAFKA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215675#comment-14215675
]
Joe Stein commented on KAFKA-1173:
----------------------------------
[~ewencp] changing override.hostmanager.ignore_private_ip = false in the AWS
section didn't work :( The host manager is setting the hosts to the 192 address
cat /etc/hosts ## vagrant-hostmanager-start
192.168.50.51 broker1
192.168.50.52 broker2
192.168.50.53 broker3
192.168.50.11 zk1
The virtual box parts are great I think for folks to jump in and get up and
running quickly using vagrant and it is helpful for development and works
without futzing with it, yup. One option is we could commit that part and move
the AWS pieces to another ticket. I don't mind that but I am ok with helping to
keep testing the EC2 parts as long as it can work for folks out the box with
little issues/steps as our end game. I should have a chance to try this all
again and/or review whatever changes on Wednesday & Thursdasy (FYI gotta knock
off for the evening and tomorrow is packed). Many folks have VPC we should try
to accommodate them otherwise it just looks like Kafka isn't working (or is
harder than it really is to setup). We already get a lot of emails about EC2
and advertising hosts and everything else so this could be really helpful for
folks once it is working more.
<< The Spark EC2 scripts do a nice job of just setting up a usable default so
it's really easy to get up and running, but I'm also hesitant to have the
script automatically muck with users' security settings.
You can make it a flag to use it and have some detail about changing the flag
and what is going to happen if you do (so it is not automatic). I think if
things are going to work then folks can make the decision themselves if the
impact of that is something that is worth it for them. I think having it just
not work though without having to-do a lot kind of takes away from the "spin up
something working" aspect to the change.
We will also find out a lot more and learn what the community wants more and/or
differently as this gets in and out to the world.
> Using Vagrant to get up and running with Apache Kafka
> -----------------------------------------------------
>
> Key: KAFKA-1173
> URL: https://issues.apache.org/jira/browse/KAFKA-1173
> Project: Kafka
> Issue Type: Improvement
> Reporter: Joe Stein
> Assignee: Ewen Cheslack-Postava
> Fix For: 0.8.3
>
> Attachments: KAFKA-1173.patch, KAFKA-1173_2013-12-07_12:07:55.patch,
> KAFKA-1173_2014-11-11_13:50:55.patch, KAFKA-1173_2014-11-12_11:32:09.patch
>
>
> Vagrant has been getting a lot of pickup in the tech communities. I have
> found it very useful for development and testing and working with a few
> clients now using it to help virtualize their environments in repeatable ways.
> Using Vagrant to get up and running.
> For 0.8.0 I have a patch on github https://github.com/stealthly/kafka
> 1) Install Vagrant [http://www.vagrantup.com/](http://www.vagrantup.com/)
> 2) Install Virtual Box
> [https://www.virtualbox.org/](https://www.virtualbox.org/)
> In the main kafka folder
> 1) ./sbt update
> 2) ./sbt package
> 3) ./sbt assembly-package-dependency
> 4) vagrant up
> once this is done
> * Zookeeper will be running 192.168.50.5
> * Broker 1 on 192.168.50.10
> * Broker 2 on 192.168.50.20
> * Broker 3 on 192.168.50.30
> When you are all up and running you will be back at a command brompt.
> If you want you can login to the machines using vagrant shh <machineName> but
> you don't need to.
> You can access the brokers and zookeeper by their IP
> e.g.
> bin/kafka-console-producer.sh --broker-list
> 192.168.50.10:9092,192.168.50.20:9092,192.168.50.30:9092 --topic sandbox
> bin/kafka-console-consumer.sh --zookeeper 192.168.50.5:2181 --topic sandbox
> --from-beginning
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
