brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.10.0 [rc3]
Date Wed, 21 Dec 2016 10:59:07 GMT
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 
comparison 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 
includes 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 started 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/cf6f467cc63afc9bb7bb75d7396becbd4ea2ac273031d31073f546d2@%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 to
>> 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 from
>> git history and plug it in or things have changed considerably, assuming
>> 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/BrooklynUserWithRandomPasswordSecurityProvider.java#L55
>>
>>> On 20.12.2016 г., 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 configure
>> 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 any
>>>> 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@cloudsoftcorp.
>> com>
>>>> wrote:
>>>>
>>>>> +1 (binding)
>>>>>
>>>>> Tested by running Svet's verify script.
>>>>>
>>>>> Do a clean extract of source repo for next steps.
>>>>>
>>>>> -------------------------------------------
>>>>>
>>>>> 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.
>>>>>
>>>>> Additional manual steps done (execute in source distribution folder
>>>>> apache-brooklyn-0.10.0-src:
>>>>>   * Check for files with invalid headers in source distribution. There
>> 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:
>>>>> [✓] All files have license headers where appropriate: I relied 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 this
>>>>> 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_brooklyn_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 г., 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’s 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 applications
>> 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=$1
>>>>>>>         local copyright='Copyright 2014-2016 The Apache Software
>>>>>> Foundation'
>>>>>>>         for tarball in `ls *.tar.gz`; do
>>>>>>>         container=$( tar tf $tarball | awk NR==1 )
>>>>>>>         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 Softlayer
>>>>>>> without problem,
>>>>>>> and didn't see the "hostname is (none)" problem mentioned previously
>> 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
SANs
>>>>>>>
>>>>>>>     ./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.
 Anyone
>>>>> 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
for
>>>>> 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
be
>> 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
not
>>>>> seem
>>>>>>> to have actually
>>>>>>> caused a problem for anyone in practice. I'm therefore happy
enough
>> to
>>>>>> say
>>>>>>> +1.
>>>>>>> At the same time I think it is something that we should tidy
up for
>> 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
IP
>> 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 of
>>>>> 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.properties.
>>>>>>>> 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);
>>>>>>>>
>>>>>>>> [✓] 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’s commits list.
>>>>>>>>
>>>>>>>>
>>>>>>>> Svet.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 18.12.2016 г., 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’s 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:
>>>>>>>>>>
>>>>>>>>>>   9ae6ec9f6e2356264fd2032d224965d191e5eab5a5346f8a9de5b05271650157
>>>>>>>> *apache-brooklyn-0.10.0-rc3-1.noarch.rpm
>>>>>>>>>>   b43c1fc20409594d17151d68b550bb17d8ea5a5592e0b7fbdcf489a81ca2118e
>>>>>>>> *apache-brooklyn-0.10.0-rc3-bin.tar.gz
>>>>>>>>>>   cb7df99f024e918c5517097d904a68d9976c5bf913c9dd64edebb6b5b6e5a89e
>>>>>>>> *apache-brooklyn-0.10.0-rc3-bin.zip
>>>>>>>>>>   d65d2525507d40fa0b554b13a57190a724213610a7615082d53137b7bab4b5d5
>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.tar.gz
>>>>>>>>>>   4d13118fca8e02aaf5b4ab3b3f305d139450bcf64d290781609643c4622b8cb5
>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.zip
>>>>>>>>>>   375eb6a4944a7758dc790a75bd4a0abc782a4ba66af754b4162bbb66a33902d8
>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.tar.gz
>>>>>>>>>>   9d95e0679e603a9184ada88b63b0c4e8f8503eb51677e04ae59f4aa05f454860
>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.zip
>>>>>>>>>>   502e0999d3612f0eb4027d24312da67a67183fc127074ec815b3c72f5de41d87
>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.tar.gz
>>>>>>>>>>   1e1ec0210e53faaf9ef1d8907275535a197b341df80e0832067967f4075db191
>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.zip
>>>>>>>>>>   a32c65628bf897c66ed8bd820a2ce5268bba52815b46f805795e9b51ac836912
>>>>>>>> *apache-brooklyn-0.10.0-rc3-karaf.tar.gz
>>>>>>>>>>   4b840de7ab986ba64ffba4b98748ca87818718ac3e386bb2d978533e4fa35f62
>>>>>>>> *apache-brooklyn-0.10.0-rc3-karaf.zip
>>>>>>>>>>   7906b3dba2278c9648f2b340a532d3030536a6a8f1c920311bdcd585a42111e8
>>>>>>>> *apache-brooklyn-0.10.0-rc3-src.tar.gz
>>>>>>>>>>   4579e5e27c2751b5e8b57bab126ae683aa34aa42d6e13eb6c922951df6947b4c
>>>>>>>> *apache-brooklyn-0.10.0-rc3-src.zip
>>>>>>>>>>   b361ada2d4cc1334e72b44986b96e6302aaa24464252c3782f7b679bfa5da858
>>>>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.tar.gz
>>>>>>>>>>   393df963f6b952ec8c05c1aa0ab0d459037e0972798f17ba7d0221f7e3570440
>>>>>>>> *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-rc3"
>>>>>>>>>>
>>>>>>>>>> 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’s commits list.
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message