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 <[email protected]> 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 <[email protected]> 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= >>> [email protected]}]@U09W94lm) >>> >>> Failure running task Cross-context execution: Invoking effector >>> joinCluster >>> on RiakNode:vrua with parameters {nodeName= >>> [email protected]} (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 <[email protected]> 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 [email protected] 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 <[email protected]> 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 >>> > > >>> > >>> >> >> >
