I've just confirmed that it does work in 0.10.0. On AWS, it picked an Ubuntu 14.04 image by default; 0.11.0 picks CentOS 7.
Now that it is a regression, I am a bit more concerned. But there is a straightforward workaround. And there are other desirable changes[1] that missed the release deadline so I think we could do a 0.11.1 release fairly soon. Leaning towards "release"... [1] https://lists.apache.org/thread.html/d97ddd9d40a8eb86987649ee6c8af0f765c68be4afba5ced61423609@%3Cdev.brooklyn.apache.org%3E On 17 May 2017 at 14:41, Aled Sage <[email protected]> wrote: > My guess for why it worked previously is that it used to default to centos > 6, whereas now it's using a centos 7 vm image that has different default > config. > > I agree it should not block the release. > > Aled > > Sent from my iPhone > > > > On 17 May 2017, at 15:25, Geoff Macartney <geoff.macartney@ > cloudsoftcorp.com> wrote: > > > > 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 <[email protected]> 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 <[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 > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> >
