brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Grant <duncan.gr...@cloudsoft.io>
Subject Re: Issue running Brooklyn in Vagrant
Date Sat, 21 Oct 2017 20:36:38 GMT
Brian,

Not sure if you've seen but Thomas has started the process of getting a
brooklyn 0.12.1 release which will have the vagrant fix in it.

All,

There's probably a better place to ask but it would seem sensible to
release a brooklyn-amabari release to go with this.  I think it's worth
fixing a couple of issues as part of this:

1) make a new catalog.bom that includes yaml versions of each java element
so that we don't have whitelisting issues due to the move to karaf.
2) include the SharedLocationSecurityGroupCustomizer in the default and
examples to make it as easy as possible to get started.

Anything else?

thanks

Duncan Grant

On Thu, 12 Oct 2017 at 13:56 Duncan Grant <duncan.grant@cloudsoft.io> wrote:

> Brian,
>
> Did you get any further with your Ambari deployment?  Hopefully my email
> was at least some help.
> I've been on holiday but I'm back online / at work now so please let me
> know if I can be of further assistance.
>
> Regards
>
> Duncan Grant
>
>
>
> On Fri, 6 Oct 2017 at 14:17 Duncan Grant <duncan.grant@cloudsoft.io>
> wrote:
>
>> So my screenshot got stripped (obviously)  - should be visible here
>> https://drive.google.com/file/d/0B_7Ae8shGZO_WHIwQzJmWjlEbVk/view?usp=sharing
>>
>>
>> On Fri, 6 Oct 2017 at 13:53 Duncan Grant <duncan.grant@cloudsoft.io>
>> wrote:
>>
>>> Brian,
>>>
>>> It looks like you're right that you need to use the catalog.bom from the
>>> open PR[1].  I've modified that PR a bit and Thomas has now merged it.
>>>
>>> As I mentioned it is also important that you get the security group
>>> configuration correct.  It needs ports 8080 and 22 open to the world (or
>>> probably more sensibly only open 22 to the ip that brooklyn is running
>>> on).  And it needs all tcp and udp traffic allowed from other members of
>>> the security group.  See the attached screenshot for an example.  To open
>>> all the ports to other nodes in the security group you need to first create
>>> the security group and then edit it to add those rules.
>>>
>>> To get a simple cluster up and running you should now be able to do:
>>>
>>> br add-catalog catalog.bom
>>>
>>> And then deploy with the following yaml via the yaml editor:
>>>
>>> location:
>>>   jclouds:aws-ec2:
>>>     # edit these to use your credential (or delete if credentials
>>> specified in brooklyn.properties)
>>>     identity:
>>>     credential:
>>>
>>>     region:       us-east-1
>>>
>>>     # we want Ubuntu, with a lot of RAM
>>>     osFamily:     ubuntu
>>>     minRam:       8gb
>>>
>>> services:
>>> - type: ambari-cluster-application
>>>
>>> Hopefully that will get you a working cluster.  But, you can't directly
>>> configure the services you want using that approach.  I'll try to explain
>>> why and give you a couple of options to choose from.  (I'm also going to
>>> have a chat with Thomas about how we should describe all this in the README)
>>>
>>> So we've recently been extending brooklyn with karaf.  Among other
>>> things this makes adding blueprints, particularly those with a mix of java
>>> and yaml, easier and more secure.  And at each step someone has helpfully
>>> added this to the brooklyn-ambari README.  But, it's got a bit confusing.
>>>
>>> When you use the br add-catalog command you are adding a pre-configured
>>> version of brooklyn-ambari which also pulls in the jars that it needs.
>>> When you deploy brooklyn-ambari as above you can only configure the number
>>> of amp worker nodes.  You can't change the HDP services, operating system,
>>> ram, etc.  Modifying the catalog.bom to include the services you want and
>>> with the correct name of the security group would probably be the best
>>> place to start.
>>>
>>> I think the above is the best approach but I'm going to write up the
>>> various other alternatives and I'll let you know once I'm done.
>>>
>>> Duncan
>>>
>>>
>>> [1] https://github.com/brooklyncentral/brooklyn-ambari/pull/126
>>> [image: Screen Shot 2017-10-06 at 13.09.22.png]
>>>
>>>
>>> On Fri, 6 Oct 2017 at 09:57 Thomas Bouron <
>>> thomas.bouron@cloudsoftcorp.com> wrote:
>>>
>>>> Hi Brian.
>>>>
>>>> Thanks for the very detailed email/gist, this kind of feedback is very
>>>> valuable to the community and help us deliver the best possible
>>>> experience.
>>>>
>>>> Regarding your vagrant issues:
>>>> - downloading the released vagrant version 0.12.0[1] won't work
>>>> unfortunately. This was released as part of Brooklyn 0.12.0 and contains
>>>> the bug you mentioned on your first email. We don't re-release under the
>>>> same version therefore what you need to download is the next SNAPSHOT
>>>> version available here[2]. This contains the fix I made for the symlink
>>>> (my
>>>> apologies, I should have mentioned it to you earlier)
>>>> - the `bento/centos-7.3` box does work on macOS (I am running macOS
>>>> myself)
>>>> We choose this box over the official one for several reasons[3]. The
>>>> error
>>>> message I mentioned was present in the logs you provided in your first
>>>> email. Not sure exactly what is going on here but I cannot reproduce
>>>> this
>>>> on my environment unfortunately.
>>>>
>>>> Anyhow, swapping you box for `geerlingguy/centos7` is fine as long as it
>>>> works for you: that's the most important thing!
>>>>
>>>> Regarding your brooklyn-ambari issues, I can help you on this.
>>>> Although, I
>>>> see that Duncan already jumped in so it is up to you.
>>>>
>>>> Best.
>>>>
>>>> [1]
>>>>
>>>> https://www.apache.org/dyn/closer.lua?action=download&filename=brooklyn/apache-brooklyn-0.12.0/apache-brooklyn-0.12.0-vagrant.tar.gz
>>>> [2]
>>>>
>>>> https://repository.apache.org/service/local/artifact/maven/redirect?r=snapshots&g=org.apache.brooklyn&a=brooklyn-vagrant&v=0.13.0-SNAPSHOT&c=dist&e=tar.gz
>>>> [3] https://github.com/apache/brooklyn-dist/pull/86
>>>>
>>>> On Thu, 5 Oct 2017 at 20:00 Brian Long <brianblong@gmail.com> wrote:
>>>>
>>>> > Hi all,
>>>> >
>>>> > Sorry for the spam -- I'm just getting used to the plain text mailing
>>>> > list.  If you prefer HTML formatting, I've uploaded my message here:
>>>> > https://gist.github.com/b-long/9156a3696d9c30c14a092fe4b0a01381
>>>> >
>>>> > Thanks,
>>>> > b-long
>>>> >
>>>> > On Thu, Oct 5, 2017 at 3:12 PM, Brian Long <brianblong@gmail.com>
>>>> wrote:
>>>> > > Hi Thomas,
>>>> > >
>>>> > > Sorry for my delayed response and thanks for your all of your work.
>>>> > >
>>>> > > Vagrant related
>>>> > >
>>>> > > I see that the brooklyn-dist PR that you referenced [0] was indeed
>>>> merged
>>>> > > and I agree it appears that it would fix the symlink issue I’ve
>>>> observed.
>>>> > > However, when I download the Vagrant tar archive, I’m still getting
>>>> the
>>>> > same
>>>> > > MD5 sum that was produced back on September 27th:
>>>> > > 331ab054e08a0b8c0480621b2f2adfe4 . To download the Vagrant archive,
>>>> I’m
>>>> > > using the command found at https://brooklyn.apache.org/#get-started
>>>> :
>>>> > > curl -SL --output apache-brooklyn-0.12.0-vagrant.tar.gz
>>>> > > "
>>>> >
>>>> https://www.apache.org/dyn/closer.lua?action=download&filename=brooklyn/apache-brooklyn-0.12.0/apache-brooklyn-0.12.0-vagrant.tar.gz
>>>> > "
>>>> > >
>>>> > > So, this yields a new question about the update process for
>>>> mirrors. Is
>>>> > it
>>>> > > working? Or perhaps I didn’t understand the release model with
>>>> > > brooklyn-dist.
>>>> > >
>>>> > > Anyhow, I still need to apply the fix I mentioned previously
>>>> (linking and
>>>> > > restarting the service after vagrant up) [1]. Unfortunately, I’m
>>>> still
>>>> > > experiencing issues with the bento/centos-7.3 boxes too, so I’m
>>>> > continuing
>>>> > > to change the box variable to geerlingguy/centos7. I appreciate
your
>>>> > help in
>>>> > > debugging this. You referenced an error message with the text
>>>> “Could not
>>>> > > find the X.Org or XFree86 Window System, skipping.” . Is this
>>>> expected to
>>>> > > work on macOS? Is there a simple method of testing the integration?
>>>> > >
>>>> > > My approach is still working for me, and once the service is
>>>> running I
>>>> > can
>>>> > > access Brooklyn from my host, at http://localhost:8081 .
>>>> > >
>>>> > > Deployment related
>>>> > >
>>>> > > After getting Brooklyn started, the thing I’m eager to use more
than
>>>> > > anything is Ambari. Here are the steps I’ve done, attempting
>>>> deployment:
>>>> > >
>>>> > > # Install the Brooklyn command line tool
>>>> > > brew install apache-brooklyn-cli
>>>> > >
>>>> > > # Authenticate to Brooklyn
>>>> > > br login http://localhost:8081/
>>>> > >
>>>> > > # Get the Brooklyn Ambari repo
>>>> > > git clone https://github.com/brooklyncentral/brooklyn-ambari.git
>>>> > >
>>>> > > cd brooklyn-ambari
>>>> > >
>>>> > > # Add Ambari to Brooklyn's catalog
>>>> > > br add-catalog catalog.bom
>>>> > >
>>>> > > Next, in AWS, I had to establish my Security Group. I first created
>>>> a
>>>> > > security group called test-ambari and opened ports 8080 according
>>>> to the
>>>> > > brooklyn-ambari README. This failed, reasonably, since I know Ambari
>>>> > needs
>>>> > > 8440 for coordinating agent nodes. In a third or fourth iteration,
>>>> I saw
>>>> > an
>>>> > > error that referenced port 22. At that point, I decided to just
open
>>>> > things
>>>> > > up a lot wider, in hopes that the networking would get everything
>>>> working
>>>> > > properly. My final Security Group, with speculative rules for TCP
>>>> > > connections from anywhere is the following:
>>>> > >
>>>> > > * 8080   # The Ambari web UI
>>>> > > * 24007  # I saw mention of GlusterFS in the logs
>>>> > > * 24008  # Again, for GlusterFS
>>>> > > * 8441   # Ambari Registration and Heartbeat Port
>>>> > > * 22     # It seems the Brooklyn control machine has to SSH to
>>>> Ambari
>>>> > nodes
>>>> > > * 8440   # Ambari Agent orchestration
>>>> > > * 2181   # ZooKeeper
>>>> > >
>>>> > > Next, from the Brooklyn web UI, I navigate to the Composer / editor
>>>> and
>>>> > > enter this YAML:
>>>> > >
>>>> > > location:
>>>> > >   jclouds:aws-ec2:
>>>> > >     # edit these to use your credential (or delete if credentials
>>>> > specified
>>>> > > in brooklyn.properties)
>>>> > >     identity:     <redacted>
>>>> > >     credential:   <redacted>
>>>> > >
>>>> > >     region:       us-east-2
>>>> > >
>>>> > >     # we want Ubuntu, with a lot of RAM
>>>> > >     osFamily:     ubuntu
>>>> > >     minRam:       8gb
>>>> > >
>>>> > >     # set up this user and password (default is to authorize a
>>>> public
>>>> > key)
>>>> > >     user:         sample
>>>> > >     password:     s4mpl3
>>>> > >
>>>> > > services:
>>>> > > - type: ambari-cluster-application
>>>> > >   name: Ambari Cluster
>>>> > >   brooklyn.config:
>>>> > >     securityGroup: test-ambari
>>>> > >     initialSize: 3
>>>> > >     services:
>>>> > >     - FALCON
>>>> > >     - FLUME
>>>> > >     - GANGLIA
>>>> > >     - HBASE
>>>> > >     - HDFS
>>>> > >     - KAFKA
>>>> > >     - KERBEROS
>>>> > >     - MAPREDUCE2
>>>> > >     - OOZIE
>>>> > >     - PIG
>>>> > >     - SLIDER
>>>> > >     - SQOOP
>>>> > >     - YARN
>>>> > >     - ZOOKEEPER
>>>> > >
>>>> > > After clicking the Deploy button, 4 instances are created in AWS.
>>>> Here’s
>>>> > a
>>>> > > screenshot:
>>>> > > https://drive.google.com/file/d/0B91hmcyKP8SzLTRHcTdTZFkzWG8/view
>>>> > >
>>>> > > I can watch, in the Brooklyn UI, that there is communication
>>>> between the
>>>> > > Brooklyn Vagrant VM and these EC2 hosts. Screenshot:
>>>> > > https://drive.google.com/file/d/0B91hmcyKP8SzR0R2bFFDYWhCUk0/view
>>>> > >
>>>> > > Eventually, all 3 Ambari agent nodes seem to be in a happy state.
>>>> > > Unfortunately, the Ambari Server is not:
>>>> > >
>>>> > > Screenshot:
>>>> > > https://drive.google.com/file/d/0B91hmcyKP8SzZzZ1XzF1UmZQZkU/view
>>>> > >
>>>> > > Screenshot:
>>>> > > https://drive.google.com/file/d/0B91hmcyKP8SzYkQ4N1dXeVVnUEU/view
>>>> > >
>>>> > > When I attempt to open port 8080 (Ambari web UI) on the Ambari
>>>> server,
>>>> > I’m
>>>> > > receiving an error. Screenshot:
>>>> > > https://drive.google.com/file/d/0B91hmcyKP8SzUkF2MGJWeFNCNDQ/view
>>>> > >
>>>> > > I know that at one point, things were working to a greater degree
>>>> than I
>>>> > am
>>>> > > seeing now. Unfortunately, I don’t recall how I managed to
>>>> accomplish
>>>> > that
>>>> > > (maybe using the newer BOM file from this PR [2] or perhaps it
was
>>>> the
>>>> > BYON
>>>> > > / Vagrant nodes). I was, at one point, able to login to Ambari.
I
>>>> found
>>>> > it
>>>> > > really great that there was a Brooklyn generated password for the
>>>> > service.
>>>> > > As a last ditch effort for today, I did try the former on AWS and
>>>> didn’t
>>>> > > have success.
>>>> > >
>>>> > > Wrapping up
>>>> > >
>>>> > > My team and I need move quickly, and unfortunately, if I can’t
get
>>>> things
>>>> > > working with Brooklyn soon - I’ll need to change my approach.
>>>> > >
>>>> > > I think the Brooklyn team has a very serious opportunity if you
can
>>>> > support
>>>> > > Ambari. I say that, since I’m not totally satisfied with the
job
>>>> that
>>>> > > Hortonworks is doing supporting FLOSS deployments of the Hadoop
>>>> ecosystem
>>>> > > and Ambari. Presumably, if you can support the baseline, you’ll
>>>> inherit a
>>>> > > variety of other services.
>>>> > >
>>>> > > Furthermore, since Brooklyn has first-class support for load
>>>> balancing
>>>> > and
>>>> > > resizing, Hadoop users get serious value in being able to scale
>>>> > workloads.
>>>> > > The possibility of developing / testing distributed workloads on
>>>> local
>>>> > VMs
>>>> > > is another value not so well supported in the open source.
>>>> > >
>>>> > > Lastly, if we could get Apache Ranger working (via an Ambari +
>>>> Brooklyn
>>>> > > configuration), then Brooklyn could provide a very rich feature
set
>>>> for
>>>> > > securing clusters, data, and custom endpoints. Perhaps some other
>>>> Apache
>>>> > > folks would be willing to help with this integration?
>>>> > >
>>>> > > Thanks for all your help,
>>>> > > b-long
>>>> > >
>>>> > > 0: https://github.com/apache/brooklyn-dist/pull/111
>>>> > > 1: https://gist.github.com/b-long/ab096f45a7867574b74f01adff9f6c22
>>>> > > 2: https://github.com/brooklyncentral/brooklyn-ambari/pull/126
>>>> >
>>>> --
>>>>
>>>> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
>>>> https://cloudsoft.io/
>>>> Github: https://github.com/tbouron
>>>> Twitter: https://twitter.com/eltibouron
>>>>
>>>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message