Re: [DISCUSS] Release Apache Brooklyn 1.0.0-M1 [rc1]
+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:
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]
riak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is not
2018-09-13T12:01:18,859 - DEBUG 128 o.a.b.SSH [Thread-1521]
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.
On 12/09/2018 16:37, Thomas Bouron wrote:
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
This thread is for discussions related to the release vote.
I should clarify what we are looking for in a release vote.
we are looking for people to download,validate, and test the release.
Only if you are satisfied that the artifacts are correct and the
high enough, should you make a "+1" vote. Alongside your vote you
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
it is about making sure that *these* artifacts are *correct* (e.g.
not corrupted, hashes and signatures pass) and are of
quality* to be stamped as an official release of The Apache Software
Why test the artifacts when master is looking good? Here are some
- somebody could have made a commit that broke it, since you last
- the release branch could have been made at the wrong point, or
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
unobtainable or corrupted
This is why the release manager needs you to download the actual
artifacts and try them out.
The way Apache works can be a bit arcane sometimes, but it's all
a reason. If the vote passes then the contents of the email and
become "endorsed" by The Apache Software Foundation, and the
take on legal liability for them, forever.
And of course we want the best possible experience for our users -
the actual release files to be tested manually to make sure that a
not ruin the experience for users.
So if you can spare an hour or more to download some of the
them out, then it will be *very* useful! The vote lasts for three
there's no need to rush to get a vote in.
Senior Software Engineer
*Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
Need a hand with AWS? Get a Free Consultation.