Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
MIME-Version: 1.0
In-Reply-To: <969fb081-3ba3-b34c-7bd2-8268ef8e2794@gmail.com>
References: <9DB55C50-DF7E-4D6C-8DBB-3D63BA41717E@cloudsoftcorp.com>
 <8740d9b4-09a8-0e38-76b1-0d59abf596e1@gmail.com> <18B7FA84-A59C-43E5-B0CC-CC0F7FBB95A3@cloudsoftcorp.com>
 <CAE7C0Pciiacy7nzf4FUQ6sm2SiaKow8zjnL992+R-kULLPt8ig@mail.gmail.com>
 <C0C97FE2-05F5-4C96-8F2A-B9A2A22F5851@cloudsoftcorp.com> <CANaN7bE_k30azm220du16xpgT60tiOmXY_OVwahm5ZRo4Xtvrw@mail.gmail.com>
 <CA+gmfag6ey_-x7iDPJJvFmEZA3zdD0v4jYwOhtE8Ck9XyTWzVw@mail.gmail.com>
 <8abde5b7-2020-a4ce-691b-288a3b197ef6@gmail.com> <1CCAAC84-C8F5-4810-ABD3-94EF9151FAFC@cloudsoftcorp.com>
 <CABQFKi2q0GMcMR-C0TAn2zqMtDbCcgQf5r0Aaoc65KFoy89huQ@mail.gmail.com> <969fb081-3ba3-b34c-7bd2-8268ef8e2794@gmail.com>
From: Guglielmo Nigri <guglielmo.nigri@cloudsoftcorp.com>
Date: Wed, 21 Dec 2016 12:26:30 +0100
Message-ID: <CAGgioR96+uWqTNDVmD8aPV1jQQPww+F-FNMtsKo5Q5j0NoBoAQ@mail.gmail.com>
Subject: Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.10.0 [rc3]
To: dev@brooklyn.apache.org
Content-Type: multipart/alternative; boundary=001a113d039ee1c4c10544296d02
archived-at: Wed, 21 Dec 2016 11:27:07 -0000

--001a113d039ee1c4c10544296d02
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I support Aled's proposal for the time being, i.e. to produce an rc4 with
password authentication disabled as the default config.

Longer term, I'm inclined to take steps to ensure that authentication is
properly configured before running the server; but I'd leave this to
another thread.

Guglielmo

On 21 December 2016 at 11:59, Aled Sage <aled.sage@gmail.com> wrote:

> Hi all,
>
> I lean towards us changing the existing behaviour for 0.10.0 (i.e.
> producing an rc4 that fixes it).
>
> It seems risky/complicated to revert to the "pre-JAAS authentication code
> path". If there is another acceptable way, then I'd much prefer that.
>
> **Proposal**
> We disable password authentication entirely, as the default configuration=
.
> We ensure steps to configure security are well documented.
>
> As per the very long email thread in [1], this is "Alternative Proposal 2=
"
> in my email dated 2016-09-13 15:32.
>
> This got Geoff's agreement (on 2016-09-13 16:25) and also Martin's
> agreement (2016-09-13 16:56). John McCabe pointed out by way of compariso=
n
> that Jenkins deploys out-of-the-box with no auth (2016-09-08 22:05).
>
> The major benefits I see are:
>
> 1. Solves the immediate problem (i.e. backwards compatibility for
>    localhost login with no password).
> 2. Super-simple user experience, including for installing on a VM
>    (which currently still requires the horrible step of digging out the
>    auto-generated username:password, buried in the log).
> 3. Consistency for localhost + remote (getting-started instructions can
>    be simpler, rather than different depending how/where you've
>    installed it. This has not been stressed enough in the discussions
>    so far.)
> 4. Passwords are a false sense of security when using http (which is
>    still the default), given that it would be sent in plain text.
>
> We should also ensure that the vagrant install is consistent (e.g. it no
> longer needs to have an auto-populated username:password in the config
> file, and can instead rely on the default being no password).
>
> **Longer Term**
> For the next release (i.e. 0.11.0), we can continue the discussion for
> what the user experience should be long-term (e.g. on first login, it
> prompts for a username+password to be created automatically). This includ=
es
> discussion of RPM installs: on `yum install ...`, the user doesn't have a
> chance to modify the defaults in the config file before Brooklyn is start=
ed
> for the first time.
>
> For 0.11.0, we re-visit the default Karaf configuration (which I believe
> will still require the auto-generated username + password (buried in the
> log), both for localhost and remote).
>
> Aled
>
> [1] https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d
> 7396becbd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E
>
>
>
> On 20/12/2016 16:05, Richard Downer wrote:
>
>> Ok, I can reproduce this behaviour when trying to connect to a Brooklyn
>> instance on localhost.
>>
>> *But...*
>>
>> I've started up a new instance on AWS and I'm connecting to it on port
>> 8081. A username and password is printed to the console on startup, and =
I
>> can use those credentials to access the web UI. If I give the wrong
>> password, I am forbidden to access.
>>
>> So it seems that this behaviour is unique to localhost. IMO this is
>> annoying but not a release blocker - but it would be nicer to our new
>> users
>> to have a fix.
>>
>> The Brooklyn startup log says:
>> 2016-12-20 15:54:32,668 INFO  Starting Brooklyn web-console with
>> passwordless access on localhost and protected access from any other
>> interfaces (no bind address specified)
>>
>> So it seems that the "passwordless access on localhost" isn't quite true=
.
>> In that case I'd go with Svet's suggestion to remove the localhost
>> exception.
>>
>> Richard.
>>
>> On 20 December 2016 at 15:08, Svetoslav Neykov <
>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>
>> // Added DISCUSS tag
>>>
>>> There's a long related [PROPOSAL] thread on the topic -
>>> https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d7396bec
>>> bd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E <
>>> https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d7396bec
>>> bd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E> which seems t=
o
>>> have died off without consensus.
>>>
>>> Anyone want to hazard a guess for how hard to fix BROOKLYN-417?
>>>>
>>> There are two possible fixes.
>>>    * Require the autogenerated password - as simple as removing the
>>> isRemoteAddressLocalhost[1] check.
>>>    * Don't require a password. That's more complicated. It needs
>>> reverting
>>> to the pre-JAAS authentication code path, using a Filter to do the
>>> authorization. Can't say right now whether we can just get some code fr=
om
>>> git history and plug it in or things have changed considerably, assumin=
g
>>> JAAS under the hood.
>>>
>>> Svet.
>>>
>>> [1] https://github.com/apache/brooklyn-server/blob/master/
>>> rest/rest-resources/src/main/java/org/apache/brooklyn/rest/
>>> security/provider/BrooklynUserWithRandomPasswordSecurityProv
>>> ider.java#L55
>>>
>>> On 20.12.2016 =D0=B3., at 16:48, Aled Sage <aled.sage@gmail.com> wrote:
>>>>
>>>> Alex, all,
>>>>
>>>> I've created https://issues.apache.org/jira/browse/BROOKLYN-417 to
>>>>
>>> track this - and have included details from my initial investigation.
>>>
>>>> I'm in two minds about whether it blocks the release. We expect people
>>>>
>>> to quickly move to supplying credentials (rather than Brooklyn
>>> auto-generating a password). However, it does impact the initial user
>>> experience (for those running on localhost, rather than vagrant etc) -
>>> having to supply dummy username:password looks horrible. If we did ship
>>> with this, we should probably update the docs to tell people to configu=
re
>>> the credentials *before* starting brooklyn for the first time.
>>>
>>>> Anyone want to hazard a guess for how hard to fix BROOKLYN-417?
>>>>
>>>> Aled
>>>>
>>>>
>>>> On 20/12/2016 14:06, Alex Heneveld wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> -0 ?  -1 ?
>>>>>
>>>>> The "bin" build when run locally on a fresh system (no
>>>>>
>>>> brooklyn.properties)
>>>
>>>> requires that a username/password is supplied.  It doesn't do any
>>>>> authentication of the local credentials but gives a 401 if not
>>>>> supplied.
>>>>> Specifically:
>>>>>
>>>>> $ curl -v http://localhost:8081/ 2>&1 | grep "< HTTP"
>>>>> < HTTP/1.1 401 Unauthorized
>>>>>
>>>>> $ curl -u anyuser:passwordignored -v http://localhost:8081/ 2>&1 |
>>>>>
>>>> grep "<
>>>
>>>> HTTP"
>>>>> < HTTP/1.1 200 OK
>>>>>
>>>>> I'm inclined to think this should block a release as it will break an=
y
>>>>> workflow that expects local http to work, and will irritate new users
>>>>> without any security benefits, but I could be talked in to forgiving
>>>>> it.
>>>>>
>>>>> --A
>>>>>
>>>>>
>>>>> On 20 December 2016 at 13:41, Andrea Turli <andrea.turli@cloudsoftcor=
p.
>>>>>
>>>> com>
>>>
>>>> wrote:
>>>>>
>>>>> +1 (binding)
>>>>>>
>>>>>> Tested by running Svet's verify script.
>>>>>>
>>>>>> Do a clean extract of source repo for next steps.
>>>>>>
>>>>>> -------------------------------------------
>>>>>>
>>>>>> Checks successfully completed:
>>>>>> [=E2=9C=93] Download links work.
>>>>>> [=E2=9C=93] Checksums and PGP signatures are valid.
>>>>>> [=E2=9C=93] Expanded source archive matches contents of RC tag.
>>>>>> [=E2=9C=93] Expanded source archive builds and passes tests.
>>>>>> [=E2=9C=93] LICENSE is present and correct.
>>>>>> [=E2=9C=93] NOTICE is present and correct, including copyright date.
>>>>>> [=E2=9C=93] No compiled archives bundled in source archive.
>>>>>>
>>>>>> Additional manual steps done (execute in source distribution folder
>>>>>> apache-brooklyn-0.10.0-src:
>>>>>>   * Check for files with invalid headers in source distribution. The=
re
>>>>>>
>>>>> are
>>>
>>>> already files excluded from RAT checks, do a sanity check.
>>>>>>   * Check for binary files in source distribution. Look for files
>>>>>> which
>>>>>>
>>>>> are
>>>
>>>> created/compiled based on other source files in the distribution.
>>>>>>
>>>>> "Primary"
>>>
>>>> binary files like images are acceptable.
>>>>>>
>>>>>> Checks left to do manually with the help of above instructions:
>>>>>> [=E2=9C=93] All files have license headers where appropriate: I reli=
ed on the
>>>>>>
>>>>> rat
>>>
>>>> check when running `mvn clean install` for checking that "all files
>>>>>>
>>>>> have
>>>
>>>> license headers where appropriate".
>>>>>> [-] All dependencies have compatible licenses.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 19 December 2016 at 17:28, Svetoslav Neykov <
>>>>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>>>>
>>>>>> Geoff,
>>>>>>>
>>>>>>> I checked the checksums with the release verification script. Is th=
is
>>>>>>>>
>>>>>>> in
>>>>>>
>>>>>>> source control somewhere? I'll offer this to add to it:
>>>>>>>>
>>>>>>> See https://github.com/apache/brooklyn-dist/pull/65 <
>>>>>>> https://github.com/apache/brooklyn-dist/pull/65> and in particular
>>>>>>> https://github.com/neykov/brooklyn-dist/blob/
>>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_broo
>>>>>>> klyn_rc.sh
>>>>>>>
>>>>>> <
>>>
>>>> https://github.com/neykov/brooklyn-dist/blob/
>>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_
>>>>>>>
>>>>>> brooklyn_rc.sh>
>>>
>>>> for an initial implementation of these kind of checks (obviously to be
>>>>>>> expanded where possible).
>>>>>>>
>>>>>>> Svet.
>>>>>>>
>>>>>>>
>>>>>>> On 19.12.2016 =D0=B3., at 18:17, Geoff Macartney <geoff.macartney@
>>>>>>>>
>>>>>>> cloudsoftcorp.com> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> [x] Download links work.
>>>>>>>> [x] Binaries work.
>>>>>>>> [x] Checksums and PGP signatures are valid.
>>>>>>>> [x] Expanded source archive matches contents of RC tag.
>>>>>>>> [x] Expanded source archive builds and passes tests.
>>>>>>>> [x] LICENSE is present and correct.
>>>>>>>> [x] NOTICE is present and correct, including copyright date.
>>>>>>>> [x] All files have license headers where appropriate.
>>>>>>>> [-] All dependencies have compatible licenses.
>>>>>>>> [x] No compiled archives bundled in source archive.
>>>>>>>> [x] I follow this project=E2=80=99s commits list.
>>>>>>>>
>>>>>>>> I deployed the classic tarball and karaf versions to Ubuntu using
>>>>>>>>
>>>>>>> Java
>>>
>>>> 8
>>>>>>
>>>>>>> and 7,
>>>>>>>> and the RPM to Centos 7, and was able to deploy sample application=
s
>>>>>>>>
>>>>>>> to
>>>
>>>> AWS
>>>>>>>
>>>>>>>> and SL.
>>>>>>>>
>>>>>>>> I checked the checksums with the release verification script. Is
>>>>>>>> this
>>>>>>>>
>>>>>>> in
>>>>>>
>>>>>>> source
>>>>>>>> control somewhere? I'll offer this to add to it:
>>>>>>>>
>>>>>>>>     function licenses_and_notices () {
>>>>>>>>         local filename=3D$1
>>>>>>>>         local copyright=3D'Copyright 2014-2016 The Apache Software
>>>>>>>>
>>>>>>> Foundation'
>>>>>>>
>>>>>>>>         for tarball in `ls *.tar.gz`; do
>>>>>>>>         container=3D$( tar tf $tarball | awk NR=3D=3D1 )
>>>>>>>>         tar tf $tarball  | grep -q ${container}LICENSE
>>>>>>>>         tar tf $tarball  | grep -q ${container}NOTICE
>>>>>>>>         tar xOf $tarball ${container}NOTICE | grep -q "${copyright=
}"
>>>>>>>>         done
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     licenses_and_notices
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>
>>>>>>>> I was able to deploy a WebServer + 3-node Riak demo app to Softlay=
er
>>>>>>>> without problem,
>>>>>>>> and didn't see the "hostname is (none)" problem mentioned previous=
ly
>>>>>>>>
>>>>>>> by
>>>
>>>> Svet.
>>>>>>>>
>>>>>>>> I tested https access (with Karaf version) and access to it using
>>>>>>>>
>>>>>>> "br"
>>>
>>>> (from Mac) without
>>>>>>>> observing the crash Svet saw:
>>>>>>>>
>>>>>>>>     ./br login https://10.10.10.102:8443 geoff password
>>>>>>>>     Get https://10.10.10.102:8443/v1/server/version: x509: cannot
>>>>>>>>
>>>>>>> validate
>>>>>>>
>>>>>>>> certificate for 10.10.10.102 because it doesn't contain any IP SAN=
s
>>>>>>>>
>>>>>>>>     ./br  --skipSslChecks login https://10.10.10.102:8443 geoff
>>>>>>>>
>>>>>>> password
>>>>>>
>>>>>>>     Connected to Brooklyn version 0.10.0 at
>>>>>>>> https://10.10.10.102:8443
>>>>>>>>
>>>>>>>>     ./br app
>>>>>>>>     Id   | Name   | Status   | Location
>>>>>>>>
>>>>>>>>
>>>>>>>> Tested the above on Linux and Mac.  I also tried 1000 consecutive
>>>>>>>>
>>>>>>> logins
>>>>>>
>>>>>>> and didn't see the
>>>>>>>> segfault as mentioned in the comment on BROOKLYN-416. I don't know
>>>>>>>>
>>>>>>> why
>>>
>>>> Svet
>>>>>>>
>>>>>>>> is seeing these
>>>>>>>> problems; my own tests would indicate that br is working ok.  Anyo=
ne
>>>>>>>>
>>>>>>> else
>>>>>>
>>>>>>> able to say what
>>>>>>>> they are seeing?
>>>>>>>>
>>>>>>>> Caveat:
>>>>>>>>
>>>>>>>> I did see the behaviour that Svet describes on the main.uri on the
>>>>>>>>
>>>>>>> sample
>>>>>>
>>>>>>> applications.
>>>>>>>> I thought hard about whether this should prevent us releasing. On
>>>>>>>> the
>>>>>>>>
>>>>>>> one
>>>>>>
>>>>>>> hand, there
>>>>>>>> is a possible risk of a poor impression on users trying Brooklyn f=
or
>>>>>>>>
>>>>>>> the
>>>>>>
>>>>>>> first time if
>>>>>>>> its own sample apps appear not to work well. On the other hand it'=
s
>>>>>>>>
>>>>>>> fairly
>>>>>>>
>>>>>>>> clear just from
>>>>>>>> looking at the URL what network it is on, so it shouldn't really b=
e
>>>>>>>>
>>>>>>> too
>>>
>>>> confusing.  In
>>>>>>>> the end what persuaded me was checking back to 0.9.0, and this
>>>>>>>>
>>>>>>> behaviour
>>>>>>
>>>>>>> was already
>>>>>>>> there, so this is not a regression. Not that that matters as such,
>>>>>>>>
>>>>>>> but
>>>
>>>> as
>>>>>>
>>>>>>> far as I recall
>>>>>>>> there was no feedback on the mailing list about this, so it does n=
ot
>>>>>>>>
>>>>>>> seem
>>>>>>
>>>>>>> to have actually
>>>>>>>> caused a problem for anyone in practice. I'm therefore happy enoug=
h
>>>>>>>>
>>>>>>> to
>>>
>>>> say
>>>>>>>
>>>>>>>> +1.
>>>>>>>> At the same time I think it is something that we should tidy up fo=
r
>>>>>>>>
>>>>>>> the
>>>
>>>> future.
>>>>>>>>
>>>>>>>> Geoff
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 19 Dec 2016 at 11:51 Svetoslav Neykov <
>>>>>>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>>>>>>
>>>>>>>> +1 (binding)
>>>>>>>>>
>>>>>>>>> Caveats:
>>>>>>>>>   * hostname on Softlayer-provisioned machines is "(none)"
>>>>>>>>>   * On Softlayer App Wizard examples "Template 2: Python Web
>>>>>>>>> Server",
>>>>>>>>> "Template 3: Bash Web Server and Riak Cluster" list the private I=
P
>>>>>>>>>
>>>>>>>> for
>>>
>>>> "main.uri" (with no "xxx.public/private" alternatives). It's easy to
>>>>>>>>>
>>>>>>>> think
>>>>>>>
>>>>>>>> that it's not working. If public IP is used it's reachable. Some o=
f
>>>>>>>>>
>>>>>>>> the
>>>>>>
>>>>>>> items have the sensor propagated to top, but it's still the private
>>>>>>>>>
>>>>>>>> IP
>>>
>>>>   * "main.uri" is not propagated to root app  (for most examples),
>>>>>>>>>
>>>>>>>> need
>>>
>>>> to
>>>>>>>
>>>>>>>> drill down to first child to get the sensors
>>>>>>>>>   * br - getting fatal error sometimes (
>>>>>>>>> https://issues.apache.org/jira/browse/BROOKLYN-416 <
>>>>>>>>> https://issues.apache.org/jira/browse/BROOKLYN-416>). Not a new
>>>>>>>>>
>>>>>>>> problem
>>>>>>
>>>>>>> it seems.
>>>>>>>>>   * br - can't use --skipSslChecks, still getting "Get
>>>>>>>>> https://localhost:8443/v1/server/version: x509: certificate is
>>>>>>>>>
>>>>>>>> valid
>>>
>>>> for
>>>>>>>
>>>>>>>> web-console, not localhost" from Karaf dist.
>>>>>>>>>   * If I log in into two localhost ports at the same time I get
>>>>>>>>> CSRF
>>>>>>>>>
>>>>>>>> Token
>>>>>>>
>>>>>>>> errors from the page that got loaded first. Using them one by one
>>>>>>>>>
>>>>>>>> works
>>>>>>
>>>>>>> fine.
>>>>>>>>>
>>>>>>>>> Could be easily convinced that item 2 from above doesn't deserve =
a
>>>>>>>>>
>>>>>>>> +1,
>>>
>>>> thoughts?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tested by running the verify script from
>>>>>>>>> https://github.com/neykov/brooklyn-dist/blob/
>>>>>>>>>
>>>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_
>>>>>>>
>>>>>> brooklyn_rc.sh
>>>
>>>> <
>>>>>>>>> https://github.com/neykov/brooklyn-dist/blob/
>>>>>>>>>
>>>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_
>>>>>>>
>>>>>> brooklyn_rc.sh>
>>>
>>>> (https://github.com/apache/brooklyn-dist/pull/65 <
>>>>>>>>> https://github.com/apache/brooklyn-dist/pull/65>).
>>>>>>>>> Expanded the -bin & -karaf, running with local brooklyn.propertie=
s.
>>>>>>>>> Deployed the example apps to AWS & Softlayer (with preconfigured
>>>>>>>>>
>>>>>>>> locations).
>>>>>>>
>>>>>>>> Expanded the OS X br client and tried it against Classic (https) &
>>>>>>>>>
>>>>>>>> Karaf
>>>>>>
>>>>>>> (non-https);
>>>>>>>>>
>>>>>>>>> [=E2=9C=93] Download links work.
>>>>>>>>> [=E2=9C=93] Binaries work.
>>>>>>>>> [=E2=9C=93] Checksums and PGP signatures are valid.
>>>>>>>>> [=E2=9C=93] Expanded source archive matches contents of RC tag.
>>>>>>>>> [=E2=9C=93] Expanded source archive builds and passes tests.
>>>>>>>>> [=E2=9C=93] LICENSE is present and correct.
>>>>>>>>> [=E2=9C=93] NOTICE is present and correct, including copyright da=
te.
>>>>>>>>> [=E2=9C=93] All files have license headers where appropriate.
>>>>>>>>> [=E2=9C=93] All dependencies have compatible licenses.
>>>>>>>>> [=E2=9C=93] No compiled archives bundled in source archive.
>>>>>>>>> [-] I follow this project=E2=80=99s commits list.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Svet.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 18.12.2016 =D0=B3., at 19:14, Aled Sage <aled.sage@gmail.com> =
wrote:
>>>>>>>>>>
>>>>>>>>>> +1 (binding)
>>>>>>>>>>
>>>>>>>>>> I downloaded the tar.gz, and ran it on OS X. I deployed
>>>>>>>>>>
>>>>>>>>> TomcatServer
>>>
>>>> to
>>>>>>
>>>>>>> AWS, Softlayer, Openstack (bluebox-london) and Google Compute
>>>>>>>>>
>>>>>>>> Engine.
>>>
>>>> I ran the verify_brooklyn_rc.sh script (see attachment in rc1
>>>>>>>>>>
>>>>>>>>> vote).
>>>
>>>> I relied on the rat check when running `mvn clean install` for
>>>>>>>>>>
>>>>>>>>> checking
>>>>>>
>>>>>>> that "all files have license headers where appropriate".
>>>>>>>>>
>>>>>>>>>> I checked that each tar.gz in [1] contained a top-level LICENSE
>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>> NOTICE file (including the text "Copyright 2014-2016 The Apache
>>>>>>>>>
>>>>>>>> Software
>>>>>>
>>>>>>> Foundation").
>>>>>>>>>
>>>>>>>>>> [-] Download links work.
>>>>>>>>>> [-] Binaries work.
>>>>>>>>>> [x] Checksums and PGP signatures are valid.
>>>>>>>>>> [-] Expanded source archive matches contents of RC tag.
>>>>>>>>>> [x] Expanded source archive builds and passes tests.
>>>>>>>>>> [x] LICENSE is present and correct.
>>>>>>>>>> [x] NOTICE is present and correct, including copyright date.
>>>>>>>>>> [x] All files have license headers where appropriate.
>>>>>>>>>> [-] All dependencies have compatible licenses.
>>>>>>>>>> [x] No compiled archives bundled in source archive.
>>>>>>>>>> [x] I follow this project=E2=80=99s commits list.
>>>>>>>>>>
>>>>>>>>>> Aled
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>> https://dist.apache.org/repos/dist/dev/brooklyn/apache-
>>>>>>>>>
>>>>>>>> brooklyn-0.10.0-rc3
>>>>>>>
>>>>>>>> On 16/12/2016 12:34, Svetoslav Neykov wrote:
>>>>>>>>>>
>>>>>>>>>>> This is to call for a vote for the release of Apache Brooklyn
>>>>>>>>>>>
>>>>>>>>>> 0.10.0.
>>>>>>
>>>>>>> This release comprises of a source code distribution, and a
>>>>>>>>>>>
>>>>>>>>>> corresponding
>>>>>>>>>
>>>>>>>>>> binary distribution, and Maven artifacts.
>>>>>>>>>>>
>>>>>>>>>>> The source and binary distributions, including signatures,
>>>>>>>>>>>
>>>>>>>>>> digests,
>>>
>>>> etc. can
>>>>>>>>>
>>>>>>>>>> be found at:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/brooklyn/apache-
>>>>>>>>>
>>>>>>>> brooklyn-0.10.0-rc3
>>>>>>>
>>>>>>>> The artifact SHA-256 checksums are as follows:
>>>>>>>>>>>
>>>>>>>>>>>   9ae6ec9f6e2356264fd2032d224965d191e5eab5a5346f8a9de5b0527165
>>>>>>>>>>> 0157
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-1.noarch.rpm
>>>>>>>>>
>>>>>>>>>>   b43c1fc20409594d17151d68b550bb17d8ea5a5592e0b7fbdcf489a81ca2
>>>>>>>>>>> 118e
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-bin.tar.gz
>>>>>>>>>
>>>>>>>>>>   cb7df99f024e918c5517097d904a68d9976c5bf913c9dd64edebb6b5b6e5
>>>>>>>>>>> a89e
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-bin.zip
>>>>>>>>>
>>>>>>>>>>   d65d2525507d40fa0b554b13a57190a724213610a7615082d53137b7bab4
>>>>>>>>>>> b5d5
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.tar.gz
>>>>>>>>>
>>>>>>>>>>   4d13118fca8e02aaf5b4ab3b3f305d139450bcf64d290781609643c4622b
>>>>>>>>>>> 8cb5
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.zip
>>>>>>>>>
>>>>>>>>>>   375eb6a4944a7758dc790a75bd4a0abc782a4ba66af754b4162bbb66a339
>>>>>>>>>>> 02d8
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.tar.gz
>>>>>>>>>
>>>>>>>>>>   9d95e0679e603a9184ada88b63b0c4e8f8503eb51677e04ae59f4aa05f45
>>>>>>>>>>> 4860
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.zip
>>>>>>>>>
>>>>>>>>>>   502e0999d3612f0eb4027d24312da67a67183fc127074ec815b3c72f5de4
>>>>>>>>>>> 1d87
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.tar.gz
>>>>>>>>>
>>>>>>>>>>   1e1ec0210e53faaf9ef1d8907275535a197b341df80e0832067967f4075d
>>>>>>>>>>> b191
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.zip
>>>>>>>>>
>>>>>>>>>>   a32c65628bf897c66ed8bd820a2ce5268bba52815b46f805795e9b51ac83
>>>>>>>>>>> 6912
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-karaf.tar.gz
>>>>>>>>>
>>>>>>>>>>   4b840de7ab986ba64ffba4b98748ca87818718ac3e386bb2d978533e4fa3
>>>>>>>>>>> 5f62
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-karaf.zip
>>>>>>>>>
>>>>>>>>>>   7906b3dba2278c9648f2b340a532d3030536a6a8f1c920311bdcd585a421
>>>>>>>>>>> 11e8
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-src.tar.gz
>>>>>>>>>
>>>>>>>>>>   4579e5e27c2751b5e8b57bab126ae683aa34aa42d6e13eb6c922951df694
>>>>>>>>>>> 7b4c
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-src.zip
>>>>>>>>>
>>>>>>>>>>   b361ada2d4cc1334e72b44986b96e6302aaa24464252c3782f7b679bfa5d
>>>>>>>>>>> a858
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.tar.gz
>>>>>>>>>
>>>>>>>>>>   393df963f6b952ec8c05c1aa0ab0d459037e0972798f17ba7d0221f7e357
>>>>>>>>>>> 0440
>>>>>>>>>>>
>>>>>>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.zip
>>>>>>>>>
>>>>>>>>>> The Nexus staging repository for the Maven artifacts is located
>>>>>>>>>>>
>>>>>>>>>> at:
>>>
>>>>
>>>>>>>>>>> https://repository.apache.org/content/repositories/
>>>>>>>>>
>>>>>>>> orgapachebrooklyn-1034
>>>>>>>
>>>>>>>> All release artifacts are signed with the following key:
>>>>>>>>>>>
>>>>>>>>>>>     https://people.apache.org/keys/committer/svet.asc
>>>>>>>>>>>
>>>>>>>>>>> KEYS file available here:
>>>>>>>>>>>
>>>>>>>>>>>     https://dist.apache.org/repos/dist/release/brooklyn/KEYS
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The artifacts were built from git commit IDs:
>>>>>>>>>>>
>>>>>>>>>>> brooklyn: 1d7ab19ffba2c87e9ad1b037fb217dc7d39506c9
>>>>>>>>>>> brooklyn-client: 0e870fa15714c5a050bb67d6fa0429ff90a8fa4c
>>>>>>>>>>> brooklyn-dist: dda655c45abab34601a5e62250431ea93fdf1755
>>>>>>>>>>> brooklyn-docs: d75752725ef6683a0f52e3059ed475dc69872f9e
>>>>>>>>>>> brooklyn-library: 9fbc78cb4a9d1dccdbdbb70a1ee48f2afddfe067
>>>>>>>>>>> brooklyn-server: 41561635e3bbb0524dbeaae516a26c793174fd93
>>>>>>>>>>> brooklyn-ui: a6e2e8bccfdd98b4f7155b5be86f5b85149e0f33
>>>>>>>>>>> All of the above have been tagged as "apache-brooklyn-0.10.0-rc=
3"
>>>>>>>>>>>
>>>>>>>>>>> Please vote on releasing this package as Apache Brooklyn 0.10.0=
.
>>>>>>>>>>>
>>>>>>>>>>> The vote will be open for at least 72 hours.
>>>>>>>>>>> [ ] +1 Release this package as Apache Brooklyn 0.10.0
>>>>>>>>>>> [ ] +0 no opinion
>>>>>>>>>>> [ ] -1 Do not release this package because ...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Svet.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> CHECKLIST for reference
>>>>>>>>>>>
>>>>>>>>>>> [ ] Download links work.
>>>>>>>>>>> [ ] Binaries 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.
>>>>>>>>>>> [ ] All files have license headers where appropriate.
>>>>>>>>>>> [ ] All dependencies have compatible licenses.
>>>>>>>>>>> [ ] No compiled archives bundled in source archive.
>>>>>>>>>>> [ ] I follow this project=E2=80=99s commits list.
>>>>>>>>>>>
>>>>>>>>>>
>>>
>

--001a113d039ee1c4c10544296d02--