osdir.com


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

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


Hi Geoff, if this was a 1.0.0 final then I'd agree we wouldn't want an
embarrassing bug like this. But since it's a milestone release I'm happy
for it to be noted in the documentation / release notes.

Richard.


On Thu, 13 Sep 2018 at 23:28, Geoff Macartney <geoff.macartney@xxxxxxxxx>
wrote:

> 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 <geoff.macartney@xxxxxxxxx>
> 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 <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.
> >>
> >>
>