I do note the new issue Richard raised about the slow start, BROOKLYN-601. I don't necessarily see this as a blocker, as it's something that can be worked around, but I guess it would be nice to fix it, so I could probably be persuaded to change my vote :-) . What does anyone else think?
G On Thu, 13 Sep 2018 at 23:00 Geoff Macartney <[email protected]> wrote: > +1 from me > > Checks successfully completed: > [✓] Download links work. > [✓] Checksums and PGP signatures are valid. > [✓] Expanded source archive matches contents of RC tag. > [✓] Expanded source archive builds and passes tests. > [✓] LICENSE is present and correct. > [✓] NOTICE is present and correct, including copyright date. > [✓] No compiled archives bundled in source archive. > [✓] apache-brooklyn-1.0.0-M1-bin and br (on OSX) binaries work > [✓] I follow this project’s commits list > [✓] Deployed and stopped two of the provided sample apps on AWS > > Geoff > > > > > On Thu, 13 Sep 2018 at 13:31 Aled Sage <[email protected]> wrote: > >> +1 from me. >> >> Here's what I tested: >> >> 1. installed/ran brooklyn (tar.gz) from local machine (os x); used it >> to spin up a blueprint for... >> 2. install/run brooklyn (rpm) on CentOS machine in AWS >> 3. deployed each of the 4 templates to aws: >> 1. server-template >> 2. bash-web-server-template >> 3. bash-web-and-riak-template >> 4. resilient-bash-web-cluster-template >> 4. deploy mysql (using https://github.com/brooklyncentral/brooklyn-mysql >> ) >> 5. deployed a dynamic cluster of 100 'server' entities to localhost. >> 6. restarted Brooklyn by running `systemctl restart brooklyn` (to >> confirm that persistence/rebind works). >> >> --- >> The one caveat is for (3.3) above: the riak cluster gave an error. Each >> node came up ok, but when it tried to run `joinCluster` for one of them >> it gave the error: >> >> 2018-09-13T12:01:18,843 - DEBUG 128 o.a.b.SSH [Thread-1521] >> [[email protected]:stdout] Node >> [email protected] is not >> reachable! >> 2018-09-13T12:01:18,859 - DEBUG 128 o.a.b.SSH [Thread-1521] >> [[email protected]:stdout] Executed >> >> /tmp/brooklyn-20180913-120117508-g2Xj-joinCluster_RiakNodeImpl_id_co.sh, >> result 1 >> >> I tried it twice - same error each time. >> >> I propose that we just create a jira issue to track this, rather than it >> blocking a milestone release. >> >> Aled >> >> >> On 12/09/2018 16:37, Thomas Bouron wrote: >> > Hi all >> > >> > It's a solid +1 to me. >> > >> > Here is the summary of my tests: >> > 1. downloaded all artifacts >> > 2. verified all signatures >> > 3. build source with tests >> > 4. launched Brooklyn vagrant and did sanity checks, i.e. up and running >> > 5. launched Brooklyn (zip) and did sanity checks, i.e. up and running >> > 6. used CLI to add locations >> > 7. deployed the 4th quick launch template (Resilient Load-Balanced >> > Bash Web Cluster (Brooklyn Example) in AWS and verify it was working >> > >> > Item 1, 2, 3 and 4 were done automatically with the attached script. >> > >> > On Wed, 12 Sep 2018 at 12:20 Richard Downer <[email protected] >> > <mailto:[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 >> > >> > -- >> > >> > Thomas Bouron >> > Senior Software Engineer >> > >> > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud >> > >> > GitHub: https://github.com/tbouron >> > Twitter: https://twitter.com/eltibouron >> > >> > Need a hand with AWS? Get a Free Consultation. >> >>
