Cancelling RC3 based on the discussion in sibling thread.

Svet.


> On 20.12.2016 г., at 16:48, Aled Sage <[email protected]> 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 <[email protected]>
>> 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 <
>>> [email protected]> 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 <
>>>>> [email protected]> 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 <[email protected]> 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.
>>>>>>> 
>>>>>> 
>>>> 
> 

Reply via email to