osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Release Apache Brooklyn 1.0.0-M1 [rc1]


+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 <aled.sage@xxxxxxxxx> 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]
>     [co2yobqk8m@3.120.132.118:stdout] Node
>     riak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is not
>     reachable!
>     2018-09-13T12:01:18,859 - DEBUG 128 o.a.b.SSH [Thread-1521]
>     [co2yobqk8m@3.120.132.118: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 <richard@xxxxxxxxxx
> > <mailto:richard@xxxxxxxxxx>> 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.
>
>