Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
MIME-Version: 1.0
References: <CABQFKi23t02s=QWxQND9UbM7H6+6smB_PqS2wZzQjUVueVRRUg@mail.gmail.com>
 <CABQFKi3umoFxy4QNDwkN=g++eQSYRPE-ocC_rtO-CNTdLOm6hw@mail.gmail.com>
 <CAE7C0Pec05sKx5wMx0qV1=qus2v_cy2DkFFBRdaFnpKF2D56Ww@mail.gmail.com>
 <CABQFKi3d7V_EzumgWVMXxP2gSu-BxQDREwJmsvHWKuTxmTPgHg@mail.gmail.com>
 <CABQFKi0NbMfVyaXLBxgKgWwPZBD_06GPiJPrYe+Q3BWmK9gT2A@mail.gmail.com> <CABQFKi1dpjqtZ+maJnOp6m1P8Vy1oeVVVzvDS=svVce_nriV7w@mail.gmail.com>
In-Reply-To: <CABQFKi1dpjqtZ+maJnOp6m1P8Vy1oeVVVzvDS=svVce_nriV7w@mail.gmail.com>
From: Geoff Macartney <geoff.macartney@cloudsoftcorp.com>
Date: Wed, 17 May 2017 13:25:01 +0000
Message-ID: <CAE7C0PcenVufd0pYr=OT2xRxJGn13ZenPME--ziWVmHPAKyULA@mail.gmail.com>
Subject: Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.11.0 [rc3]
To: Brooklyn dev <dev@brooklyn.apache.org>
Content-Type: multipart/alternative; boundary="001a113ef6aac517f3054fb8378e"
archived-at: Wed, 17 May 2017 13:25:29 -0000

--001a113ef6aac517f3054fb8378e
Content-Type: text/plain; charset="UTF-8"

Still it looks bad if one of our out-of-the-box examples doesn't work
surely?

I didn't test the templates this time round but did so in previous
releases, and they all worked then.


On Wed, 17 May 2017 at 13:52 Richard Downer <richard@apache.org> wrote:

> IRC:
>
> [13:46:09]  <richardasf> Question @here: if I'm using `openIptables:true`,
> is it expected that using JcloudsLocationCustomizer should open iptables
> ports - e.g.
>
> https://github.com/apache/brooklyn-library/blob/master/software/nosql/src/main/java/org/apache/brooklyn/entity/nosql/riak/RiakNodeImpl.java#L137-L161
> does not open iptables ports, should it?
> [13:47:06]  <valio> richardasf, no it is not expected.
> [13:48:01]  <valio> There is customer requirement for unifying port opening
> mechanism and translating security  group rules to OS firewall rules.
> [13:48:28]  <valio> I hope I will submit a suggestion for it this week.
> [13:48:39]  <richardasf> Ok, that clears up that. thanks valio
>
>
> So it appears that RiakNode is simply incompatible with iptables, so it
> should be run with `stopIptables:true` (and therefore run on a cloud which
> supports security groups or similar). So there's a simple workaround.
>
> This would also appear to NOT be a regression.
>
> In that case I'm comfortable with this not being a release blocker.
>
> Richard.
>
>
> On 17 May 2017 at 13:26, Richard Downer <richard@apache.org> wrote:
>
> > It's related to iptables. Setting `stopIptables: true` fixes the problem.
> > But setting `openIptables: true` does not - I though this odd, since
> > something is configuring the AWS security group correctly, so I don't
> > understand why it isn't also configuring iptables with the same data...
> >
> > Richard.
> >
> >
> > On 16 May 2017 at 20:37, Richard Downer <richard@apache.org> wrote:
> >
> >> Urgh, we'd better investigate. If there's a failure in one of our "try
> >> this to get started!" blueprints I'd consider that a release blocker.
> >> Hopefully there's a good reason, or at least a simple workaround...
> >>
> >> Richard.
> >>
> >> On 16 May 2017 at 17:28, Geoff Macartney <geoff.macartney@cloudsoftcorp
> >> .com> wrote:
> >>
> >>> I get this too Richard:
> >>>
> >>> start failed with error:
> >>> org.apache.brooklyn.util.core.task.DynamicSequentialTask$Que
> >>> ueAbortedException:
> >>> Cannot add a task to Task[start]@iEOrS6Mt whose queue has been aborted
> >>> (trying to add Task[Cross-context execution: Invoking effector
> >>> joinCluster
> >>> on RiakNode:d5gt with parameters {nodeName=
> >>> riak@ec2-54-154-176-140.eu-west-1.compute.amazonaws.com}]@U09W94lm)
> >>>
> >>> Failure running task Cross-context execution: Invoking effector
> >>> joinCluster
> >>> on RiakNode:vrua with parameters {nodeName=
> >>> riak@ec2-54-154-176-140.eu-west-1.compute.amazonaws.com} (lpAS8V4t):
> >>> Error
> >>> invoking joinCluster at RiakNodeImpl{id=vrua9dk6kf}: Execution failed,
> >>> invalid result 1 for joinCluster RiakNodeImpl{id=vrua9dk6kf}
> >>>
> >>>
> >>>
> >>> On Tue, 16 May 2017 at 17:03 Richard Downer <richard@apache.org>
> wrote:
> >>>
> >>> > Hello all,
> >>> >
> >>> > I'm trying out the rc3 and seeing a problem. If I deploy the
> "Template
> >>> 3"
> >>> > app (web server + Riak cluster) from the "New Application" window,
> >>> then the
> >>> > individual cluster nodes appear to start, but the cluster as a whole
> >>> goes
> >>> > on fire.
> >>> >
> >>> > Drilling down, it appears to be a "join cluster" activity which is
> >>> failing.
> >>> > The stdout of the task says:
> >>> > "Node riak@ec2-52-57-99-169.eu-central-1.compute.amazonaws.com is
> not
> >>> > reachable!"
> >>> >
> >>> > This is running in AWS EC2 in eu-central-1 - everything is in the
> same
> >>> > region.
> >>> >
> >>> > Can anybody else reproduce?
> >>> >
> >>> > Thanks
> >>> > Richard.
> >>> >
> >>> >
> >>> > On 12 May 2017 at 17:09, Richard Downer <richard@apache.org> wrote:
> >>> >
> >>> > > This thread is for discussions related to the release vote.
> >>> > >
> >>> > > I should clarify what we are looking for in a release vote.
> >>> Particularly,
> >>> > > we are looking for people to download,validate, and test the
> release.
> >>> > > Only if you are satisfied that the artifacts are correct and the
> >>> quality
> >>> > is
> >>> > > high enough, should you make a "+1" vote. Alongside your vote you
> >>> should
> >>> > > list
> >>> > > the checks that you made.
> >>> > >
> >>> > > Here is a good example:
> http://markmail.org/message/gevsz2pdciraw6jw
> >>> > >
> >>> > > The vote is not simply about "the master branch contains the
> >>> features I
> >>> > > wanted" -
> >>> > > it is about making sure that *these* artifacts are *correct* (e.g.
> >>> they
> >>> > are
> >>> > > not corrupted, hashes and signatures pass) and are of *sufficiently
> >>> high
> >>> > > quality* to be stamped as an official release of The Apache
> Software
> >>> > > Foundation.
> >>> > >
> >>> > > Why test the artifacts when master is looking good? Here are some
> >>> > reasons:
> >>> > >
> >>> > > - somebody could have made a commit that broke it, since you last
> git
> >>> > > pulled
> >>> > > - the release branch could have been made at the wrong point, or
> >>> > > inconsistently
> >>> > >   between all of the submodules
> >>> > > - something in the release process could have broken it
> >>> > > - I could have made a mistake and corrupted the files
> >>> > > - a problem with the Apache infrastructure could mean that the
> >>> release
> >>> > > files are
> >>> > >   unobtainable or corrupted
> >>> > >
> >>> > > This is why the release manager needs you to download the actual
> >>> release
> >>> > > artifacts and try them out.
> >>> > >
> >>> > > The way Apache works can be a bit arcane sometimes, but it's all
> done
> >>> > with
> >>> > > a reason. If the vote passes then the contents of the email and its
> >>> links
> >>> > > become "endorsed" by The Apache Software Foundation, and the
> >>> Foundation
> >>> > > will
> >>> > > take on legal liability for them, forever.
> >>> > >
> >>> > > And of course we want the best possible experience for our users -
> >>> so we
> >>> > > need
> >>> > > the actual release files to be tested manually to make sure that a
> >>> > mistake
> >>> > > does
> >>> > > not ruin the experience for users.
> >>> > >
> >>> > > So if you can spare an hour or more to download some of the
> >>> artifacts and
> >>> > > try
> >>> > > them out, then it will be *very* useful! The vote lasts for three
> >>> days so
> >>> > > there's no need to rush to get a vote in.
> >>> > >
> >>> > > Thanks!
> >>> > > Richard Downer
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>

--001a113ef6aac517f3054fb8378e--