Re: new committer: Mykola Mandra

[Richard Downer]

Welcome, Mykola!

Richard


On Tue, 8 Mar 2022, at 8:42 PM, Geoff Macartney wrote:
> The Project Management Committee (PMC) for Apache Brooklyn has
> invited Mykola Mandra to become a committer and we are pleased
> to announce that he has accepted.
> 
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> 
> Please join me in welcoming him to the Apache Brooklyn committers group.
> 
> Geoff
> 

Hashicorp Vault - update

[Richard Downer]

Hello all,

Apache Brooklyn has supported Hashicorp Vault as an "externalized
configuration" provider[1]. Vault. This was implemented in 2015 - at that
time, Vault was at version 0.3.1 or thereabouts - still a fairly early
product.

Fast forward to 2021 and Vault is at 1.6.0 and several of its early
features have been deprecated and replaced with improved features, but
Brooklyn has stood still. In recent PRs[2][3] I've updated the Vault
provider to fix the breaking changes between versions 0.3 and 1.6, and to
ensure that Brooklyn still works with a near-out-of-the-box configuration
of Vault.

So Brooklyn is now back at the "minimum" support for Vault - but it's not
at the "recommended" level.

This is a complicated subject, and I don't claim to fully understand it
all. There's also quite a few different options, which vary depending on
the environment that Brooklyn is running in. Below I summarise the
resources available. I'm not proposing any immediate development effort
right now, but if there is demand for using a better Vault implementation,
the resources here will be a starting point for discussing implementations.

The "Secure Introduction" problem - how you get a secret to an app for it
to use to access Vault when you are trying to avoid storing secrets on the
app - is talked about at [4]. A number of options are proposed there,
depending on the deployment environment. For example, AWS-specific services
can be used, if deployment is onto AWS.

"Approle"[5][6] is Hashicorp's recommendation for apps to access Vault, but
that requires a "trusted entity" to act as an agent to get a secret
delivered to Brooklyn. Vault's tutorials describe Chef as a possible entity
- it obtains a secret for each new client it sets up, and deploys it into
the app it is deploying.

Response wrapping[7] provides a way to deliver a secret to the app. Rather
than deliver the secret directly, it's placed in a Vault "cubbyhole" and
what is delivered is a single-use, short-TTL token. The short TTL means
that an attacker has a very short time window to retrieve the secret. The
single-use nature means that if an attacker is able to successfully get the
secret, the app will know that if it can't retrieve the secret that it has
been compromised.


I suspect that the large variation of options and deployment environment
makes a "one size fits all" approach quite difficult to implement. But
interested in other people's thoughts.

Richard.


[1]
https://brooklyn.apache.org/v/latest/ops/externalized-configuration.html#vault
[2] https://github.com/apache/brooklyn-server/pull/1136
[3] https://github.com/apache/brooklyn-docs/pull/313
[4]
https://learn.hashicorp.com/tutorials/vault/secure-introduction?in=vault/app-integration
[5] https://www.vaultproject.io/docs/auth/approle
[6] https://learn.hashicorp.com/tutorials/vault/approle
[7] https://www.vaultproject.io/docs/concepts/response-wrapping.html

Re: Changes to the Apache CI build system - volunteer needed

[Richard Downer]

Hmm! Oh well, I won't argue with Infra :-)

Thanks again for doing this Thomas. Let's let it run for a week or two,
then we can delete the jobs off the old Jenkins instance.

Richard.


On Tue, 21 Jul 2020 at 15:47, Thomas Bouron 
wrote:

> Hi Richard.
>
> When I implemented the jobs on the old build machine, I asked the exact
> same question and INFRA told me to use a personal token as it should be
> bound to a committer on Brooklyn rather than INFRA.
>
> Could ask again but I don't think it has changed.
>
> Best.
>
> On Tue, 21 Jul 2020 at 15:37, Richard Downer  wrote:
>
> > Hi Thomas,
> >
> > That was quick! Thanks for taking care of this.
> >
> > Seems that we should remove the dependency on your own personal access
> > token though. There must be another way to do this. Would you discuss on
> > the bui...@apache.org mailing list if there's an alternative method
> which
> > doesn't need any of your own credentials?
> >
> > Richard.
> >
> >
> > On Tue, 21 Jul 2020 at 11:21, Thomas Bouron 
> > wrote:
> >
> > > Hi all.
> > >
> > > I just recreated the job on the new build machine:
> > > https://ci-builds.apache.org/job/Brooklyn/
> > > Like the ones on the old build machine, these jobs are using one of my
> > own
> > > personal token to access GitHub.
> > >
> > > They are currently running and *should* just work as all the build
> > > environments have been pushed to docker.
> > >
> > > If you spot any error, please let me know.
> > >
> > > Best.
> > >
> > > On Mon, 20 Jul 2020 at 21:02, Thomas Bouron <
> thomas.bou...@cloudsoft.io>
> > > wrote:
> > >
> > > > Hey Richard.
> > > >
> > > > I was the one creating the latest Jenkins jobs on the old build
> > machine,
> > > > so it shouldn't take me a too long to recreate them, especially since
> > > it's
> > > > now using docker to build stuff.
> > > >
> > > > I'll look at it tomorrow or maximum this week, then report back here
> > once
> > > > done or if I encounter any issues.
> > > >
> > > > Best.
> > > >
> > > > On Mon, 20 Jul 2020, 15:40 Richard Downer, 
> wrote:
> > > >
> > > >> Hello all,
> > > >>
> > > >> Apache Infra have announced that they are retiring their existing
> > > Jenkins
> > > >> infrastructure in favour of a new one managed by CloudBees. Details
> > > below,
> > > >> but TL;DR every project is responsible for manually setting up their
> > > >> project's jobs on the new Jenkins instance (as an automated
> migration
> > is
> > > >> not possible.)
> > > >>
> > > >> Do any of our committers have availability to do this before the
> > > deadline
> > > >> of 15th August?
> > > >>
> > > >> I've requested that a Brooklyn folder is added. Once this is
> available
> > > >> (within a day I expect) all Brooklyn committers should be able to
> > create
> > > >> and manage jobs in that folder.
> > > >>
> > > >> Richard.
> > > >>
> > > >> -- Forwarded message -
> > > >> From: Gavin McDonald 
> > > >> Date: Thu, 16 Jul 2020 at 17:33
> > > >> Subject: [IMPORTANT] - Migration to ci-builds.a.o
> > > >> To: builds 
> > > >>
> > > >>
> > > >> Hi All,
> > > >>
> > > >> This NOTICE is for everyone on builds.apache.org. We are migrating
> > to a
> > > >> new
> > > >> Cloudbees based Client Master called https://ci-builds.apache.org.
> > The
> > > >> migrations of all jobs needs to be done before the switch off date
> of
> > > 15th
> > > >> August 2020, so you have a maximum of 4 weeks.
> > > >>
> > > >> There is no tool or automated way of migrating your jobs, the
> > > >> differences in the platforms, the plugins and the setup makes it
> > > >> impossible
> > > >> to do in a safe way. So, you all need to start creating new jobs on
> > > >> ci-infra.a.o and then , when you are happy, turn off your old builds
> > on
> > > >> builds.a.o.
> > > >>
> > > >> There are

Re: Changes to the Apache CI build system - volunteer needed

[Richard Downer]

Hi Thomas,

That was quick! Thanks for taking care of this.

Seems that we should remove the dependency on your own personal access
token though. There must be another way to do this. Would you discuss on
the bui...@apache.org mailing list if there's an alternative method which
doesn't need any of your own credentials?

Richard.


On Tue, 21 Jul 2020 at 11:21, Thomas Bouron 
wrote:

> Hi all.
>
> I just recreated the job on the new build machine:
> https://ci-builds.apache.org/job/Brooklyn/
> Like the ones on the old build machine, these jobs are using one of my own
> personal token to access GitHub.
>
> They are currently running and *should* just work as all the build
> environments have been pushed to docker.
>
> If you spot any error, please let me know.
>
> Best.
>
> On Mon, 20 Jul 2020 at 21:02, Thomas Bouron 
> wrote:
>
> > Hey Richard.
> >
> > I was the one creating the latest Jenkins jobs on the old build machine,
> > so it shouldn't take me a too long to recreate them, especially since
> it's
> > now using docker to build stuff.
> >
> > I'll look at it tomorrow or maximum this week, then report back here once
> > done or if I encounter any issues.
> >
> > Best.
> >
> > On Mon, 20 Jul 2020, 15:40 Richard Downer,  wrote:
> >
> >> Hello all,
> >>
> >> Apache Infra have announced that they are retiring their existing
> Jenkins
> >> infrastructure in favour of a new one managed by CloudBees. Details
> below,
> >> but TL;DR every project is responsible for manually setting up their
> >> project's jobs on the new Jenkins instance (as an automated migration is
> >> not possible.)
> >>
> >> Do any of our committers have availability to do this before the
> deadline
> >> of 15th August?
> >>
> >> I've requested that a Brooklyn folder is added. Once this is available
> >> (within a day I expect) all Brooklyn committers should be able to create
> >> and manage jobs in that folder.
> >>
> >> Richard.
> >>
> >> -- Forwarded message -
> >> From: Gavin McDonald 
> >> Date: Thu, 16 Jul 2020 at 17:33
> >> Subject: [IMPORTANT] - Migration to ci-builds.a.o
> >> To: builds 
> >>
> >>
> >> Hi All,
> >>
> >> This NOTICE is for everyone on builds.apache.org. We are migrating to a
> >> new
> >> Cloudbees based Client Master called https://ci-builds.apache.org. The
> >> migrations of all jobs needs to be done before the switch off date of
> 15th
> >> August 2020, so you have a maximum of 4 weeks.
> >>
> >> There is no tool or automated way of migrating your jobs, the
> >> differences in the platforms, the plugins and the setup makes it
> >> impossible
> >> to do in a safe way. So, you all need to start creating new jobs on
> >> ci-infra.a.o and then , when you are happy, turn off your old builds on
> >> builds.a.o.
> >>
> >> There are currently 4 agents over there ready to take jobs, plus a
> >> floating
> >> agent which is shared amongst many masters (more to come). I will
> migrate
> >> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> >> will keep an eye of load across both and adjust accordingly.
> >>
> >> If needed, create a ticket on INFRA jira for any issues that crop up, or
> >> email here on builds@a.o. there may be one or two plugins we need to
> >> install/tweak etc.
> >>
> >> We will be not using 'Views' at the top level, but rather we will take
> >> advantage of 'Folders Plus' - each project will get its own Folder and
> >> have
> >> authorisation access to create/edit jobs etc within that folder. I will
> >> create these folders as you ask for them to start with. This setup
> allows
> >> for credentials isolation amongst other benefits, including but not
> >> limited
> >> to exclusive agents (Controlled Agents) for your own use , should you
> have
> >> any project targeted donations of agents.
> >>
> >> As with other aspects of the ASF, projects can choose to just enable all
> >> committers access to their folder, just ask.
> >>
> >> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will
> not
> >> be setting up any forwarding rules or anything like that.
> >>
> >> So, please, get started *now *on this so you can be sure we are all
> >> completed before the final cutoff date of 15th August 2020.
> >>
> >> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> >> tickets.
> >>
> >> Hadoop and related projects have their own migration path to follow,
> same
> >> cut off date, Cassandra, Beam, CouchDB have already migrated and are
> doing
> >> very well in their new homes.
> >>
> >> Lets get going ...
> >>
> >> --
> >>
> >> *Gavin McDonald*
> >> Systems Administrator
> >> ASF Infrastructure Team
> >>
> >
>
> --
> Thomas Bouron
> Lead Software Engineer
>
> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud
>
> GitHub: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Changes to the Apache CI build system - volunteer needed

[Richard Downer]

Hello all,

Apache Infra have announced that they are retiring their existing Jenkins
infrastructure in favour of a new one managed by CloudBees. Details below,
but TL;DR every project is responsible for manually setting up their
project's jobs on the new Jenkins instance (as an automated migration is
not possible.)

Do any of our committers have availability to do this before the deadline
of 15th August?

I've requested that a Brooklyn folder is added. Once this is available
(within a day I expect) all Brooklyn committers should be able to create
and manage jobs in that folder.

Richard.

-- Forwarded message -
From: Gavin McDonald 
Date: Thu, 16 Jul 2020 at 17:33
Subject: [IMPORTANT] - Migration to ci-builds.a.o
To: builds 


Hi All,

This NOTICE is for everyone on builds.apache.org. We are migrating to a new
Cloudbees based Client Master called https://ci-builds.apache.org. The
migrations of all jobs needs to be done before the switch off date of 15th
August 2020, so you have a maximum of 4 weeks.

There is no tool or automated way of migrating your jobs, the
differences in the platforms, the plugins and the setup makes it impossible
to do in a safe way. So, you all need to start creating new jobs on
ci-infra.a.o and then , when you are happy, turn off your old builds on
builds.a.o.

There are currently 4 agents over there ready to take jobs, plus a floating
agent which is shared amongst many masters (more to come). I will migrate
away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
will keep an eye of load across both and adjust accordingly.

If needed, create a ticket on INFRA jira for any issues that crop up, or
email here on builds@a.o. there may be one or two plugins we need to
install/tweak etc.

We will be not using 'Views' at the top level, but rather we will take
advantage of 'Folders Plus' - each project will get its own Folder and have
authorisation access to create/edit jobs etc within that folder. I will
create these folders as you ask for them to start with. This setup allows
for credentials isolation amongst other benefits, including but not limited
to exclusive agents (Controlled Agents) for your own use , should you have
any project targeted donations of agents.

As with other aspects of the ASF, projects can choose to just enable all
committers access to their folder, just ask.

We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
be setting up any forwarding rules or anything like that.

So, please, get started *now *on this so you can be sure we are all
completed before the final cutoff date of 15th August 2020.

Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
tickets.

Hadoop and related projects have their own migration path to follow, same
cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
very well in their new homes.

Lets get going ...

-- 

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team

[jira] [Reopened] (BROOKLYN-616) REST API swagger validation fails on isolated environment

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer reopened BROOKLYN-616:
-

> REST API swagger validation fails on isolated environment 
> --
>
> Key: BROOKLYN-616
> URL: https://issues.apache.org/jira/browse/BROOKLYN-616
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0-M1
>Reporter: Ludovic Farine
>Priority: Minor
> Fix For: 1.0.0
>
>
> REST API Docs page shows an error message if the swagger.json file is 
> inaccessible from the internet.
>  It has been detected on customer on-prem environment.
> ```json
> {"schemaValidationMessages":[\\{"level":"error","message":"Can't read from 
> file http://:8081/v1/apidoc/swagger.json"}
> ]}
>  ```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (BROOKLYN-616) REST API swagger validation fails on isolated environment

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer closed BROOKLYN-616.
---
Resolution: Fixed

> REST API swagger validation fails on isolated environment 
> --
>
> Key: BROOKLYN-616
> URL: https://issues.apache.org/jira/browse/BROOKLYN-616
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0-M1
>Reporter: Ludovic Farine
>Priority: Minor
> Fix For: 1.0.0
>
>
> REST API Docs page shows an error message if the swagger.json file is 
> inaccessible from the internet.
>  It has been detected on customer on-prem environment.
> ```json
> {"schemaValidationMessages":[\\{"level":"error","message":"Can't read from 
> file http://:8081/v1/apidoc/swagger.json"}
> ]}
>  ```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (BROOKLYN-616) REST API swagger validation fails on isolated environment

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-616:

Comment: was deleted

(was: Briefly re-opened and closed issue to make an edit to the description.)

> REST API swagger validation fails on isolated environment 
> --
>
> Key: BROOKLYN-616
> URL: https://issues.apache.org/jira/browse/BROOKLYN-616
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0-M1
>Reporter: Ludovic Farine
>Priority: Minor
> Fix For: 1.0.0
>
>
> REST API Docs page shows an error message if the swagger.json file is 
> inaccessible from the internet.
>  It has been detected on customer on-prem environment.
> ```json
> {"schemaValidationMessages":[\\{"level":"error","message":"Can't read from 
> file http://:8081/v1/apidoc/swagger.json"}
> ]}
>  ```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (BROOKLYN-616) REST API swagger validation fails on isolated environment

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer closed BROOKLYN-616.
---
Resolution: Fixed

Briefly re-opened and closed issue to make an edit to the description.

> REST API swagger validation fails on isolated environment 
> --
>
> Key: BROOKLYN-616
> URL: https://issues.apache.org/jira/browse/BROOKLYN-616
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0-M1
>Reporter: Ludovic Farine
>Priority: Minor
> Fix For: 1.0.0
>
>
> REST API Docs page shows an error message if the swagger.json file is 
> inaccessible from the internet.
>  It has been detected on customer on-prem environment.
> ```json
> {"schemaValidationMessages":[\\{"level":"error","message":"Can't read from 
> file http://:8081/v1/apidoc/swagger.json"}
> ]}
>  ```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (BROOKLYN-616) REST API swagger validation fails on isolated environment

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-616:

Description: 
REST API Docs page shows an error message if the swagger.json file is 
inaccessible from the internet.
 It has been detected on customer on-prem environment.

```json

{"schemaValidationMessages":[\\{"level":"error","message":"Can't read from file 
http://:8081/v1/apidoc/swagger.json"}

]}
 ```

  was:
REST API Docs page shows an error message if the swagger.json file is 
inaccessible from the internet.
It has been detected on JPMC environment.

```json
{"schemaValidationMessages":[\{"level":"error","message":"Can't read from file 
http://:8081/v1/apidoc/swagger.json"}]}
```


> REST API swagger validation fails on isolated environment 
> --
>
> Key: BROOKLYN-616
> URL: https://issues.apache.org/jira/browse/BROOKLYN-616
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0-M1
>Reporter: Ludovic Farine
>Priority: Minor
> Fix For: 1.0.0
>
>
> REST API Docs page shows an error message if the swagger.json file is 
> inaccessible from the internet.
>  It has been detected on customer on-prem environment.
> ```json
> {"schemaValidationMessages":[\\{"level":"error","message":"Can't read from 
> file http://:8081/v1/apidoc/swagger.json"}
> ]}
>  ```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (BROOKLYN-616) REST API swagger validation fails on isolated environment

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer reopened BROOKLYN-616:
-

> REST API swagger validation fails on isolated environment 
> --
>
> Key: BROOKLYN-616
> URL: https://issues.apache.org/jira/browse/BROOKLYN-616
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0-M1
>Reporter: Ludovic Farine
>Priority: Minor
> Fix For: 1.0.0
>
>
> REST API Docs page shows an error message if the swagger.json file is 
> inaccessible from the internet.
> It has been detected on JPMC environment.
> ```json
> {"schemaValidationMessages":[\{"level":"error","message":"Can't read from 
> file http://:8081/v1/apidoc/swagger.json"}]}
> ```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[ANNOUNCE] Apache Brooklyn 1.0.0 released

[Richard Downer]

On behalf of the Brooklyn Project Management Committee (PMC) and all of our
contributors, I'm pleased to announce the release of Apache Brooklyn 1.0.0.

It can be downloaded from https://brooklyn.apache.org/download/. We provide
source code, binaries and a selection OS packages. Brooklyn's artifacts are
also available through Maven Central.

The Apache Software Foundation has put out a press release about our 1.0.0
release - please read it and share!
https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces59

Brooklyn has been an Apache project since 2014, and we spent the first few
years figuring out the cloud landscape, the ideal expression for
applications, the best API and UI. We've now stabilised these and many
other decisions, and we have been confident for some time that Brooklyn is
"production quality" and we, the PMC and the community, can support it for
the long term. Therefore, it was time to stamp it "1.0.0".

I'd like to thank everyone involved in bringing Brooklyn to 1.0.0 - there
are many people, no longe actively involved, who contributed code back in
the early days that is still here and actively used in Brooklyn today - and
on the flip side, we have new contributors who have just started making
their first contributions to Brooklyn in the last few months. All of you
are very important to this project. Thank you all!

Please download Brooklyn, enjoy, and spread the word.

[RESULT][VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Richard Downer]

The votes cast were as follows:

+1

Duncan Grant (binding)
Aled Sage (binding)
Geoff Macartney (binding)
Richard Downer (binding)
Iuliana Cosmina
Juan Cabrerizo
John Campbell

No -1 votes

With no negative votes, and sufficient positive binding votes, the vote
PASSES and rc3 will be released as Apache Brooklyn 1.0.0.

A huge thanks to everyone who has contributed to get us this far!

Please note that the release is not made until the artifacts are moved to
the official release location, the website updated, and an official
[ANNOUNCE] is published to this list. Until then please keep distribution
of the rc3 artifacts to a minimum.

Richard.


-- Forwarded message -
From: Richard Downer 
Date: Tue, 18 Feb 2020 at 23:37
Subject: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]
To: Brooklyn dev 


This is to call for a vote for the release of Apache Brooklyn 1.0.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-1.0.0-rc3

The artifact SHA-256 checksums are as follows:

  f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
*apache-brooklyn-1.0.0-rc3-1.noarch.rpm
  7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
*apache-brooklyn-1.0.0-rc3-bin.tar.gz
  9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
*apache-brooklyn-1.0.0-rc3-bin.zip
  e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
*apache-brooklyn-1.0.0-rc3-classic.tar.gz
  e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
*apache-brooklyn-1.0.0-rc3-classic.zip
  3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
*apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
  eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
*apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
  13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
*apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
  f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
*apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
  8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
*apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
  ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
*apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
  9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
*apache-brooklyn-1.0.0-rc3-src.tar.gz
  a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
*apache-brooklyn-1.0.0-rc3-src.zip
  164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
*apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
  ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
*apache-brooklyn-1.0.0-rc3-vagrant.zip
  9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26
*apache-brooklyn-1.0.0-rc3.deb

The Nexus staging repository for the Maven artifacts is located at:


https://repository.apache.org/content/repositories/orgapachebrooklyn-1055

All release artifacts are signed with the following key:

https://people.apache.org/keys/committer/richard.asc

KEYS file available here:

https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: d3ef75f26240bee38d288d507364616380e4d853
brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
brooklyn-dist: d55424d0c5994d9bceb804bcf0ecc7c80560370e
brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
All of the above have been tagged as "apache-brooklyn-1.0.0-rc3"

Please vote on releasing this package as Apache Brooklyn 1.0.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 1.0.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Richard Downer]

+1 (binding)

Tests performed:

Build from source
Run from .tar.gz on Ubuntu Linux 18.04
Connect br client from Windows 10 Professional
Deploy a quickstart blueprint
Try some more complex blueprints


On Tue, 18 Feb 2020 at 23:37, Richard Downer  wrote:

> This is to call for a vote for the release of Apache Brooklyn 1.0.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-1.0.0-rc3
>
> The artifact SHA-256 checksums are as follows:
>
>   f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
>   7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> *apache-brooklyn-1.0.0-rc3-bin.tar.gz
>   9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> *apache-brooklyn-1.0.0-rc3-bin.zip
>   e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> *apache-brooklyn-1.0.0-rc3-classic.tar.gz
>   e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> *apache-brooklyn-1.0.0-rc3-classic.zip
>   3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
>   eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
>   13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
> *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
>   f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
> *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
>   8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
> *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
>   ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
> *apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
>   9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
> *apache-brooklyn-1.0.0-rc3-src.tar.gz
>   a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
> *apache-brooklyn-1.0.0-rc3-src.zip
>   164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
> *apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
>   ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
> *apache-brooklyn-1.0.0-rc3-vagrant.zip
>   9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26
> *apache-brooklyn-1.0.0-rc3.deb
>
> The Nexus staging repository for the Maven artifacts is located at:
>
>
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1055
>
> All release artifacts are signed with the following key:
>
> https://people.apache.org/keys/committer/richard.asc
>
> KEYS file available here:
>
> https://dist.apache.org/repos/dist/release/brooklyn/KEYS
>
>
> The artifacts were built from git commit IDs:
>
> brooklyn: d3ef75f26240bee38d288d507364616380e4d853
> brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
> brooklyn-dist: d55424d0c5994d9bceb804bcf0ecc7c80560370e
> brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
> brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
> brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
> brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
> All of the above have been tagged as "apache-brooklyn-1.0.0-rc3"
>
> Please vote on releasing this package as Apache Brooklyn 1.0.0.
>
> The vote will be open for at least 72 hours.
> [ ] +1 Release this package as Apache Brooklyn 1.0.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Thanks!
>

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Richard Downer]

Paul,

Forgive me if I'm missing anything as I avoid Docker where I generally can.

Bringing up a shell on that Docker image, I can see JDK 8 is already
installed:

root@6ec502dbd5bb:/# which java
/usr/local/openjdk-8/bin/java
root@6ec502dbd5bb:/# java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
root@6ec502dbd5bb:/# javac -version
javac 1.8.0_242

Is the workaround to simply remove attempt to install JDK 8 from the
Dockerfile?

I'd also consider the Dockerfile to be a non-core part of Brooklyn and
therefore this should not be a release blocker. Does anyone agree/disagree?

Richard.


On Wed, 19 Feb 2020 at 10:09, Paul Campbell 
wrote:

> Hi,
>
> When I try to create the brooklyn docker image for building (i.e. docker
> build -t brooklyn .) I get the following error:
>
> pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker
> build -t brooklyn .
> Sending build context to Docker daemon  38.09MB
> Step 1/8 : FROM maven:3.6.3-jdk-8
> 3.6.3-jdk-8: Pulling from library/maven
> dc65f448a2e2: Pull complete
> 346ffb2b67d7: Pull complete
> dea4ecac934f: Pull complete
> 8ac92ddf84b3: Pull complete
> d8ef64070a18: Pull complete
> 6577248b0d6e: Pull complete
> 576c0a3a6af9: Pull complete
> b96f1ed3d8ce: Pull complete
> a42ee290f6d0: Pull complete
> b85c95a261d3: Pull complete
> Digest:
> sha256:c822fa30ca61b434f87f415be39357cbee36f3ef88f2d65445437ab055d1266b
> Status: Downloaded newer image for maven:3.6.3-jdk-8
>  ---> a4ae0fe55e86
> Step 2/8 : RUN apt-get update && apt-get install -y openjdk-8-jre
>  ---> Running in a27050aa0206
> Get:1 http://deb.debian.org/debian buster InRelease [122 kB]
> Get:2 http://security.debian.org/debian-security buster/updates
> InRelease [65.4 kB]
> Get:3 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
> Get:4 http://security.debian.org/debian-security buster/updates/main
> amd64 Packages [177 kB]
> Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
> Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages
> [5792 B]
> Fetched 8326 kB in 3s (2504 kB/s)
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> E: Unable to locate package openjdk-8-jre
> The command '/bin/sh -c apt-get update && apt-get install -y
> openjdk-8-jre' returned a non-zero code: 100
>
> This is because of a problem with the base maven image:
>
> pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker run
> -it maven:3.6.3-jdk-8 /bin/bash
> root@ee5eb6fdf173:/# apt-get update
> Get:1 http://security.debian.org/debian-security buster/updates
> InRelease [65.4 kB]
> Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
> Get:3 http://security.debian.org/debian-security buster/updates/main
> amd64 Packages [177 kB]
> Get:4 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
> Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
> Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages
> [5792 B]
> Fetched 8326 kB in 6s (1480 kB/s)
> Reading package lists... Done
> root@ee5eb6fdf173:/# apt-cache search openjdk|grep jre
> openjdk-11-jre - OpenJDK Java runtime, using Hotspot JIT
> openjdk-11-jre-headless - OpenJDK Java runtime, using Hotspot JIT
> (headless)
> openjdk-11-jre-zero - Alternative JVM for OpenJDK, using Zero
> openjdk-11-jre-dcevm - Alternative VM for OpenJDK 11 with enhanced
> class redefinition
>
> Despite being tagged as 'jdk-8' it doesn't have a JDK8 package available.
>
> Paul
>
>
> On Tue, 18 Feb 2020 at 23:37, Richard Downer  wrote:
>
> > This is to call for a vote for the release of Apache Brooklyn 1.0.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-1.0.0-rc3
> >
> > The artifact SHA-256 checksums are as follows:
> >
> >   f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> >   7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> > *apache-brooklyn-1.0.0-rc3-bin.tar.gz
> >   9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> > *apache-brooklyn-1.0.0-rc3-bin.zip
> >   e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f326

[VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Richard Downer]

This is to call for a vote for the release of Apache Brooklyn 1.0.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-1.0.0-rc3

The artifact SHA-256 checksums are as follows:

  f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
*apache-brooklyn-1.0.0-rc3-1.noarch.rpm
  7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
*apache-brooklyn-1.0.0-rc3-bin.tar.gz
  9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
*apache-brooklyn-1.0.0-rc3-bin.zip
  e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
*apache-brooklyn-1.0.0-rc3-classic.tar.gz
  e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
*apache-brooklyn-1.0.0-rc3-classic.zip
  3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
*apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
  eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
*apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
  13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
*apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
  f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
*apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
  8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
*apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
  ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
*apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
  9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
*apache-brooklyn-1.0.0-rc3-src.tar.gz
  a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
*apache-brooklyn-1.0.0-rc3-src.zip
  164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
*apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
  ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
*apache-brooklyn-1.0.0-rc3-vagrant.zip
  9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26
*apache-brooklyn-1.0.0-rc3.deb

The Nexus staging repository for the Maven artifacts is located at:


https://repository.apache.org/content/repositories/orgapachebrooklyn-1055

All release artifacts are signed with the following key:

https://people.apache.org/keys/committer/richard.asc

KEYS file available here:

https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: d3ef75f26240bee38d288d507364616380e4d853
brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
brooklyn-dist: d55424d0c5994d9bceb804bcf0ecc7c80560370e
brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
All of the above have been tagged as "apache-brooklyn-1.0.0-rc3"

Please vote on releasing this package as Apache Brooklyn 1.0.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 1.0.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!

Version 1.0.0 press and media

[Richard Downer]

Hello all!

Apache Brooklyn 1.0.0 is nearing release (the next RC is building as I
write this), and with 1.0.0 being a nice round number it's a good
opportunity to get some free press out of our release :-)

I've approached the ASF's media team and our VP of Marketing and Publicity,
Sally Khudairi, is happy to help us write a press release and will issue it
through the ASF's media channels. The recommendation is to issue it on a
Tuesday - if I get this RC out tonight, I'd be closing the vote on next
Monday morning and we'd get the release published in time for a press
release Tuesday next week!

Sally suggests we look at https://s.apache.org/HK21 and
https://s.apache.org/aznB for examples of The ASF's house style for project
press releases. We'll need to pull together an introductory section and key
points about our project/release. Then it's followed by quotes from the PMC
Chair (are you up for this Geoff, or happy for someone to ghost-write for
you?) and possibly others in the PMC, and quotes from community members -
typically from tech companies that are using the project. My employer,
Cloudsoft, is a big user of Apache Brooklyn and will likely supply a
quotation, but quotes from other people and companies will be very valuable.

I'll put together a draft for the first part of the press release and share
it for comments, but I'd like to appeal to our community - do you use
Apache Brooklyn and would you like to contribute a quote for our press
release? If so please let me know as soon as possible!

Thanks
Richard

[jira] [Updated] (BROOKLYN-625) Blueprint Composer cannot select a location

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-625:

Attachment: (was: image-2020-02-12-22-14-27-176.png)

> Blueprint Composer cannot select a location
> ---
>
> Key: BROOKLYN-625
> URL: https://issues.apache.org/jira/browse/BROOKLYN-625
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 Professional 64-bit
> Firefox 72.0.2 (64-bit)
> Apache Brooklyn 1.0.0-rc2
>Reporter: Richard Downer
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: Annotation 2020-02-12 221501.png
>
>
>  
>  
>  # Ensure at least one location is configured in the Location Manager.
>  # Open the Blueprint Composer.
>  # Click on the "New Application" entity on the canvas.
>  # In the sidebar, expand the Location section and click "Attach a location".
>  
> Expected behaviour: a list of locations to choose from.
> Actual behaviour: an empty list and message "Nothing available"
> Workaround: the location name can be typed in manually, then the "ad hoc" 
> tile clicked and attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (BROOKLYN-625) Blueprint Composer cannot select a location

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-625:

Attachment: Annotation 2020-02-12 221501.png

> Blueprint Composer cannot select a location
> ---
>
> Key: BROOKLYN-625
> URL: https://issues.apache.org/jira/browse/BROOKLYN-625
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 Professional 64-bit
> Firefox 72.0.2 (64-bit)
> Apache Brooklyn 1.0.0-rc2
>Reporter: Richard Downer
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: Annotation 2020-02-12 221501.png, 
> image-2020-02-12-22-14-27-176.png
>
>
>  
>  
>  # Ensure at least one location is configured in the Location Manager.
>  # Open the Blueprint Composer.
>  # Click on the "New Application" entity on the canvas.
>  # In the sidebar, expand the Location section and click "Attach a location".
>  
> Expected behaviour: a list of locations to choose from.
> Actual behaviour: an empty list and message "Nothing available"
> Workaround: the location name can be typed in manually, then the "ad hoc" 
> tile clicked and attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BROOKLYN-625) Blueprint Composer cannot select a location

[Richard Downer (Jira)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035756#comment-17035756
 ] 

Richard Downer commented on BROOKLYN-625:
-

I'm still seeing this issue - both with Chrome and Firefox, and with native 
Windows and WSL2 Ubuntu Linux.

Attached a screenshot. Am I doing something wrong?

!Annotation 2020-02-12 221501.png!

> Blueprint Composer cannot select a location
> ---
>
> Key: BROOKLYN-625
> URL: https://issues.apache.org/jira/browse/BROOKLYN-625
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 Professional 64-bit
> Firefox 72.0.2 (64-bit)
> Apache Brooklyn 1.0.0-rc2
>Reporter: Richard Downer
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: Annotation 2020-02-12 221501.png, 
> image-2020-02-12-22-14-27-176.png
>
>
>  
>  
>  # Ensure at least one location is configured in the Location Manager.
>  # Open the Blueprint Composer.
>  # Click on the "New Application" entity on the canvas.
>  # In the sidebar, expand the Location section and click "Attach a location".
>  
> Expected behaviour: a list of locations to choose from.
> Actual behaviour: an empty list and message "Nothing available"
> Workaround: the location name can be typed in manually, then the "ad hoc" 
> tile clicked and attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (BROOKLYN-625) Blueprint Composer cannot select a location

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-625:

Attachment: image-2020-02-12-22-14-27-176.png

> Blueprint Composer cannot select a location
> ---
>
> Key: BROOKLYN-625
> URL: https://issues.apache.org/jira/browse/BROOKLYN-625
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 Professional 64-bit
> Firefox 72.0.2 (64-bit)
> Apache Brooklyn 1.0.0-rc2
>Reporter: Richard Downer
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: image-2020-02-12-22-14-27-176.png
>
>
>  
>  
>  # Ensure at least one location is configured in the Location Manager.
>  # Open the Blueprint Composer.
>  # Click on the "New Application" entity on the canvas.
>  # In the sidebar, expand the Location section and click "Attach a location".
>  
> Expected behaviour: a list of locations to choose from.
> Actual behaviour: an empty list and message "Nothing available"
> Workaround: the location name can be typed in manually, then the "ad hoc" 
> tile clicked and attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[RESULT][VOTE] Release Apache Brooklyn 1.0.0 [rc2]

[Richard Downer]

Voting is now closed.

The votes are:

+1 votes from:
Geoff Macartney (binding)
Thomas Bouron (binding)

-1 votes from:
Richard Downer (binding)
Iuliana Cosmina
Paul Campbell


As there is a binding -1 vote this means that the vote is NOT passed.

Thanks to all those who took the time to test this release (including some
new contributors - thank you to Iuliana and Paul, and some other people who
helped behind the scenes).

There's now some bugs to investigate and fix, and then we'll try again with
rc3 hopefully fairly quickly!

Thanks
Richard.


-- Forwarded message -----
From: Richard Downer 
Date: Mon, 3 Feb 2020 at 20:11
Subject: [VOTE] Release Apache Brooklyn 1.0.0 [rc2]
To: Brooklyn dev 


I'm very happy to announce the first public release candidate for Apache
Brooklyn 1.0.0. This is rc2 (as rc1 had an error which meant it could not
be published fully). I'd like to thank all our contributors who have worked
hard to bring us to this release.

**This is to call for a vote for the release of Apache Brooklyn 1.0.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-1.0.0-rc2

The artifact SHA-256 checksums are as follows:

  6ccb7afe2108a02c4fab6907f9866e5baa07f7957f639d4717bde4bc5f5832ef
*apache-brooklyn-1.0.0-rc2-1.noarch.rpm
  ffc28d11d1cd30a76dcfca8741460d5c5a4950f4f11cb1d6d023235087f3a32b
*apache-brooklyn-1.0.0-rc2-bin.tar.gz
  c2f3ee83aa26a65157de9e61c45c2b7600940b95cfcbd5bf452d1e25ab1b97e2
*apache-brooklyn-1.0.0-rc2-bin.zip
  0f6abd1f8f31510c14be3eb3a68d83103b9a8d46d5035f09a16908b37c90fef0
*apache-brooklyn-1.0.0-rc2-classic.tar.gz
  0d0ddae0b1fc72762ec177c90d8059a8054ee42a7b49b80052edc6eff4de1624
*apache-brooklyn-1.0.0-rc2-classic.zip
  c227a55a7780869b35b0ab9b7b82e2540b97edbad4b1544e478b36b8f14fb72a
*apache-brooklyn-1.0.0-rc2-client-cli-linux.tar.gz
  e0afadf6f649ca17d6b77e901505efab5cc84a00d9e8167fcc390dd08ce89475
*apache-brooklyn-1.0.0-rc2-client-cli-linux.zip
  b237903d2b5b6dad7475fe523f9d56047d863dc326975f12ff04e4fc1be80f26
*apache-brooklyn-1.0.0-rc2-client-cli-macosx.tar.gz
  bd259175b7a42427cfa91a00e31615eee65de728c614f81269d1a8917f277831
*apache-brooklyn-1.0.0-rc2-client-cli-macosx.zip
  697eac5a550319bfc9669c01bfca67a4613303e4152aa9c7e0fb5ddd39d15263
*apache-brooklyn-1.0.0-rc2-client-cli-windows.tar.gz
  f600a4a845ba01f4cc1064737e9f0614562fe0422e2626030d5d8884294ab6f9
*apache-brooklyn-1.0.0-rc2-client-cli-windows.zip
  042569ee07c98c1233112aa8f0a8ec2b1970a3f33a83f9b30a9f8047b7673596
*apache-brooklyn-1.0.0-rc2-src.tar.gz
  7c2234837af519dbb15d300625d91d2ff355266ad4ba51a9e6dc3a7e280f8959
*apache-brooklyn-1.0.0-rc2-src.zip
  df13ad311bef3568ca446dcad576b0260c3c751dea22d90542ec7aaac17e0f83
*apache-brooklyn-1.0.0-rc2-vagrant.tar.gz
  773eadf39f84e3e7bb42fddbf05965504fc56da7ec75e059a9535c79b721d0db
*apache-brooklyn-1.0.0-rc2-vagrant.zip
  58989b85c41e29a44bd5b265f489890f0e0c8eead51688b1420eabe75cc849cc
*apache-brooklyn-1.0.0-rc2.deb

The Nexus staging repository for the Maven artifacts is located at:


https://repository.apache.org/content/repositories/orgapachebrooklyn-1054

All release artifacts are signed with the following key:

https://people.apache.org/keys/committer/richard.asc

KEYS file available here:

https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: 4331f9cb44d8da637b5673b4a6170dd62a0974b2
brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
brooklyn-dist: 680da6d1f94195fe01c0dd9ea915164ebe868e5d
brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
All of the above have been tagged as "apache-brooklyn-1.0.0-rc2"

Please vote on releasing this package as Apache Brooklyn 1.0.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 1.0.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!
Richard Downer and Martin Harris (co-Release Managers)

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc2]

[Richard Downer]

My vote is:
-1 (binding)
I discovered a defect in the blueprint composer - it's not able to browse
locations[1].
Furthermore, some defects reported by other people I believe are serious
enough to vote -1 for:
Defect in the Vagrant build and some of the quickstart blueprints, reported
Iuliana Cosmina[2] - since the Vagrant build is the first set of
instructions in "Getting Started" it's important to get this right.
A further defect in a quickstart blueprint, reported by Paul Campbell[3]

[1]https://issues.apache.org/jira/browse/BROOKLYN-625
[2]
https://lists.apache.org/thread.html/rc43d0d687cda81cc43990965f5f4f990b42f9b1bbf44296931f1ec35%40%3Cdev.brooklyn.apache.org%3E
[3]
https://lists.apache.org/thread.html/r1be945635b5afff601a1fcd187b4ea428f317c86d2f2adc7011b8b10%40%3Cdev.brooklyn.apache.org%3E


On Wed, 5 Feb 2020 at 09:16, Thomas Bouron 
wrote:

> Solid +1
>
> I tested the artifacts with the `verify_brooklyn_rc.sh` script and here is
> the output:
> --
> 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.
>
> I also unpack and ran locally the tarball:
> [✓] Sanity check all UI modules work as expected.
> [✓] Catalog is populated.
> [✓] Created an app in blueprint composer and deployed it to AWS.
> [✓] Imported catalog items through the BR cli.
> [✓] Deployed application through the BR cli on AWS, Azure and GCE.
> [✓] invoke couple of effectors through the App Inspector.
> [✓] Restarted Brooklyn and checked that the persisted state didn't cause
> any issue (after app have been deployed)
>
> Note that I didn't test the RPM and DEB packages.
>
> Best.
>
> On Tue, 4 Feb 2020 at 21:39, Geoff Macartney 
> wrote:
>
> > +1
> >
> > I haven't been able to take the time to do extensive validation on the
> RC,
> > but I have been able to validate checksums, install and run it, deploy a
> > basic application, create an app with the UI. Happy to defer to others if
> > more comprehensive tests reveal problems.
> >
> > Excited to see this!
> >
> > Geoff
> >
> > On Mon, 3 Feb 2020 at 20:11, Richard Downer  wrote:
> >
> > > I'm very happy to announce the first public release candidate for
> Apache
> > > Brooklyn 1.0.0. This is rc2 (as rc1 had an error which meant it could
> not
> > > be published fully). I'd like to thank all our contributors who have
> > worked
> > > hard to bring us to this release.
> > >
> > > **This is to call for a vote for the release of Apache Brooklyn
> 1.0.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-1.0.0-rc2
> > >
> > > The artifact SHA-256 checksums are as follows:
> > >
> > >   6ccb7afe2108a02c4fab6907f9866e5baa07f7957f639d4717bde4bc5f5832ef
> > > *apache-brooklyn-1.0.0-rc2-1.noarch.rpm
> > >   ffc28d11d1cd30a76dcfca8741460d5c5a4950f4f11cb1d6d023235087f3a32b
> > > *apache-brooklyn-1.0.0-rc2-bin.tar.gz
> > >   c2f3ee83aa26a65157de9e61c45c2b7600940b95cfcbd5bf452d1e25ab1b97e2
> > > *apache-brooklyn-1.0.0-rc2-bin.zip
> > >   0f6abd1f8f31510c14be3eb3a68d83103b9a8d46d5035f09a16908b37c90fef0
> > > *apache-brooklyn-1.0.0-rc2-classic.tar.gz
> > >   0d0ddae0b1fc72762ec177c90d8059a8054ee42a7b49b80052edc6eff4de1624
> > > *apache-brooklyn-1.0.0-rc2-classic.zip
> > >   c227a55a7780869b35b0ab9b7b82e2540b97edbad4b1544e478b36b8f14fb72a
> > > *apache-brooklyn-1.0.0-rc2-client-cli-linux.tar.gz
> > >   e0afadf6f649ca17d6b77e901505efab5cc84a00d9e8167fcc390dd08ce89475
> > > *apache-brooklyn-1.0.0-rc2-client-cli-linux.zip
> > >   b237903d2b5b6dad7475fe523f9d56047d863dc326975f12ff04e4fc1be80f26
> > > *apache-brooklyn-1.0.0-rc2-client-cli-macosx.tar.gz
> > >   bd259175b7a42427cfa91a00e31615eee65de728c614f81269d1a8917f277831
> > > *apache-brooklyn-1.0.0-rc2-client-cli-macosx.zip
> > >   697eac5a550319bfc9669c01bfca67a4613303e4152aa9c7e0fb5ddd39d15263
> > > *apache-brooklyn-1.0.0-rc2-client-cli-windows.tar.gz
> &g

[jira] [Created] (BROOKLYN-625) Blueprint Composer cannot select a location

[Richard Downer (Jira)]

Richard Downer created BROOKLYN-625:
---

 Summary: Blueprint Composer cannot select a location
 Key: BROOKLYN-625
 URL: https://issues.apache.org/jira/browse/BROOKLYN-625
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 1.0.0
 Environment: Windows 10 Professional 64-bit

Firefox 72.0.2 (64-bit)

Apache Brooklyn 1.0.0-rc2
Reporter: Richard Downer
 Fix For: 1.0.0


 

 
 # Ensure at least one location is configured in the Location Manager.
 # Open the Blueprint Composer.
 # Click on the "New Application" entity on the canvas.
 # In the sidebar, expand the Location section and click "Attach a location".

 

Expected behaviour: a list of locations to choose from.

Actual behaviour: an empty list and message "Nothing available"

Workaround: the location name can be typed in manually, then the "ad hoc" tile 
clicked and attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[VOTE] Release Apache Brooklyn 1.0.0 [rc2]

[Richard Downer]

I'm very happy to announce the first public release candidate for Apache
Brooklyn 1.0.0. This is rc2 (as rc1 had an error which meant it could not
be published fully). I'd like to thank all our contributors who have worked
hard to bring us to this release.

**This is to call for a vote for the release of Apache Brooklyn 1.0.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-1.0.0-rc2

The artifact SHA-256 checksums are as follows:

  6ccb7afe2108a02c4fab6907f9866e5baa07f7957f639d4717bde4bc5f5832ef
*apache-brooklyn-1.0.0-rc2-1.noarch.rpm
  ffc28d11d1cd30a76dcfca8741460d5c5a4950f4f11cb1d6d023235087f3a32b
*apache-brooklyn-1.0.0-rc2-bin.tar.gz
  c2f3ee83aa26a65157de9e61c45c2b7600940b95cfcbd5bf452d1e25ab1b97e2
*apache-brooklyn-1.0.0-rc2-bin.zip
  0f6abd1f8f31510c14be3eb3a68d83103b9a8d46d5035f09a16908b37c90fef0
*apache-brooklyn-1.0.0-rc2-classic.tar.gz
  0d0ddae0b1fc72762ec177c90d8059a8054ee42a7b49b80052edc6eff4de1624
*apache-brooklyn-1.0.0-rc2-classic.zip
  c227a55a7780869b35b0ab9b7b82e2540b97edbad4b1544e478b36b8f14fb72a
*apache-brooklyn-1.0.0-rc2-client-cli-linux.tar.gz
  e0afadf6f649ca17d6b77e901505efab5cc84a00d9e8167fcc390dd08ce89475
*apache-brooklyn-1.0.0-rc2-client-cli-linux.zip
  b237903d2b5b6dad7475fe523f9d56047d863dc326975f12ff04e4fc1be80f26
*apache-brooklyn-1.0.0-rc2-client-cli-macosx.tar.gz
  bd259175b7a42427cfa91a00e31615eee65de728c614f81269d1a8917f277831
*apache-brooklyn-1.0.0-rc2-client-cli-macosx.zip
  697eac5a550319bfc9669c01bfca67a4613303e4152aa9c7e0fb5ddd39d15263
*apache-brooklyn-1.0.0-rc2-client-cli-windows.tar.gz
  f600a4a845ba01f4cc1064737e9f0614562fe0422e2626030d5d8884294ab6f9
*apache-brooklyn-1.0.0-rc2-client-cli-windows.zip
  042569ee07c98c1233112aa8f0a8ec2b1970a3f33a83f9b30a9f8047b7673596
*apache-brooklyn-1.0.0-rc2-src.tar.gz
  7c2234837af519dbb15d300625d91d2ff355266ad4ba51a9e6dc3a7e280f8959
*apache-brooklyn-1.0.0-rc2-src.zip
  df13ad311bef3568ca446dcad576b0260c3c751dea22d90542ec7aaac17e0f83
*apache-brooklyn-1.0.0-rc2-vagrant.tar.gz
  773eadf39f84e3e7bb42fddbf05965504fc56da7ec75e059a9535c79b721d0db
*apache-brooklyn-1.0.0-rc2-vagrant.zip
  58989b85c41e29a44bd5b265f489890f0e0c8eead51688b1420eabe75cc849cc
*apache-brooklyn-1.0.0-rc2.deb

The Nexus staging repository for the Maven artifacts is located at:


https://repository.apache.org/content/repositories/orgapachebrooklyn-1054

All release artifacts are signed with the following key:

https://people.apache.org/keys/committer/richard.asc

KEYS file available here:

https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: 4331f9cb44d8da637b5673b4a6170dd62a0974b2
brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
brooklyn-dist: 680da6d1f94195fe01c0dd9ea915164ebe868e5d
brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
All of the above have been tagged as "apache-brooklyn-1.0.0-rc2"

Please vote on releasing this package as Apache Brooklyn 1.0.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 1.0.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!
Richard Downer and Martin Harris (co-Release Managers)

Re: Brooklyn 1.0.0 release candidate?

[Richard Downer]

+1. Look forward to it :-) Thanks to all who have been getting us up to
1.0-grade!

On Fri, 17 Jan 2020 at 16:00, Aled Sage  wrote:

> Hi all,
>
> I believe we are (finally!) ready to produce Apache Brooklyn 1.0.0 RC1.
>
> Assuming folk agree, then we can kick off the RC1 release process and
> build it over the weekend or Monday.
>
> Please give an information +1 or -1 (we'll do a proper vote on the
> actual RCs).
>
> ---
>
> We proposed a "code freeze" for 13th Dec [1] and by lazy consensus we've
> focused on bug fixes / test fixes since then.
>
> Aled
>
> [1] See Martin Harris' email: "Open pull requests".
>
>

Re: [PROPOSAL] Revamp of website/docs

[Richard Downer]

Hi Thomas,

Agree with a lot of what you say - we've made some decisions that in
hindsight were bad ones that are now causing pain (even though they were
the correct decisions at the time - back when Brooklyn first started,
before Apache, Jekyll was just about the only static site generator with a
lot of traction).

I've a couple of points to make:

In your description about why website is on a separate branch, you've
omitted that website and docs have big differences in their lifecycles.
There's always only one branch of the website, but there's multiple
versions of the documentation. Mixing website and docs has the problem of
making multiple versions of the website. Only one branch will contain the
"real" website and all others will necessarily be out-of-date copies. For
that reason I'd prefer that the website and the docs are kept in distinct
branches.

I don't have any particular view on which static site generator is best
other than to say I'm wary of fast-moving targets. Jekyll and Ruby bit us
like that - you have to keep your content and infrastructure up-to-date -
stand still for too long and suddenly it's a pain building your tooling and
a hefty job to upgrade. I'm very wary of the Node.js, Yarn, NPM ecosystem
for that reason and I wouldn't want us to be in a similar position to now a
year or two down the line. I'd be happier with a generator written in Go as
it usually has simpler distributions and setup (native static-linked
binaries) that have a longer shelf-life.

Richard.


On Tue, 7 Jan 2020 at 09:58, Thomas Bouron 
wrote:

> Hello Brooklyners, and welcome into this new decade! (i.e. Happy New Year!)
>
> To start off nicely, I would like to make a proposal regarding the Brooklyn
> website/doc.
>
> *Background*
> Currently, we have 2 separate projects in `brooklyn-docs`:
> - the docs are using `gitbooks` and sources live in the `master` branch.
> - the rest of the website is using an ancient version `Jekyll` and sources
> live in the `website` branch.
>
> We did this because:
> 1. the ancient version of Jekyll requires a very specific version of ruby
> which is a pain to setup locally and on the CI. Meaning it was virtually
> impossible to contribute the docs alone.
> 2. if there is a change in the docs, it didn't make sense to update the
> website part and vice-versa.
> 3. we wanted to automatically publish the changes live as soon as PRs were
> merged.
>
> *Issue*
> The problem with this approach is that we need to have 2 CI jobs to build 2
> different parts and to somehow push these live. We never managed to
> automatically publish updates to website/docs through Jenkins.
> We also picked a tool that is unfortunately not maintained anymore
> (gitbooks) as their team is pushing for a commercial offering. Our Jekyll
> setup is very old and impossible to upgrade currently, as it's using custom
> plugins that would need to be rewritten.
> And finally, our setup is, in my view, way too complicated and clunky to
> use.
>
> *Proposal*
> I took a look at different solutions and found one that seemed to tick all
> the boxes, it's called vuepress [1] and let us to:
> - reconciled the website and docs under the same branch as it supports
> multiple layouts, hence build both in one go.
> - have a custom navigation, based on whatever configuration we write.
> - defined custom blocks that can use hardcoded HTML or vue templates (we do
> have custom blocks for the blueprint tours, tips, alerts, etc...)
> - have custom search like gitbooks + be responsive and SEO friendly.
> - have a toolchain that is maintained, open source and easy to use.
>
> On top of that, having the full website build in one go will enable us to
> push, from Jenkins, the compiled files to another branch (like `asf-pages`)
> and leverage a new service called `.asf.yaml` [2] which takes care of
> publishing it.
>
> WDYT?
>
> Best.
>
> [1] https://vuepress.vuejs.org/
> 
> [2]
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405038#id-.asf.yamlfeaturesforgitrepositories-WebSiteDeploymentServiceforGitRepositories
>
>
> --
> Thomas Bouron
> Senior Software Engineer
>
> *Cloudsoft  *| Bringing Business to the Cloud
>
> GitHub: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Re: PR for BROOKLYN-597

[Richard Downer]

Geoff,

Possibly unrelated, but I've had an experience getting Brooklyn to build
recently (haven't tried for many months!)

There's a Dockerfile which spins up a container with all the required
dependencies for a *build* - I'm not sure if it has everything required for
a *release* build though.

However I prefer to avoid Docker and just build on my workstation - I have
a working build without tests but not with tests so consider this a work in
progress, but I believe these are the OS packages required to do a build.
Do you have all of these installed?

golang
maven
procps
libpng-devel (CentOS/RHEL) / libpng-dev (Ubuntu/Debian)
make
automake
autoconf
libtool
pkgconfig
nasm
gcc
rpm-build (CentOS/RHEL) / rpm (Ubuntu/Debian)
dpkg (CentOS/RHEL)

HTH

Richard.


On Sun, 8 Dec 2019 at 22:15, Geoff Macartney 
wrote:

> Hi all,
>
> Per our chat about prepping for 1.0.0 I have created
> https://github.com/apache/brooklyn-dist/pull/150
>
> to remove MD5 and SHA-1 from the signing process.
>
> I've marked it Do Not Merge because I can't get the
> make-release-artifacts.sh to work to test this. It keeps failing on
> brooklyn-ui/ui-modules/utils with
>
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test)
> on project brooklyn-software-base: There are test failures.
> [ERROR]
> [ERROR] Please refer to
>
> /private/var/folders/10/7wxypczs3ng9dny8kpnwc9nrgn/T/release-working-dir/source/apache-brooklyn-1.0.0-SNAPSHOT-src/brooklyn-server/software/base/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
>
>
> Running "mvn test" in the folder works ok. I will need to take some time to
> dig into this, but might as well stick this up for review for now.
>
> Does anyone with more experience of the script have any ideas on what might
> be up here?
>
> I tried to get the Vagrant setup going too but there's some incompatibility
> in my conf  between the gpg version in vagrant (1.4.20) and my version
> (2.2.15), so again more digging required. Also, anyone know if gpg will
> work inside Vagrant when I use a Yubikey?
>
> Geoff
>

[jira] [Commented] (BROOKLYN-597) Remove MD5 and SHA-1 checksums

[Richard Downer (Jira)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986148#comment-16986148
 ] 

Richard Downer commented on BROOKLYN-597:
-

[~geomacy] can run with this one, following his interest on the mailing list. 
Geoff, give me a shout if you need anything from me!

> Remove MD5 and SHA-1 checksums 
> ---
>
> Key: BROOKLYN-597
> URL: https://issues.apache.org/jira/browse/BROOKLYN-597
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 0.12.0
>Reporter: Geoff Macartney
>Assignee: Geoff Macartney
>Priority: Major
>
> Per the recently updated Apache Release Distribution Policy, 
> [https://www.apache.org/dev/release-distribution], we should remove the 
> generation and checking of MD5 and SHA-1 checksums from brooklyn-dist/release 
> before we do another release, presumably 1.0.
> The relevant wording is 
> {quote}For every artifact distributed to the public through Apache channels, 
> the PMC
>  * MUST supply a 
> [valid|https://www.apache.org/dev/release-signing#verifying-signature] 
> [OpenPGP-compatible ASCII-armored detached 
> signature|https://www.apache.org/dev/release-signing#openpgp-ascii-detach-sig]
>  file
>  * MUST supply at least one checksum file
>  * SHOULD supply a [SHA-256 and/or 
> SHA-512|https://www.apache.org/dev/release-signing#sha-checksum] checksum file
>  * SHOULD NOT supply a MD5 or SHA-1 checksum file (because these are 
> deprecated)
> For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT 
> supply MD5 or SHA-1. Existing releases do not need to be changed.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Brooklyn 1.0 is shaping up

[Richard Downer]

Hi Geoff,

Please feel free to take this one - I've assigned the Jira issue to you.
Shout if you need anything from me!

Cheers
Richard.


On Sun, 1 Dec 2019 at 14:47, Geoff Macartney 
wrote:

> We should definitely include
> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove MD5 and SHA-1
> checksums" as part of 1.0.0.  I'd be happy to do this but I see it's got
> you assigned to it Richard. Do you have work in progress on this, or would
> you like me to look into it? I have a notion that I might polish up the
> signing procedure a bit.
>
> Cheers
> Geoff
>
> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney 
> wrote:
>
> > Hi Ludo,
> >
> > I am indeed pleased to see this!  I had been thinking of mailing the
> > community again on the matter after Christmas was out of the way, let's
> let
> > 2020 be the year of Brooklyn 1.0.0!
> >
> > That's a great list of things to address. One thing to add would be
> > removing some deprecated code. Do you think they are all small changes,
> or
> > do any require extensive work or have a wide impact?
> >
> > The reason I ask is that I think it would be good to restrict ourselves
> to
> > relatively easy and limited impact changes between now and 1.0.0. My fear
> > is that larger changes will take a longer time and push back a release
> even
> > further. It seems to me things are quite stable now; I'd say let's polish
> > it up and release it rather than try to make significant improvements.
> >
> > What does everyone think?
> >
> > Cheers
> > Geoff
> >
> >
> >
> >
> > On Thu, 28 Nov 2019 at 11:04, Ludovic Farine  wrote:
> >
> >> Hi everyone,
> >>
> >> Hope you are all doing well!
> >>
> >> Christmas is fast approaching and well hopefully a gift we would all
> like
> >> to have: Brooklyn 1.0.0 release :) Geoff would be pleased to hear!
> >>
> >> Working towards this goal of first official release, these are a few bug
> >> fixes and improvements that I believe are worth considering
> >> (non-exhaustive
> >> and not ordered wishlist!) :
> >>
> >> Bug fixes:
> >>
> >>-
> >>
> >>Broken icon links for ELK and DNS entities
> >>-
> >>
> >>REST API Swagger error
> >>-
> >>
> >>Two different versions of jetty-server
> >>-
> >>
> >>Karaf version bump
> >>
> >>
> >> Improvements:
> >>
> >>-
> >>
> >>Session Management: introduce expiry settings for inactivity or
> >> repeated
> >>background API calls
> >>-
> >>
> >>User Experience: blueprints ordered by date deployed, cookies to
> >>remember preferred sort criteria and palette preferences
> >>
> >>
> >> Clean-up:
> >>
> >>-
> >>
> >>Review existing open Pull Requests
> >>-
> >>
> >>Fix most of the Jenkins tests
> >>
> >>
> >> What are your thoughts on this scope? Any other suggestions you would
> like
> >> to deliver in this next release?
> >>
> >> Looking forward to get the community engaging in the next weeks and
> >> months.
> >>
> >> Remember you can participate with others on the official Slack channel
> >> *#brooklyn* on the official Apache group. Sign up here
> >> https://s.apache.org/slack-invite to join the discussion!
> >>
> >> Thanks
> >>
> >> Ludo
> >>
> >>
> >> --
> >>
> >> Ludovic Farine
> >>
> >> Senior Technical Project Manager
> >>
> >>
> >> Cloudsoft  | Bringing Business to the Cloud
> >>
> >> E: l...@cloudsoft.io
> >>
> >> T: +44 7584 748013
> >>
> >> L: https://www.linkedin.com/in/ludovicfarine/
> >>
> >
>

[jira] [Assigned] (BROOKLYN-597) Remove MD5 and SHA-1 checksums

[Richard Downer (Jira)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer reassigned BROOKLYN-597:
---

Assignee: Geoff Macartney  (was: Richard Downer)

> Remove MD5 and SHA-1 checksums 
> ---
>
> Key: BROOKLYN-597
> URL: https://issues.apache.org/jira/browse/BROOKLYN-597
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 0.12.0
>Reporter: Geoff Macartney
>Assignee: Geoff Macartney
>Priority: Major
>
> Per the recently updated Apache Release Distribution Policy, 
> [https://www.apache.org/dev/release-distribution], we should remove the 
> generation and checking of MD5 and SHA-1 checksums from brooklyn-dist/release 
> before we do another release, presumably 1.0.
> The relevant wording is 
> {quote}For every artifact distributed to the public through Apache channels, 
> the PMC
>  * MUST supply a 
> [valid|https://www.apache.org/dev/release-signing#verifying-signature] 
> [OpenPGP-compatible ASCII-armored detached 
> signature|https://www.apache.org/dev/release-signing#openpgp-ascii-detach-sig]
>  file
>  * MUST supply at least one checksum file
>  * SHOULD supply a [SHA-256 and/or 
> SHA-512|https://www.apache.org/dev/release-signing#sha-checksum] checksum file
>  * SHOULD NOT supply a MD5 or SHA-1 checksum file (because these are 
> deprecated)
> For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT 
> supply MD5 or SHA-1. Existing releases do not need to be changed.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org

[Richard Downer]

Hi dev@brooklyn,

Looks like we missed our historical Git repositories when we did the
migration to gitbox. I'll create a JIRA ticket for these last two
repositories. I expect nobody to be impacted as these repositories are
obsolete and only kept for historical purposes.

Richard.


On Thu, 3 Jan 2019 at 13:18, Apache Infrastructure Team <
infrastruct...@apache.org> wrote:

> Hello, brooklyn folks.
> As stated earlier in 2018, all git repositories must be migrated from
> the git-wip-us.apache.org URL to gitbox.apache.org, as the old service
> is being decommissioned. Your project is receiving this email because
> you still have repositories on git-wip-us that needs to be migrated.
>
> The following repositories on git-wip-us belong to your project:
>  - incubator-brooklyn.git
>  - incubator-brooklyn-site.git
>
>
> We are now entering the mandated (coordinated) move stage of the roadmap,
> and you are asked to please coordinate migration with the Apache
> Infrastructure Team before February 7th. All repositories not migrated
> on February 7th will be mass migrated without warning, and we'd appreciate
> it if we could work together to avoid a big mess that day :-).
>
> Moving to gitbox means you will get full write access on GitHub as well,
> and be able to close/merge pull requests and much more.
>
> To have your repositories moved, please follow these steps:
>
> - Ensure consensus on the move (a link to a lists.apache.org thread will
>   suffice for us as evidence).
> - Create a JIRA ticket at https://issues.apache.org/jira/browse/INFRA
>
> Your migration should only take a few minutes. If you wish to migrate
> at a specific time of day or date, please do let us know in the ticket.
>
> As always, we appreciate your understanding and patience as we move
> things around and work to provide better services and features for
> the Apache Family.
>
> Should you wish to contact us with feedback or questions, please do so
> at: us...@infra.apache.org.
>
>
> With regards,
> Apache Infrastructure
>
>

Re: Build depends on Docker

[Richard Downer]

; > > > people
> > > > > > to get started with Brooklyn (instead of vagrant).
> > > > > >
> > > > > > Best.
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > https://github.com/apache/brooklyn-dist/pull/118#issuecomment-435649038
> > > > > > [2]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/spotify/docker-maven-plugin#bind-docker-commands-to-maven-phases
> > > > > >
> > > > > > On Sat, 15 Dec 2018 at 08:55 Alex Heneveld <
> > > > > > alex.henev...@cloudsoftcorp.com>
> > > > > > wrote:
> > > > > >
> > > > > > > It should have a mvn profile like rpm and the go cli IMO. The
> > > README
> > > > in
> > > > > > the
> > > > > > > master project describes these.
> > > > > > >
> > > > > > > Best
> > > > > > > Alex
> > > > > > >
> > > > > > > On Fri, 14 Dec 2018, 22:51 Geoff Macartney <
> > > > geoff.macart...@gmail.com
> > > > > > > wrote:
> > > > > > >
> > > > > > > > We added this in
> > > https://github.com/apache/brooklyn-dist/pull/118,
> > > > > > but I
> > > > > > > > do
> > > > > > > > dislike having to have Docker to build Brooklyn.  IMHO anyone
> > > > should
> > > > > be
> > > > > > > > able to build and use Brooklyn without knowing anything about
> > > > Docker.
> > > > > > > Could
> > > > > > > > we remove the image build from the mvn install and have a
> > > separate
> > > > > > shell
> > > > > > > > script that you would run manually to build the image? And
> yes
> > it
> > > > > > should
> > > > > > > > use the karaf distro, didn't realise it doesn't.
> > > > > > > >
> > > > > > > > Geoff
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 12 Dec 2018 at 16:58 Richard Downer <
> > rich...@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > All,
> > > > > > > > >
> > > > > > > > > The Apache Brooklyn build depends on having a working
> Docker
> > > > > > instance.
> > > > > > > > This
> > > > > > > > > I did not know.
> > > > > > > > >
> > > > > > > > > The build failure happens in the `brooklyn-dist` project,
> > which
> > > > > > > > > incorporates into execution `dockerfile-maven-plugin` which
> > > > invokes
> > > > > > > > Docker
> > > > > > > > > during the build phase. If Docker is not running, it tries
> to
> > > > > connect
> > > > > > > to
> > > > > > > > a
> > > > > > > > > non-existent UNIX socket and the build fails.
> > > > > > > > >
> > > > > > > > > This presents a few discussion points...
> > > > > > > > >
> > > > > > > > > What exactly is it building? There's a Dockerfile there and
> > it
> > > > > seems
> > > > > > > that
> > > > > > > > > it builds an image which contains the Brooklyn distribution
> > and
> > > > > > starts
> > > > > > > > > Brooklyn. I don't know much about Docker, what happens to
> > that
> > > > > image?
> > > > > > > Is
> > > > > > > > it
> > > > > > > > > local to my computer?
> > > > > > > > >
> > > > > > > > > Is it necessary to have the build depend on Docker? To me
> > this
> > > > > seems
> > > > > > > > > unreasonable. Docker has a large footprint and I don't
> think
> > > it's
> > > > > > > > > reasonable to require it for a normal, local build of
> > Brooklyn.
> > > > > > > > >
> > > > > > > > > We're not releasing Docker images. Should we be? Should we
> > not
> > > > be?
> > > > > Is
> > > > > > > it
> > > > > > > > > even possible for us to do that in Apache?
> > > > > > > > >
> > > > > > > > > Why haven't I seen this before? The changes to add this to
> > > > > > > brooklyn-dist
> > > > > > > > > were made in 2017. I've performed release builds on clean
> EC2
> > > > > > instances
> > > > > > > > and
> > > > > > > > > never seen this. Was this dormant, and has something
> changed
> > > > which
> > > > > > has
> > > > > > > > > kicked this into life?
> > > > > > > > >
> > > > > > > > > brooklyn-dist is obsolete now. If the Docker build is still
> > > > > something
> > > > > > > > > important, then firstly it needs moved to another project
> > > > > (hopefully
> > > > > > > one
> > > > > > > > > exclusive to that task) and secondly it needs to use the
> > Karaf
> > > > > > > > > distribution.
> > > > > > > > >
> > > > > > > > > Can anyone shed some light on this?
> > > > > > > > >
> > > > > > > > > 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.
> > > > > >
> > > > >
> > > >
> > >
> > --
> > 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.
> >
>

[ACTION REQUIRED] Committers, link your ASF account to GitHub

[Richard Downer]

If you are a current committer to Apache Brooklyn, and you would like to
use all the new features that Gitbox gives us, you will need to link your
GitHub and ASF accounts.

You can do this at https://gitbox.apache.org

Have fun with the big green "Merge Pull Request" button!!

Richard.


-- Forwarded message -
From: Thomas Bouron 
Date: Fri, 14 Dec 2018 at 10:58
Subject: Re: [NOTICE] Mandatory relocation of Apache git repositories on
git-wip-us.apache.org
To: 


Erratum: we now have a team for the people who did the Gitbox <-> GitHub
link, which gives committers the ability to merge PR directly from the
GitHub UI 🎉


On Fri, 14 Dec 2018 at 10:18 Thomas Bouron 
wrote:

> Migration successful[1]. It means that committers can push to either
> Gitbox or GitHub (still cannot merge directly through the UI though)
>
> [1]
>
https://issues.apache.org/jira/browse/INFRA-17440?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
>
> On Fri, 14 Dec 2018 at 08:44 Thomas Bouron 
> wrote:
>
>> Hi all.
>>
>> I think we have reached a consensus here as there is no +0 or -1.
>> I went ahead and created an INFRA ticket[1] to request the move.
>>
>> Best.
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-17440
>>
>> On Thu, 13 Dec 2018 at 13:53 John Campbell <
>> john.campb...@cloudsoftcorp.com> wrote:
>>
>>> No strong feelings, so +1 from me
>>>
>>> John Campbell
>>> Software Engineer
>>>
>>> Cloudsoft | Bringing Business to the Cloud
>>>
>>> E: john.campb...@cloudsoftcorp.com
>>> M: 07779 576614
>>> T: -
>>> L: www.linkedin.com/in/john-campbell-42105267
>>>
>>> Need a hand with AWS? Get a Free Consultation.
>>>
>>> > On 13 Dec 2018, at 09:31, Duncan Grant 
>>> wrote:
>>> >
>>> > +1
>>> >
>>> > On Wed, 12 Dec 2018 at 16:42 Richard Downer 
>>> wrote:
>>> >
>>> >> Brooklyn team,
>>> >>
>>> >> Apart from myself, I don't think anyone has clearly come out in
>>> favour or
>>> >> opposed to this. I'd rather we got consensus and moved to gitbox
>>> early - so
>>> >> that if some people do object, we have time to work out the
>>> objections with
>>> >> infra, before we are involuntarily moved.
>>> >>
>>> >> Thoughts, anyone? Does this need a formal vote to get people
>>> responding?
>>> >>
>>> >> Richard.
>>> >>
>>> >>
>>> >> On Fri, 7 Dec 2018 at 16:54, Daniel Gruno 
>>> wrote:
>>> >>
>>> >>> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
>>> >>>  DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
>>> >>>
>>> >>> Hello Apache projects,
>>> >>>
>>> >>> I am writing to you because you may have git repositories on the
>>> >>> git-wip-us server, which is slated to be decommissioned in the
coming
>>> >>> months. All repositories will be moved to the new gitbox service
>>> which
>>> >>> includes direct write access on github as well as the standard ASF
>>> >>> commit access via gitbox.apache.org.
>>> >>>
>>> >>> ## Why this move? ##
>>> >>> The move comes as a result of retiring the git-wip service, as the
>>> >>> hardware it runs on is longing for retirement. In lieu of this, we
>>> >>> have decided to consolidate the two services (git-wip and gitbox),
to
>>> >>> ease the management of our repository systems and future-proof the
>>> >>> underlying hardware. The move is fully automated, and ideally,
>>> nothing
>>> >>> will change in your workflow other than added features and access to
>>> >>> GitHub.
>>> >>>
>>> >>> ## Timeframe for relocation ##
>>> >>> Initially, we are asking that projects voluntarily request to move
>>> >>> their repositories to gitbox, hence this email. The voluntary
>>> >>> timeframe is between now and January 9th 2019, during which projects
>>> >>> are free to either move over to gitbox or stay put on git-wip. After
>>> >>> this phase, we will be requiring the remaining projects to move
>>> within
>>> >>> one month, after which we will move 

Build depends on Docker

[Richard Downer]

All,

The Apache Brooklyn build depends on having a working Docker instance. This
I did not know.

The build failure happens in the `brooklyn-dist` project, which
incorporates into execution `dockerfile-maven-plugin` which invokes Docker
during the build phase. If Docker is not running, it tries to connect to a
non-existent UNIX socket and the build fails.

This presents a few discussion points...

What exactly is it building? There's a Dockerfile there and it seems that
it builds an image which contains the Brooklyn distribution and starts
Brooklyn. I don't know much about Docker, what happens to that image? Is it
local to my computer?

Is it necessary to have the build depend on Docker? To me this seems
unreasonable. Docker has a large footprint and I don't think it's
reasonable to require it for a normal, local build of Brooklyn.

We're not releasing Docker images. Should we be? Should we not be? Is it
even possible for us to do that in Apache?

Why haven't I seen this before? The changes to add this to brooklyn-dist
were made in 2017. I've performed release builds on clean EC2 instances and
never seen this. Was this dormant, and has something changed which has
kicked this into life?

brooklyn-dist is obsolete now. If the Docker build is still something
important, then firstly it needs moved to another project (hopefully one
exclusive to that task) and secondly it needs to use the Karaf distribution.

Can anyone shed some light on this?

Thanks!

Richard.

Re: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Richard Downer]

Brooklyn team,

Apart from myself, I don't think anyone has clearly come out in favour or
opposed to this. I'd rather we got consensus and moved to gitbox early - so
that if some people do object, we have time to work out the objections with
infra, before we are involuntarily moved.

Thoughts, anyone? Does this need a formal vote to get people responding?

Richard.


On Fri, 7 Dec 2018 at 16:54, Daniel Gruno  wrote:

> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
>   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
>
> Hello Apache projects,
>
> I am writing to you because you may have git repositories on the
> git-wip-us server, which is slated to be decommissioned in the coming
> months. All repositories will be moved to the new gitbox service which
> includes direct write access on github as well as the standard ASF
> commit access via gitbox.apache.org.
>
> ## Why this move? ##
> The move comes as a result of retiring the git-wip service, as the
> hardware it runs on is longing for retirement. In lieu of this, we
> have decided to consolidate the two services (git-wip and gitbox), to
> ease the management of our repository systems and future-proof the
> underlying hardware. The move is fully automated, and ideally, nothing
> will change in your workflow other than added features and access to
> GitHub.
>
> ## Timeframe for relocation ##
> Initially, we are asking that projects voluntarily request to move
> their repositories to gitbox, hence this email. The voluntary
> timeframe is between now and January 9th 2019, during which projects
> are free to either move over to gitbox or stay put on git-wip. After
> this phase, we will be requiring the remaining projects to move within
> one month, after which we will move the remaining projects over.
>
> To have your project moved in this initial phase, you will need:
>
> - Consensus in the project (documented via the mailing list)
> - File a JIRA ticket with INFRA to voluntarily move your project repos
>over to gitbox (as stated, this is highly automated and will take
>between a minute and an hour, depending on the size and number of
>your repositories)
>
> To sum up the preliminary timeline;
>
> - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
>relocation
> - January 9th -> February 6th: Mandated (coordinated) relocation
> - February 7th: All remaining repositories are mass migrated.
>
> This timeline may change to accommodate various scenarios.
>
> ## Using GitHub with ASF repositories ##
> When your project has moved, you are free to use either the ASF
> repository system (gitbox.apache.org) OR GitHub for your development
> and code pushes. To be able to use GitHub, please follow the primer
> at: https://reference.apache.org/committer/github
>
>
> We appreciate your understanding of this issue, and hope that your
> project can coordinate voluntarily moving your repositories in a
> timely manner.
>
> All settings, such as commit mail targets, issue linking, PR
> notification schemes etc will automatically be migrated to gitbox as
> well.
>
> With regards, Daniel on behalf of ASF Infra.
>
> PS:For inquiries, please reply to us...@infra.apache.org, not your
> project's dev list :-).
>
>
>

Re: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Richard Downer]

Hi Geoff,

Moving to gitbox seems to be a no-brainer to me. It won't affect our
contributor's processes, and it makes our committer's processes easier.

+1 to making an active move to gitbox.

I'm personally not concerned by the date, but after Christmas and early in
the new year would be fine.

Richard.


On Fri, 7 Dec 2018 at 21:03, Geoff Macartney 
wrote:

> Hi Brooklyners,
>
> Looks like we'll have to move Brooklyn to gitbox. Any thoughts on when to
> do this? The voluntary timeframe is between now and January 9th 2019, and
> it might be convenient to get this done in the presumably slack period
> around Christmas.
>
> The process being
>
> - Consensus in the project (documented via the mailing list)
> - File a JIRA ticket with INFRA to voluntarily move your project repos over
> to gitbox
>
> shall we agree a timeframe in response to this email?  I'll volunteer to
> raise the INFRA ticket for the move once we're agreed.
>
> Let me suggest the week beginning 31st December.
>
> Regards
> Geoff
>
>
> On Fri, 7 Dec 2018 at 16:54 Daniel Gruno  wrote:
>
> > [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
> >   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> >
> > Hello Apache projects,
> >
> > I am writing to you because you may have git repositories on the
> > git-wip-us server, which is slated to be decommissioned in the coming
> > months. All repositories will be moved to the new gitbox service which
> > includes direct write access on github as well as the standard ASF
> > commit access via gitbox.apache.org.
> >
> > ## Why this move? ##
> > The move comes as a result of retiring the git-wip service, as the
> > hardware it runs on is longing for retirement. In lieu of this, we
> > have decided to consolidate the two services (git-wip and gitbox), to
> > ease the management of our repository systems and future-proof the
> > underlying hardware. The move is fully automated, and ideally, nothing
> > will change in your workflow other than added features and access to
> > GitHub.
> >
> > ## Timeframe for relocation ##
> > Initially, we are asking that projects voluntarily request to move
> > their repositories to gitbox, hence this email. The voluntary
> > timeframe is between now and January 9th 2019, during which projects
> > are free to either move over to gitbox or stay put on git-wip. After
> > this phase, we will be requiring the remaining projects to move within
> > one month, after which we will move the remaining projects over.
> >
> > To have your project moved in this initial phase, you will need:
> >
> > - Consensus in the project (documented via the mailing list)
> > - File a JIRA ticket with INFRA to voluntarily move your project repos
> >over to gitbox (as stated, this is highly automated and will take
> >between a minute and an hour, depending on the size and number of
> >your repositories)
> >
> > To sum up the preliminary timeline;
> >
> > - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
> >relocation
> > - January 9th -> February 6th: Mandated (coordinated) relocation
> > - February 7th: All remaining repositories are mass migrated.
> >
> > This timeline may change to accommodate various scenarios.
> >
> > ## Using GitHub with ASF repositories ##
> > When your project has moved, you are free to use either the ASF
> > repository system (gitbox.apache.org) OR GitHub for your development
> > and code pushes. To be able to use GitHub, please follow the primer
> > at: https://reference.apache.org/committer/github
> >
> >
> > We appreciate your understanding of this issue, and hope that your
> > project can coordinate voluntarily moving your repositories in a
> > timely manner.
> >
> > All settings, such as commit mail targets, issue linking, PR
> > notification schemes etc will automatically be migrated to gitbox as
> > well.
> >
> > With regards, Daniel on behalf of ASF Infra.
> >
> > PS:For inquiries, please reply to us...@infra.apache.org, not your
> > project's dev list :-).
> >
> >
> >
>

[ANNOUNCE] Apache Brooklyn 1.0.0-M1 released

[Richard Downer]

All,

The Apache Brooklyn PMC are pleased to announce the release of Apache
Brooklyn 1.0.0-M1.

This is our first milestone on our way to an official 1.0.0 release of
Brooklyn. This release includes a brand new UI, developed and generously
contributed to Apache by Cloudsoft.

The Brooklyn PMC would like to thank all the individuals who have
contributed code, documentation, reviews and feedback into this release.

The source release is available from:
https://www.apache.org/dyn/closer.lua?action=download&filename=brooklyn/apache-brooklyn-1.0.0-M1/apache-brooklyn-1.0.0-M1-src.tar.gz
SHA256 hash:
https://dist.apache.org/repos/dist/release/brooklyn/apache-brooklyn-1.0.0-M1/apache-brooklyn-1.0.0-M1-src.tar.gz.sha256
PGP signature:
https://dist.apache.org/repos/dist/release/brooklyn/apache-brooklyn-1.0.0-M1/apache-brooklyn-1.0.0-M1-src.tar.gz.asc

Convenient binary artifacts are available from:
https://brooklyn.apache.org/download/index.html#version-100-m1-preview-milestone-release
Hashes and signatures from:
https://brooklyn.apache.org/download/verify.html

Documentation is published to:
https://brooklyn.apache.org/v/1.0.0-M1/

In addition, a full set of Maven artifacts are available in the Apache
Maven repositories and in Maven Central.

Best regards
Richard Downer
Release Manager for 1.0.0-M1

[RESULT][VOTE] Release Apache Brooklyn 1.0.0-M1 [rc1]

[Richard Downer]

This vote is now closed. As release manager I am satisfied that there has
been wide enough testing from the people who voted.

The votes were:

+1 binding:

Thomas Bouron
Aled Sage
Geoff Macartney
Richard Downer

+1 non-binding:

John Campbell

There were no 0 or -1 votes.

With sufficient +1 binding votes and no -1 votes, the vote to release
1.0.0-M1 passes. I will proceed immediately to publish the artifacts,
announce the release, and update the online website and documentation.

Best regards

Richard Downer
Release Manager


On Wed, 12 Sep 2018 at 12:20, Richard Downer  wrote:

> This is to call for a vote for the release of Apache Brooklyn 1.0.0-M1.
>
> 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-1.0.0-M1-rc1
>
> The artifact SHA-256 checksums are as follows:
> 8ab0298ff524cdfbcf2653315a5f4dc1950ae2aa0f50202451e6bbe6dfa7b2f2
> *apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm
> b8005d59f8f40567fd204269ec0eaba3fc9bf1f42e1ce568357eb1e0ad2e46cb
> *apache-brooklyn-1.0.0-M1-rc1-bin.tar.gz
> e2658915d4453730757b001d48e07bdeecf87c944a9aa7fc28db0393626093b5
> *apache-brooklyn-1.0.0-M1-rc1-bin.zip
> f1af936ae01dfd90b73c66bbf26aa616b034ef844d84699e54e72586af66aef5
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-linux.tar.gz
> 9e449627b7e0816d86c8ef6022bcf37d5d3953cf15889904b4d6e4da17c6a0b0
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-linux.zip
> e42abb03d70ef85be93ffaa53614a324d26b4d112ded2f49937fbbd4268feec0
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-macosx.tar.gz
> 7ced5edf70684abdf0ed8a1c7512bb24a0ac250535e87934bb572fce8183baaa
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-macosx.zip
> 17ee4674bc13cc09d4d3f880e776b812234ca554f640f6fc55d4ec380560fa46
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-windows.tar.gz
> 61f03d4cd90b7404ad53bc51ce1f2b84f7a3cb50b93b3ea47260e596342e9874
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-windows.zip
> 7d20768b2c94689f9be3e7b6790c526661fc6d3a1b039cae8043bf6e8ae140c8
> *apache-brooklyn-1.0.0-M1-rc1.deb
> b3656c5ac7670ed0fb2383f4a84b080469d6d5df1f33935963b0ed403a849ad7
> *apache-brooklyn-1.0.0-M1-rc1-src.tar.gz
> 3ffc5e1701edf9b0fbde5d80686076af782df70e12c023f8cef370eb7c563d8f
> *apache-brooklyn-1.0.0-M1-rc1-src.zip
> 6d19c7c4278a72121ca6f9acd238a3dc9e479463bce3f2e19d47db899a46fb57
> *apache-brooklyn-1.0.0-M1-rc1-vagrant.tar.gz
> 337058e12695feee2e0b151ee26bdfaae3a95b8617289ee5ffec7f112e4819c3
> *apache-brooklyn-1.0.0-M1-rc1-vagrant.zip
>
> The Nexus staging repository for the Maven artifacts is located at:
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1052
>
> All release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/richard.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/brooklyn/KEYS
>
> The artifacts were built from these Git commit IDs:
> brooklyn: 5b160b1417e95f21c6b5d103c88c9f94ab526a60
> brooklyn-client: 600f620f7819853d0f9d944648f2f8e428d50786
> brooklyn-dist: 644ff07f04e4613e60facd7673a8436cb8c6d64c
> brooklyn-docs: 7e171cc52c61943e28598d354298b0469f7fd25e
> brooklyn-library: 740d33abd36b451863b1452e08754a83c3b3fe12
> brooklyn-server: ab2f98b4920ba96d5778233c189d298e61f80c23
> brooklyn-ui: 03d173160addcc11173ee1e46c2c60ce437c26b1
> All these commit IDs are tagged as rel/apache-brooklyn-1.0.0-M1-rc1
>
> Please vote on releasing this package as Apache Brooklyn 1.0.0-M1.
>
> The vote will be open for at least 72 hours.
> [ ] +1 Release this package as Apache Brooklyn 1.0.0-M1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
> Richard.
>

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

[Richard Downer]

+1

- Installed RPM package
- Verified the Apache Brooklyn instance, configured locations
- Performed a number of deployment to AWS
- Installed DEB package and performed basic operations checks
- Verified distribution package hashes and signatures

I did note a problem which I wrote down in BROOKLYN-601 [1]. Since this has
an easy workaround I do not consider it to be a release blocker.

Richard.

[1] https://issues.apache.org/jira/browse/BROOKLYN-601


On Wed, 12 Sep 2018 at 12:20, Richard Downer  wrote:

> This is to call for a vote for the release of Apache Brooklyn 1.0.0-M1.
>
> 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-1.0.0-M1-rc1
>
> The artifact SHA-256 checksums are as follows:
> 8ab0298ff524cdfbcf2653315a5f4dc1950ae2aa0f50202451e6bbe6dfa7b2f2
> *apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm
> b8005d59f8f40567fd204269ec0eaba3fc9bf1f42e1ce568357eb1e0ad2e46cb
> *apache-brooklyn-1.0.0-M1-rc1-bin.tar.gz
> e2658915d4453730757b001d48e07bdeecf87c944a9aa7fc28db0393626093b5
> *apache-brooklyn-1.0.0-M1-rc1-bin.zip
> f1af936ae01dfd90b73c66bbf26aa616b034ef844d84699e54e72586af66aef5
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-linux.tar.gz
> 9e449627b7e0816d86c8ef6022bcf37d5d3953cf15889904b4d6e4da17c6a0b0
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-linux.zip
> e42abb03d70ef85be93ffaa53614a324d26b4d112ded2f49937fbbd4268feec0
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-macosx.tar.gz
> 7ced5edf70684abdf0ed8a1c7512bb24a0ac250535e87934bb572fce8183baaa
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-macosx.zip
> 17ee4674bc13cc09d4d3f880e776b812234ca554f640f6fc55d4ec380560fa46
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-windows.tar.gz
> 61f03d4cd90b7404ad53bc51ce1f2b84f7a3cb50b93b3ea47260e596342e9874
> *apache-brooklyn-1.0.0-M1-rc1-client-cli-windows.zip
> 7d20768b2c94689f9be3e7b6790c526661fc6d3a1b039cae8043bf6e8ae140c8
> *apache-brooklyn-1.0.0-M1-rc1.deb
> b3656c5ac7670ed0fb2383f4a84b080469d6d5df1f33935963b0ed403a849ad7
> *apache-brooklyn-1.0.0-M1-rc1-src.tar.gz
> 3ffc5e1701edf9b0fbde5d80686076af782df70e12c023f8cef370eb7c563d8f
> *apache-brooklyn-1.0.0-M1-rc1-src.zip
> 6d19c7c4278a72121ca6f9acd238a3dc9e479463bce3f2e19d47db899a46fb57
> *apache-brooklyn-1.0.0-M1-rc1-vagrant.tar.gz
> 337058e12695feee2e0b151ee26bdfaae3a95b8617289ee5ffec7f112e4819c3
> *apache-brooklyn-1.0.0-M1-rc1-vagrant.zip
>
> The Nexus staging repository for the Maven artifacts is located at:
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1052
>
> All release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/richard.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/brooklyn/KEYS
>
> The artifacts were built from these Git commit IDs:
> brooklyn: 5b160b1417e95f21c6b5d103c88c9f94ab526a60
> brooklyn-client: 600f620f7819853d0f9d944648f2f8e428d50786
> brooklyn-dist: 644ff07f04e4613e60facd7673a8436cb8c6d64c
> brooklyn-docs: 7e171cc52c61943e28598d354298b0469f7fd25e
> brooklyn-library: 740d33abd36b451863b1452e08754a83c3b3fe12
> brooklyn-server: ab2f98b4920ba96d5778233c189d298e61f80c23
> brooklyn-ui: 03d173160addcc11173ee1e46c2c60ce437c26b1
> All these commit IDs are tagged as rel/apache-brooklyn-1.0.0-M1-rc1
>
> Please vote on releasing this package as Apache Brooklyn 1.0.0-M1.
>
> The vote will be open for at least 72 hours.
> [ ] +1 Release this package as Apache Brooklyn 1.0.0-M1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
> Richard.
>

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

[Richard Downer]

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 
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 
> 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  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
> >> r...@ec2-18-185-97-126.eu-central-1.compute.amazonaws.com 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  >> > <mailto:rich...@apache.org>> 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. Alongsid

[jira] [Comment Edited] (BROOKLYN-601) Provisioning very long when using RPM package

[Richard Downer (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613609#comment-16613609
 ] 

Richard Downer edited comment on BROOKLYN-601 at 9/13/18 3:04 PM:
--

Possible workarounds:
 * User to generate SSH keys for the brooklyn system user
 * User to configure alternative SSH keys in their location/blueprint

Possible fixes:
 * If Brooklyn does not have any credentials, fail fast, instead of spending 10 
minutes repeatedly trying to log in
 * Have the RPM (and presumably DEB as well) postinstall script generate SSH 
keys for the system user


was (Author: rdowner):
Possible workarounds:
 * User to generate SSH keys for the brooklyn system user
 * User to configure alternative SSH keys in their location/blueprint

Possible fixes:
 * If Brooklyn does not have any credentials, fail fast, instead of spending 10 
minutes repeatedly trying to log in
 * Have the RPM postinstall script generate SSH keys for the system user

> Provisioning very long when using RPM package
> -
>
> Key: BROOKLYN-601
> URL: https://issues.apache.org/jira/browse/BROOKLYN-601
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: AWS Linux (RPM-based) but would presumably affect *any* 
> environment which does not have SSH keys ready-to-use.
>Reporter: Richard Downer
>Priority: Major
>
> System is an AWS Linux box (RPM-based) using the 
> apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm package.
> Deployments using this system take a very long time to provision instances 
> (tested on AWS).
> On examining the debug log, I can see it is search for the {{brooklyn}} 
> system user's SSH key files:
> Since this newly-created system user doesn't have any SSH key files, it ends 
> up trying to log in to the instance with no credentials:
> {{2018-09-13T14:12:38,734 - DEBUG 133 o.a.b.l.j.JcloudsLocation 
> [nager-DV7OEufF-4] Credentials extracted for 
> {id=eu-west-1/i-05bd13b5ba7ff1f69, providerId=i-05bd13b5ba7ff1f69, 
> name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, location=}}
> {{{scope=ZONE, id=eu-west-1b, description=eu-west-1b, parent=eu-west-1, 
> iso3166Codes=[IE]}}}{{, 
> group=brooklyn-pezzf5-applicationaijwo-aijw-server-lant, 
> imageId=eu-west-1/ami-0eb66a0c3eb9f5183, os=}}{{{family=ubuntu, arch=hvm, 
> version=16.04, 
> description=aws-marketplace/ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180814-d83d0782-cb94-46d7-8993-f4ce15d1a484-ami-04169656fea786776.4,
>  is64Bit=true}}}{{, status=RUNNING[running], loginPort=22, 
> hostname=ip-172-31-41-218, privateAddresses=[172.31.41.218], 
> publicAddresses=[52.214.254.195], hardware={id=t2.small, providerId=t2.small, 
> processors=[}}{{{cores=1.0, speed=0.2}}}{{], ram=2048, 
> volumes=[}}{{{id=vol-01112c6e3486ac4d0, type=SAN, device=/dev/sda1, 
> bootDevice=true, durable=true}}}{{], hypervisor=xen, 
> supportsImage=Predicates.and(requiresRootDeviceType(ebs),requiresVirtualizationType(hvm),Predicates.alwaysTrue(),Predicates.alwaysTrue())},
>  loginUser=brooklyn, 
> userMetadata=\{Name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, 
> brooklyn-user=brooklyn, brooklyn-app-id=aijwo81iay, 
> brooklyn-app-name=Application (aijwo81iay), brooklyn-entity-id=lant5abn8y, 
> brooklyn-entity-name=Server, brooklyn-server-creation-date=2018-09-13-1411}}: 
> brooklyn/brooklyn with 
> OsCredential[no-public-key;no-private-key,no-password]/[user=brooklyn, 
> passwordPresent=true, privateKeyPresent=false, shouldAuthenticateSudo=false]}}
> {{ 2018-09-13T14:12:38,756 - DEBUG 133 o.a.b.l.j.JcloudsLocation 
> [nager-DV7OEufF-4] VM 
> aws-ec2:eu-west-1@EmptySoftwareProcessImpl}}{{{id=lant5abn8y}}}{{: reported 
> online, now waiting 5m for it to be contactable on 
> brooklyn@52.214.254.195:22; trying 1 credential: user=brooklyn, 
> password=**, key=}}
> {{ 2018-09-13T14:12:38,759 - DEBUG 128 o.a.b.SSH [nager-DV7OEufF-4] 
> check-connectivity, initiating ssh on machine SshMachineLocation[AWS 
> Dublin:brooklyn@52.214.254.195/52.214.254.195:22(id=jd41hctb1o)]: #!/bin/bash 
> -e}}
> {{ ; true}}
> {{ 2018-09-13T14:12:38,769 - DEBUG 128 o.a.b.l.s.SshMachineLocation 
> [nager-DV7OEufF-4] Create-unmanaged for SshMachineLocation[AWS 
> Dublin:brooklyn@52.214.254.195/52.214.254.195:22(id=jd41hctb1o)]; no explicit 
> cleanup task; ssh-pool cache will only be closed when machine is closed}}
> {{ 2018-09-13T14:12:38,770 - DEBUG 128 o.a.b.l.s.SshMachineLocation 
> [nager-DV7OEufF-4] 
> org.apache.brooklyn.location.ssh.SshMachineLocation$4@7c8aa530 building ssh 
> pool for

[jira] [Commented] (BROOKLYN-601) Provisioning very long when using RPM package

[Richard Downer (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613609#comment-16613609
 ] 

Richard Downer commented on BROOKLYN-601:
-

Possible workarounds:
 * User to generate SSH keys for the brooklyn system user
 * User to configure alternative SSH keys in their location/blueprint

Possible fixes:
 * If Brooklyn does not have any credentials, fail fast, instead of spending 10 
minutes repeatedly trying to log in
 * Have the RPM postinstall script generate SSH keys for the system user

> Provisioning very long when using RPM package
> -
>
> Key: BROOKLYN-601
> URL: https://issues.apache.org/jira/browse/BROOKLYN-601
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: AWS Linux (RPM-based) but would presumably affect *any* 
> environment which does not have SSH keys ready-to-use.
>Reporter: Richard Downer
>Priority: Major
>
> System is an AWS Linux box (RPM-based) using the 
> apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm package.
> Deployments using this system take a very long time to provision instances 
> (tested on AWS).
> On examining the debug log, I can see it is search for the {{brooklyn}} 
> system user's SSH key files:
> Since this newly-created system user doesn't have any SSH key files, it ends 
> up trying to log in to the instance with no credentials:
> {{2018-09-13T14:12:38,734 - DEBUG 133 o.a.b.l.j.JcloudsLocation 
> [nager-DV7OEufF-4] Credentials extracted for 
> {id=eu-west-1/i-05bd13b5ba7ff1f69, providerId=i-05bd13b5ba7ff1f69, 
> name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, location=}}
> {{{scope=ZONE, id=eu-west-1b, description=eu-west-1b, parent=eu-west-1, 
> iso3166Codes=[IE]}}}{{, 
> group=brooklyn-pezzf5-applicationaijwo-aijw-server-lant, 
> imageId=eu-west-1/ami-0eb66a0c3eb9f5183, os=}}{{{family=ubuntu, arch=hvm, 
> version=16.04, 
> description=aws-marketplace/ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180814-d83d0782-cb94-46d7-8993-f4ce15d1a484-ami-04169656fea786776.4,
>  is64Bit=true}}}{{, status=RUNNING[running], loginPort=22, 
> hostname=ip-172-31-41-218, privateAddresses=[172.31.41.218], 
> publicAddresses=[52.214.254.195], hardware={id=t2.small, providerId=t2.small, 
> processors=[}}{{{cores=1.0, speed=0.2}}}{{], ram=2048, 
> volumes=[}}{{{id=vol-01112c6e3486ac4d0, type=SAN, device=/dev/sda1, 
> bootDevice=true, durable=true}}}{{], hypervisor=xen, 
> supportsImage=Predicates.and(requiresRootDeviceType(ebs),requiresVirtualizationType(hvm),Predicates.alwaysTrue(),Predicates.alwaysTrue())},
>  loginUser=brooklyn, 
> userMetadata=\{Name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, 
> brooklyn-user=brooklyn, brooklyn-app-id=aijwo81iay, 
> brooklyn-app-name=Application (aijwo81iay), brooklyn-entity-id=lant5abn8y, 
> brooklyn-entity-name=Server, brooklyn-server-creation-date=2018-09-13-1411}}: 
> brooklyn/brooklyn with 
> OsCredential[no-public-key;no-private-key,no-password]/[user=brooklyn, 
> passwordPresent=true, privateKeyPresent=false, shouldAuthenticateSudo=false]}}
> {{ 2018-09-13T14:12:38,756 - DEBUG 133 o.a.b.l.j.JcloudsLocation 
> [nager-DV7OEufF-4] VM 
> aws-ec2:eu-west-1@EmptySoftwareProcessImpl}}{{{id=lant5abn8y}}}{{: reported 
> online, now waiting 5m for it to be contactable on 
> brooklyn@52.214.254.195:22; trying 1 credential: user=brooklyn, 
> password=**, key=}}
> {{ 2018-09-13T14:12:38,759 - DEBUG 128 o.a.b.SSH [nager-DV7OEufF-4] 
> check-connectivity, initiating ssh on machine SshMachineLocation[AWS 
> Dublin:brooklyn@52.214.254.195/52.214.254.195:22(id=jd41hctb1o)]: #!/bin/bash 
> -e}}
> {{ ; true}}
> {{ 2018-09-13T14:12:38,769 - DEBUG 128 o.a.b.l.s.SshMachineLocation 
> [nager-DV7OEufF-4] Create-unmanaged for SshMachineLocation[AWS 
> Dublin:brooklyn@52.214.254.195/52.214.254.195:22(id=jd41hctb1o)]; no explicit 
> cleanup task; ssh-pool cache will only be closed when machine is closed}}
> {{ 2018-09-13T14:12:38,770 - DEBUG 128 o.a.b.l.s.SshMachineLocation 
> [nager-DV7OEufF-4] 
> org.apache.brooklyn.location.ssh.SshMachineLocation$4@7c8aa530 building ssh 
> pool for 52.214.254.195:22 with properties:}}{{{connectTimeout=3, 
> sshTries=1, sessionTimeout=3, 
> sshTriesTimeout=3}}}{{2018-09-13T14:12:38,863 - DEBUG 128 
> o.a.b.u.c.i.s.s.SshjTool [nager-DV7OEufF-4] << (brooklyn@52.214.254.195:22) 
> error acquiring}}{{{hostAndPort=52.214.254.195:22, user=brooklyn, 
> ssh=1626499876, password=xx, privateKeyFile=null, privateKey=null, 
> connectTimeout=3, sessionTimeout=3}}}{{(attempt 1/1

[jira] [Created] (BROOKLYN-601) Provisioning very long when using RPM package

[Richard Downer (JIRA)]

Richard Downer created BROOKLYN-601:
---

 Summary: Provisioning very long when using RPM package
 Key: BROOKLYN-601
 URL: https://issues.apache.org/jira/browse/BROOKLYN-601
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 1.0.0
 Environment: AWS Linux (RPM-based) but would presumably affect *any* 
environment which does not have SSH keys ready-to-use.
Reporter: Richard Downer


System is an AWS Linux box (RPM-based) using the 
apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm package.

Deployments using this system take a very long time to provision instances 
(tested on AWS).

On examining the debug log, I can see it is search for the {{brooklyn}} system 
user's SSH key files:

Since this newly-created system user doesn't have any SSH key files, it ends up 
trying to log in to the instance with no credentials:

{{2018-09-13T14:12:38,734 - DEBUG 133 o.a.b.l.j.JcloudsLocation 
[nager-DV7OEufF-4] Credentials extracted for {id=eu-west-1/i-05bd13b5ba7ff1f69, 
providerId=i-05bd13b5ba7ff1f69, 
name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, location=}}
{{{scope=ZONE, id=eu-west-1b, description=eu-west-1b, parent=eu-west-1, 
iso3166Codes=[IE]}}}{{, 
group=brooklyn-pezzf5-applicationaijwo-aijw-server-lant, 
imageId=eu-west-1/ami-0eb66a0c3eb9f5183, os=}}{{{family=ubuntu, arch=hvm, 
version=16.04, 
description=aws-marketplace/ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180814-d83d0782-cb94-46d7-8993-f4ce15d1a484-ami-04169656fea786776.4,
 is64Bit=true}}}{{, status=RUNNING[running], loginPort=22, 
hostname=ip-172-31-41-218, privateAddresses=[172.31.41.218], 
publicAddresses=[52.214.254.195], hardware={id=t2.small, providerId=t2.small, 
processors=[}}{{{cores=1.0, speed=0.2}}}{{], ram=2048, 
volumes=[}}{{{id=vol-01112c6e3486ac4d0, type=SAN, device=/dev/sda1, 
bootDevice=true, durable=true}}}{{], hypervisor=xen, 
supportsImage=Predicates.and(requiresRootDeviceType(ebs),requiresVirtualizationType(hvm),Predicates.alwaysTrue(),Predicates.alwaysTrue())},
 loginUser=brooklyn, 
userMetadata=\{Name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, 
brooklyn-user=brooklyn, brooklyn-app-id=aijwo81iay, 
brooklyn-app-name=Application (aijwo81iay), brooklyn-entity-id=lant5abn8y, 
brooklyn-entity-name=Server, brooklyn-server-creation-date=2018-09-13-1411}}: 
brooklyn/brooklyn with 
OsCredential[no-public-key;no-private-key,no-password]/[user=brooklyn, 
passwordPresent=true, privateKeyPresent=false, shouldAuthenticateSudo=false]}}
{{ 2018-09-13T14:12:38,756 - DEBUG 133 o.a.b.l.j.JcloudsLocation 
[nager-DV7OEufF-4] VM 
aws-ec2:eu-west-1@EmptySoftwareProcessImpl}}{{{id=lant5abn8y}}}{{: reported 
online, now waiting 5m for it to be contactable on brooklyn@52.214.254.195:22; 
trying 1 credential: user=brooklyn, password=**, key=}}
{{ 2018-09-13T14:12:38,759 - DEBUG 128 o.a.b.SSH [nager-DV7OEufF-4] 
check-connectivity, initiating ssh on machine SshMachineLocation[AWS 
Dublin:brooklyn@52.214.254.195/52.214.254.195:22(id=jd41hctb1o)]: #!/bin/bash 
-e}}
{{ ; true}}
{{ 2018-09-13T14:12:38,769 - DEBUG 128 o.a.b.l.s.SshMachineLocation 
[nager-DV7OEufF-4] Create-unmanaged for SshMachineLocation[AWS 
Dublin:brooklyn@52.214.254.195/52.214.254.195:22(id=jd41hctb1o)]; no explicit 
cleanup task; ssh-pool cache will only be closed when machine is closed}}
{{ 2018-09-13T14:12:38,770 - DEBUG 128 o.a.b.l.s.SshMachineLocation 
[nager-DV7OEufF-4] 
org.apache.brooklyn.location.ssh.SshMachineLocation$4@7c8aa530 building ssh 
pool for 52.214.254.195:22 with properties:}}{{{connectTimeout=3, 
sshTries=1, sessionTimeout=3, 
sshTriesTimeout=3}}}{{2018-09-13T14:12:38,863 - DEBUG 128 
o.a.b.u.c.i.s.s.SshjTool [nager-DV7OEufF-4] << (brooklyn@52.214.254.195:22) 
error acquiring}}{{{hostAndPort=52.214.254.195:22, user=brooklyn, 
ssh=1626499876, password=xx, privateKeyFile=null, privateKey=null, 
connectTimeout=3, sessionTimeout=3}}}{{(attempt 1/1, in time 84ms/30s) 
(rethrowing, out of retries): Exhausted available authentication methods}}
{{ 2018-09-13T14:12:38,864 - DEBUG 128 o.a.b.u.c.i.s.s.SshjTool 
[nager-DV7OEufF-4] brooklyn@52.214.254.195:22 failed to connect (rethrowing)}}
{{ org.apache.brooklyn.util.core.internal.ssh.SshException: 
(brooklyn@52.214.254.195:22) (brooklyn@52.214.254.195:22) error 
acquiring}}{{{hostAndPort=52.214.254.195:22, user=brooklyn, ssh=1626499876, 
password=xx, privateKeyFile=null, privateKey=null, connectTimeout=3, 
sessionTimeout=3}}}{{(attempt 1/1, in time 84ms/30s); out of retries: 
Exhausted available authentication methods

It then repeats the connection attempt for 10 minutes.

Strangely, once this process has failed, it's not an error: Brooklyn continues, 
and somehow it's found some useful credentials and it logs in:

{{2018-09-13T14:22:40,295 - DEBUG 128 o.a.b.c.l.LocationConfigUtils 
[nager-DV7OEufF-4

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

[Richard Downer]

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

[VOTE] Release Apache Brooklyn 1.0.0-M1 [rc1]

[Richard Downer]

This is to call for a vote for the release of Apache Brooklyn 1.0.0-M1.

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-1.0.0-M1-rc1

The artifact SHA-256 checksums are as follows:
8ab0298ff524cdfbcf2653315a5f4dc1950ae2aa0f50202451e6bbe6dfa7b2f2
*apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm
b8005d59f8f40567fd204269ec0eaba3fc9bf1f42e1ce568357eb1e0ad2e46cb
*apache-brooklyn-1.0.0-M1-rc1-bin.tar.gz
e2658915d4453730757b001d48e07bdeecf87c944a9aa7fc28db0393626093b5
*apache-brooklyn-1.0.0-M1-rc1-bin.zip
f1af936ae01dfd90b73c66bbf26aa616b034ef844d84699e54e72586af66aef5
*apache-brooklyn-1.0.0-M1-rc1-client-cli-linux.tar.gz
9e449627b7e0816d86c8ef6022bcf37d5d3953cf15889904b4d6e4da17c6a0b0
*apache-brooklyn-1.0.0-M1-rc1-client-cli-linux.zip
e42abb03d70ef85be93ffaa53614a324d26b4d112ded2f49937fbbd4268feec0
*apache-brooklyn-1.0.0-M1-rc1-client-cli-macosx.tar.gz
7ced5edf70684abdf0ed8a1c7512bb24a0ac250535e87934bb572fce8183baaa
*apache-brooklyn-1.0.0-M1-rc1-client-cli-macosx.zip
17ee4674bc13cc09d4d3f880e776b812234ca554f640f6fc55d4ec380560fa46
*apache-brooklyn-1.0.0-M1-rc1-client-cli-windows.tar.gz
61f03d4cd90b7404ad53bc51ce1f2b84f7a3cb50b93b3ea47260e596342e9874
*apache-brooklyn-1.0.0-M1-rc1-client-cli-windows.zip
7d20768b2c94689f9be3e7b6790c526661fc6d3a1b039cae8043bf6e8ae140c8
*apache-brooklyn-1.0.0-M1-rc1.deb
b3656c5ac7670ed0fb2383f4a84b080469d6d5df1f33935963b0ed403a849ad7
*apache-brooklyn-1.0.0-M1-rc1-src.tar.gz
3ffc5e1701edf9b0fbde5d80686076af782df70e12c023f8cef370eb7c563d8f
*apache-brooklyn-1.0.0-M1-rc1-src.zip
6d19c7c4278a72121ca6f9acd238a3dc9e479463bce3f2e19d47db899a46fb57
*apache-brooklyn-1.0.0-M1-rc1-vagrant.tar.gz
337058e12695feee2e0b151ee26bdfaae3a95b8617289ee5ffec7f112e4819c3
*apache-brooklyn-1.0.0-M1-rc1-vagrant.zip

The Nexus staging repository for the Maven artifacts is located at:
https://repository.apache.org/content/repositories/orgapachebrooklyn-1052

All release artifacts are signed with the following key:
https://people.apache.org/keys/committer/richard.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/brooklyn/KEYS

The artifacts were built from these Git commit IDs:
brooklyn: 5b160b1417e95f21c6b5d103c88c9f94ab526a60
brooklyn-client: 600f620f7819853d0f9d944648f2f8e428d50786
brooklyn-dist: 644ff07f04e4613e60facd7673a8436cb8c6d64c
brooklyn-docs: 7e171cc52c61943e28598d354298b0469f7fd25e
brooklyn-library: 740d33abd36b451863b1452e08754a83c3b3fe12
brooklyn-server: ab2f98b4920ba96d5778233c189d298e61f80c23
brooklyn-ui: 03d173160addcc11173ee1e46c2c60ce437c26b1
All these commit IDs are tagged as rel/apache-brooklyn-1.0.0-M1-rc1

Please vote on releasing this package as Apache Brooklyn 1.0.0-M1.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 1.0.0-M1
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks,
Richard.

[jira] [Assigned] (BROOKLYN-597) Remove MD5 and SHA-1 checksums

[Richard Downer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer reassigned BROOKLYN-597:
---

Assignee: Richard Downer

> Remove MD5 and SHA-1 checksums 
> ---
>
> Key: BROOKLYN-597
> URL: https://issues.apache.org/jira/browse/BROOKLYN-597
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 0.12.0
>Reporter: Geoff Macartney
>    Assignee: Richard Downer
>Priority: Major
>
> Per the recently updated Apache Release Distribution Policy, 
> [https://www.apache.org/dev/release-distribution], we should remove the 
> generation and checking of MD5 and SHA-1 checksums from brooklyn-dist/release 
> before we do another release, presumably 1.0.
> The relevant wording is 
> {quote}For every artifact distributed to the public through Apache channels, 
> the PMC
>  * MUST supply a 
> [valid|https://www.apache.org/dev/release-signing#verifying-signature] 
> [OpenPGP-compatible ASCII-armored detached 
> signature|https://www.apache.org/dev/release-signing#openpgp-ascii-detach-sig]
>  file
>  * MUST supply at least one checksum file
>  * SHOULD supply a [SHA-256 and/or 
> SHA-512|https://www.apache.org/dev/release-signing#sha-checksum] checksum file
>  * SHOULD NOT supply a MD5 or SHA-1 checksum file (because these are 
> deprecated)
> For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT 
> supply MD5 or SHA-1. Existing releases do not need to be changed.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Time to make a release?

[Richard Downer]

Ok, the stars have aligned for a release - I've got a smoke test build
passing and all the requested PRs have been merged.

Here's what the first release candidate will be built from:

brooklyn-server: e601350d75eb61f0056f4900eca898426348ced9
https://github.com/apache/brooklyn-server/commits/e601350d75eb61f0056f4900eca898426348ced9

brooklyn-library: a94f7d84ebcd984ec7c44d62add2f00d5e663717
https://github.com/apache/brooklyn-library/commits/a94f7d84ebcd984ec7c44d62add2f00d5e663717


brooklyn-docs: 2b06e9605e1ee23f27f0d81d249074a60350cff6
https://github.com/apache/brooklyn-docs/commits/2b06e9605e1ee23f27f0d81d249074a60350cff6

brooklyn-client: 05031a79d4724b867db76b7c4afe55190666c7af
https://github.com/apache/brooklyn-client/commits/05031a79d4724b867db76b7c4afe55190666c7af

brooklyn-ui: 503d74eb20bc5206daaa0cfcf1f55b2e0cd0d5c9
https://github.com/apache/brooklyn-ui/commits/503d74eb20bc5206daaa0cfcf1f55b2e0cd0d5c9

brooklyn-dist: 3a30944e22052bb7b9c406e285a73f0e9236d0f7
https://github.com/apache/brooklyn-dist/commits/3a30944e22052bb7b9c406e285a73f0e9236d0f7

More updates to follow.

Richard.


On Tue, 4 Sep 2018 at 10:25, Richard Downer  wrote:

> Looks like we have a consensus.
>
> **KLAXON**
>
> Last call for PRs before the release. Please let me know TODAY if there's
> anything that needs to go in. Tomorrow morning I'll assess the requested
> PRs and get a release started.
>
> Richard.
>
>
> On Tue, 4 Sep 2018 at 09:41, Thomas Bouron <
> thomas.bou...@cloudsoftcorp.com> wrote:
>
>> +1
>>
>> On Tue, 4 Sep 2018 at 09:34 Geoff Macartney 
>> wrote:
>>
>>> +1 to an interim release
>>>
>>> On Mon, 3 Sep 2018 at 13:31 Alex Heneveld <
>>> alex.henev...@cloudsoftcorp.com>
>>> wrote:
>>>
>>> >
>>> > +1
>>> >
>>> > We might want to make an effort to get these merged (but I don't think
>>> > it's critical):
>>> >
>>> > * https://github.com/apache/brooklyn-server/pulls
>>> >  #982 - better type coercion
>>> >  #971 - location DSL
>>> >
>>> > There are a few others in library, docs, and dist, which we should take
>>> > care of as general housekeeping but not ahead of an M1 IMO.
>>> >
>>> > Best
>>> > Alex
>>> >
>>> >
>>> > On 03/09/2018 13:24, Aled Sage wrote:
>>> > > +1
>>> > >
>>> > > Assuming there's consensus, shall we give 24 hours for folk to get
>>> any
>>> > > outstanding PRs submitted/merged, before we kick an RC1 etc?
>>> > >
>>> > > Aled
>>> > >
>>> > >
>>> > > On 03/09/2018 13:17, Richard Downer wrote:
>>> > >> All,
>>> > >>
>>> > >> It's probably about time we made a release - shockingly, it's been
>>> > >> nearly a
>>> > >> year since the last one.
>>> > >>
>>> > >> We want to start the release train towards a 1.0 release, but I
>>> think we
>>> > >> could benefit from an interim release first, given that the paint is
>>> > >> still
>>> > >> drying on the new UI. Therefore I propose a "milestone 1" release,
>>> > >> 1.0.0-M1. I'm happy to volunteer to be release manager on this one.
>>> > >>
>>> > >> Thoughts, comments, +1 or -1?
>>> > >>
>>> > >> Cheers
>>> > >> 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.
>>
>

Re: Time to make a release?

[Richard Downer]

Looks like we have a consensus.

**KLAXON**

Last call for PRs before the release. Please let me know TODAY if there's
anything that needs to go in. Tomorrow morning I'll assess the requested
PRs and get a release started.

Richard.


On Tue, 4 Sep 2018 at 09:41, Thomas Bouron 
wrote:

> +1
>
> On Tue, 4 Sep 2018 at 09:34 Geoff Macartney 
> wrote:
>
>> +1 to an interim release
>>
>> On Mon, 3 Sep 2018 at 13:31 Alex Heneveld <
>> alex.henev...@cloudsoftcorp.com>
>> wrote:
>>
>> >
>> > +1
>> >
>> > We might want to make an effort to get these merged (but I don't think
>> > it's critical):
>> >
>> > * https://github.com/apache/brooklyn-server/pulls
>> >  #982 - better type coercion
>> >  #971 - location DSL
>> >
>> > There are a few others in library, docs, and dist, which we should take
>> > care of as general housekeeping but not ahead of an M1 IMO.
>> >
>> > Best
>> > Alex
>> >
>> >
>> > On 03/09/2018 13:24, Aled Sage wrote:
>> > > +1
>> > >
>> > > Assuming there's consensus, shall we give 24 hours for folk to get any
>> > > outstanding PRs submitted/merged, before we kick an RC1 etc?
>> > >
>> > > Aled
>> > >
>> > >
>> > > On 03/09/2018 13:17, Richard Downer wrote:
>> > >> All,
>> > >>
>> > >> It's probably about time we made a release - shockingly, it's been
>> > >> nearly a
>> > >> year since the last one.
>> > >>
>> > >> We want to start the release train towards a 1.0 release, but I
>> think we
>> > >> could benefit from an interim release first, given that the paint is
>> > >> still
>> > >> drying on the new UI. Therefore I propose a "milestone 1" release,
>> > >> 1.0.0-M1. I'm happy to volunteer to be release manager on this one.
>> > >>
>> > >> Thoughts, comments, +1 or -1?
>> > >>
>> > >> Cheers
>> > >> 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.
>

Time to make a release?

[Richard Downer]

All,

It's probably about time we made a release - shockingly, it's been nearly a
year since the last one.

We want to start the release train towards a 1.0 release, but I think we
could benefit from an interim release first, given that the paint is still
drying on the new UI. Therefore I propose a "milestone 1" release,
1.0.0-M1. I'm happy to volunteer to be release manager on this one.

Thoughts, comments, +1 or -1?

Cheers
Richard

Re: [VOTE] New Angular UI for Brooklyn

[Richard Downer]

Alex,

Agree with Thomas - the code has been [VOTE]ed in so there's no need for a
second stage of review, and pushing a massive PR isn't easy to navigate in
the GitHub UI. So just push straight to master on the Apache git repo.

There's a safety net in that the code is going into a `new` subdirectory so
interested individuals can still conduct a detailed code review.

Thanks
Richard.


On Thu, 26 Jul 2018 at 10:41, Thomas Bouron 
wrote:

> Hi Alex.
>
> Great news, I'm super excited to see this land!
> I don't think the PR approach makes sense in this context, the code is
> completely different from the current code base, there isn't much benefit
> or doing a PR and see the differences between the two.
>
> I would push directly IMO.
>
> Best.
>
> On Thu, 26 Jul 2018 at 10:32 Alex Heneveld <
> alex.henev...@cloudsoftcorp.com>
> wrote:
>
> >
> > Hi Brooklyners-
> >
> > I also give a +1 (binding).
> >
> > With 72h elapsed I declare the VOTE closed and passed.
> >
> > The [IP-CLEARANCE] also passed as folks will see.  I will incorporate
> > the new code now.  I will do this as a PR for visibility and call out
> > the IP-CLEARANCE process links in that PR, unless anyone thinks a
> > different approach is more suitable (e.g. pushing directly?).
> >
> > Best regards
> > Alex
> >
> >
> > On 23/07/2018 14:22, Geoff Macartney wrote:
> > > +1 (binding)
> > >
> > > Excited to see this go into Brooklyn
> > >
> > >
> > > On Mon, 23 Jul 2018 at 14:13 Richard Downer 
> wrote:
> > >
> > >> +1 (binding)
> > >>
> > >> Having seen this UI in action I'd be very happy for it to land into
> > >> Brooklyn. It's a much more modern-looking, aesthetically-pleasing UI
> > with
> > >> much more extensibility, but at it's core the UI works very similar to
> > the
> > >> old one, so there's very little learning curve for a user moving from
> > the
> > >> old UI to the new.
> > >>
> > >> Richard.
> > >>
> > >>
> > >> On Mon, 23 Jul 2018 at 10:07, Alex Heneveld <
> > >> alex.henev...@cloudsoftcorp.com>
> > >> wrote:
> > >>
> > >>> Hi Brooklyners-
> > >>>
> > >>> This is a vote on whether to accept the brooklyn-ui-angular
> > contribution
> > >>> at [1] once IP clearance is completed.
> > >>>
> > >>> For background, as previously discussed a new UI based on Angular/JS
> > has
> > >>> been offered to the Apache Brooklyn project.  The formal grant has
> been
> > >>> completed and is on file -- thank you Cloudsoft and Fujitsu -- and is
> > >>> currently going through IP Clearance (see prior email to this list)
> and
> > >>> barring obstacles we may have that clearance after 72 hours.  The
> vote
> > >>> to accept can occur in parallel with the clearance so that is what we
> > >>> are doing.
> > >>>
> > >>> We propose for the code to be added iniitially to a `new/`
> subdirectory
> > >>> in the `brooklyn-ui` repo, once IP clearance is completed and if this
> > >>> vote is successful.  We will then create a set of PRs to replace the
> > >>> contents at the root with the contents under `new/` and make changes
> > >>> elsewhere as needed for the project to build, run, and be documented
> > >>> cleanly.  It is proposed that those PRs be reviewed in the usual way
> > (no
> > >>> further votes) unless anyone thinks otherwise.
> > >>>
> > >>> This vote will run for 72 hours.
> > >>>
> > >>> Best
> > >>> Alex
> > >>>
> > >>> [1]  https://issues.apache.org/jira/browse/INCUBATOR-214
> > >>>
> > >>>
> > >>> On 20/07/2018 16:14, Alex Heneveld wrote:
> > >>>> Hi All-
> > >>>>
> > >>>> The codebase for the UI is staged for review here:
> > >>>>
> > >>>> https://github.com/ahgittin/brooklyn-ui/tree/new-ui-for-review/new
> > >>>>
> > >>>> We have created the ip-clearance record [1] to track steps and the
> > >>>> legal grant is in process (as per [2]).  We will call for an [IP
> > >>>> CLEARANCE] at general@incubator once those are completed, and then
> we
>

Re: Windows builds

[Richard Downer]

Thomas,

I've done a build on my Windows laptop and I can see this same error.
Judging by the exception message ("`C`") it looks like a Windows path
conversion error. I'll investigate.

Richard.

On Mon, 23 Jul 2018 at 16:28, Thomas Bouron 
wrote:

> Hi Brooklyners
>
> Does anyone here managed to build Brooklyn on their windows machine? We
> have jenkins job to do this[1] but it has been failing for a long time with
> the following error:
>
> --
>
> testCreate(org.apache.brooklyn.util.core.osgi.BundleMakerTest)  Time
> elapsed: 4.675 sec  <<< FAILURE!
> org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: Error
> starting bundle from
> C:\Users\jenkins\AppData\Local\Temp\1\test-5216526245768218750.zip
> at
> org.apache.brooklyn.util.core.osgi.BundleMakerTest.testCreate(BundleMakerTest.java:255)
> Caused by: org.apache.brooklyn.util.exceptions.PropagatedRuntimeException:
> Error getting resource
> 'file://C:/Users/jenkins/AppData/Local/Temp/1/test-5216526245768218750.zip'
> for class org.apache.brooklyn.util.core.osgi.Osgis
> at
> org.apache.brooklyn.util.core.osgi.BundleMakerTest.testCreate(BundleMakerTest.java:255)
> Caused by: java.net.UnknownHostException: C
> at
> org.apache.brooklyn.util.core.osgi.BundleMakerTest.testCreate(BundleMakerTest.java:255)
>
> testInstallBundle(org.apache.brooklyn.util.core.osgi.BundleMakerTest)
> Time elapsed: 0.022 sec  <<< FAILURE!
> org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: Error
> starting bundle from
>
> C:\Users\jenkins\AppData\Local\Temp\1\base-2067680450466845159.jar-3407788934373169015.zip
> at
> org.apache.brooklyn.util.core.osgi.BundleMakerTest.testInstallBundle(BundleMakerTest.java:230)
> Caused by: org.apache.brooklyn.util.exceptions.PropagatedRuntimeException:
> Error getting resource
>
> 'file://C:/Users/jenkins/AppData/Local/Temp/1/base-2067680450466845159.jar-3407788934373169015.zip'
> for class org.apache.brooklyn.util.core.osgi.Osgis
> at
> org.apache.brooklyn.util.core.osgi.BundleMakerTest.testInstallBundle(BundleMakerTest.java:230)
> Caused by: java.net.UnknownHostException: C
> at
> org.apache.brooklyn.util.core.osgi.BundleMakerTest.testInstallBundle(BundleMakerTest.java:230)
>
> --
>
>
> Did you ever encounter this? Any idea on how to setup the job config to
> avoid this issue?
>
> Best.
>
>
> [1]
> https://builds.apache.org/view/B/view/Brooklyn/job/brooklyn-master-windows
> --
>
> Thomas Bouron
> Senior Software Engineer
>
> *Cloudsoft  *| Bringing Business to the Cloud
>
> GitHub: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>
> Need a hand with AWS? Get a Free Consultation.
>

Re: [PROPOSAL] Using docker for jenkins builds

[Richard Downer]

behave as
> >> expected. If yes, I'll then move on to:
> >> - migrate the PR's jobs to use docker
> >> - add the `Dockerfile` within each git submodule
> >> - leverage the Jenkins' pipeline feature by adding the config directly
> in
> >> each git submodule
> >> - create new job to build and publish docs/website automatically
> >>
> >> Best
> >>
> >> [1]
> >>
> https://builds.apache.org/view/B/view/Brooklyn/job/brooklyn-master-windows/
> >>
> >> On Wed, 15 Nov 2017 at 11:18 John McCabe  wrote:
> >>
> >>> Huge +1 on consistency/portability.
> >>>
> >>> On Tue, 14 Nov 2017 at 16:40 Mark McKenna 
> >>> wrote:
> >>>
> >>> > +1 I echo what Richard says about consistency ... also makes
> debugging
> >>> > build failures easier
> >>> >
> >>> >
> >>> >
> >>> > On 14 November 2017 at 15:48, Richard Downer 
> >>> wrote:
> >>> >
> >>> > > +1
> >>> > >
> >>> > > Having seen some of the conversations on the bui...@apache.org
> >>> list, it
> >>> > > does seem like this is the way to go as far as getting the right
> >>> build
> >>> > > environment on the Apache Jenkins cluster. This is the best
> solution
> >>> for
> >>> > > getting the `rpm` and `deb` built regularly.
> >>> > >
> >>> > > Build consistency is also a great driver. I can see this being
> >>> useful for
> >>> > > the release process too, as a release build would have an identical
> >>> > > environment to that used to build the snapshots.
> >>> > >
> >>> > > Richard.
> >>> > >
> >>> > >
> >>> > > On 14 November 2017 at 15:43, Thomas Bouron
> >>> >  >>> > > om
> >>> > > > wrote:
> >>> > >
> >>> > > > Hi Brooklyners!
> >>> > > >
> >>> > > > Few months ago, I pushed a PR[1] to simplify `brooklyn-vagrant`
> by
> >>> > using
> >>> > > > the RPM package. This is still on hold because we don't build RPM
> >>> > package
> >>> > > > of SNAPSHOT versions and therefore, our vagrant install script
> >>> won't
> >>> > work
> >>> > > > for bleeding edge versions.
> >>> > > > For the record, RPM are not built on SNAPSHOT because INFRA does
> >>> not
> >>> > > offer
> >>> > > > centos/RHEL machines as Jenkins slaves.
> >>> > > >
> >>> > > > But that is coming to an end. INFRA did install (recently-ish)
> >>> docker
> >>> > on
> >>> > > > all Jenkins slaves which means that a new world is opened to us!
> >>> In the
> >>> > > > past weeks, I have created a clone[2] of the
> >>> `brooklyn-dist-master`[3]
> >>> > > job
> >>> > > > and configured it to use a custom docker image I created[4]. It
> is
> >>> > based
> >>> > > on
> >>> > > > `maven:alpine` and adds `rpm` and `dpkg` binaries (for the `dist`
> >>> tag).
> >>> > > > As my test was successful, I decided to go a little further by
> >>> > creating 2
> >>> > > > other tags for this image:
> >>> > > > - `client, based on `maven:alpine` with the `go` binary
> >>> > > > - `latest` which is the combination of the last 2.
> >>> > > >
> >>> > > > My plan is to migrate all jenkins jobs to use docker. I'll donate
> >>> the
> >>> > > > `Dockerfile` to each git repo so that jenkins will be able to
> >>> build and
> >>> > > > publish them on docker hub instead of using my account/image.
> Once
> >>> we
> >>> > > have
> >>> > > > everything dockerised, we can look at improving current builds,
> >>> like
> >>> > > using
> >>> > > > jenkins pipelines rather than relying on upstream<->downstream
> >>> > projects'
> >>> > > > relationships.
> >>> > > >
> >>> > > > It also makes the integration/live tests rise from the ashes.
> This
> >>> is
> >>> > the
> >>> > > > perfect opportunity to fix and make then part of our CI.
> >>> > > >
> >>> > > > WDYT? Even if it's obvious, the main advantage here is the
> >>> portability
> >>> > of
> >>> > > > the build environment. It also means that we can use any jenkins
> >>> > slaves,
> >>> > > > potentially saving us a lot of time when waiting for a build
> >>> executor.
> >>> > > >
> >>> > > > Best.
> >>> > > >
> >>> > > > [1] https://github.com/apache/brooklyn-dist/pull/105
> >>> > > > [2]
> >>> > > > https://builds.apache.org/view/B/view/Brooklyn/job/
> >>> > > > brooklyn-dist-master-docker/
> >>> > > > [3] https://builds.apache.org/view/B/view/Brooklyn/job/
> >>> > > > brooklyn-dist-master/
> >>> > > > [4] https://hub.docker.com/r/tbouron/brooklyn-build/
> >>> > > > --
> >>> > > >
> >>> > > > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation
> •
> >>> > > > https://cloudsoft.io/
> >>> > > > Github: https://github.com/tbouron
> >>> > > > Twitter: https://twitter.com/eltibouron
> >>> > > >
> >>> > >
> >>> >
> >>>
> >> --
> >>
> >> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> >> https://cloudsoft.io/
> >> Github: https://github.com/tbouron
> >> Twitter: https://twitter.com/eltibouron
> >>
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
> --
>
> 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.
>

Re: [VOTE] New Angular UI for Brooklyn

[Richard Downer]

+1 (binding)

Having seen this UI in action I'd be very happy for it to land into
Brooklyn. It's a much more modern-looking, aesthetically-pleasing UI with
much more extensibility, but at it's core the UI works very similar to the
old one, so there's very little learning curve for a user moving from the
old UI to the new.

Richard.


On Mon, 23 Jul 2018 at 10:07, Alex Heneveld 
wrote:

>
> Hi Brooklyners-
>
> This is a vote on whether to accept the brooklyn-ui-angular contribution
> at [1] once IP clearance is completed.
>
> For background, as previously discussed a new UI based on Angular/JS has
> been offered to the Apache Brooklyn project.  The formal grant has been
> completed and is on file -- thank you Cloudsoft and Fujitsu -- and is
> currently going through IP Clearance (see prior email to this list) and
> barring obstacles we may have that clearance after 72 hours.  The vote
> to accept can occur in parallel with the clearance so that is what we
> are doing.
>
> We propose for the code to be added iniitially to a `new/` subdirectory
> in the `brooklyn-ui` repo, once IP clearance is completed and if this
> vote is successful.  We will then create a set of PRs to replace the
> contents at the root with the contents under `new/` and make changes
> elsewhere as needed for the project to build, run, and be documented
> cleanly.  It is proposed that those PRs be reviewed in the usual way (no
> further votes) unless anyone thinks otherwise.
>
> This vote will run for 72 hours.
>
> Best
> Alex
>
> [1]  https://issues.apache.org/jira/browse/INCUBATOR-214
>
>
> On 20/07/2018 16:14, Alex Heneveld wrote:
> >
> > Hi All-
> >
> > The codebase for the UI is staged for review here:
> >
> > https://github.com/ahgittin/brooklyn-ui/tree/new-ui-for-review/new
> >
> > We have created the ip-clearance record [1] to track steps and the
> > legal grant is in process (as per [2]).  We will call for an [IP
> > CLEARANCE] at general@incubator once those are completed, and then we
> > will look for a vote here.  If you have any comments on the code or on
> > the process in the meantime please let me know.
> >
> > Best
> > Alex
> >
> > [1]
> >
> http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup
> >
> > [2]
> >
> https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling
> >
> >
> > On 28/05/2018 12:46, Alex Heneveld wrote:
> >>
> >> Dear Brooklyners,
> >>
> >> Our users at Fujitsu, UShareSoft, and Cloudsoft have generously
> >> sponsored the contribution of a new UI for Apache Brooklyn. This is
> >> based on the previously-proprietary Cloudsoft AMP UI, for those of
> >> you familiar with that.
> >>
> >> The proposed newly contributed UI has all the functionality of the
> >> existing UI including an inspector, groovy console, and online REST
> >> docs.  It is much more recent (angular, webpack), modular, easy to
> >> develop against, and lovely to look at, and so would be a great
> >> contribution based solely on that.
> >>
> >> But even better, it provides a lot of new features:
> >>
> >> *  A visual blueprint composer:  drag-and-drop elements from the
> >> catalog onto a canvas, with a bi-directional YAML editor
> >>
> >> * More live activity update:  a kilt view for activities, tailing
> >> output from SSH commands
> >>
> >> * A bundle-oriented catalog:  with search, bundle- or type- view,
> >> delete bundles
> >>
> >> * An extensible, skinnable, and reusable modular architecture: embed
> >> angular directives and components from this project in others, build
> >> a branded version of the UI, and/or add your own modules (e.g. to
> >> accompany specific blueprints)
> >>
> >> The last point in particular I think will be very valuable:  it will
> >> allow people to use Brooklyn in many more good ways!  There are plans
> >> to make the Composer embeddable and able to work with other input
> >> libraries (think e.g. of pointing it at a Docker repo or an image
> >> catalog), and with widgets for configuring items, all ultimately
> >> generating Brooklyn blueprints.
> >>
> >> Note that this is proposed to replace the existing UI, and as we have
> >> already deprecated the non-OSGi build, it is proposed to make this
> >> compatible only with the OSGi build.
> >>
> >> It is also worth pointing out that the main authors on this UI are
> >> already Brooklyn contributors, so there is enough experience among
> >> active project members to maintain, explain, and extend this.
> >>
> >> Assuming this proposal finds favour, we will open a repo for review
> >> purposes (but it will not be a merged via PR, with the actual
> >> contribution to come via the IP clearance process [1]), followed by
> >> associated PRs in other projects so that everything works seamlessly
> >> (which as minor changes to existing code is more suited to PRs than
> >> the IP clearance process).  Specifically we will:
> >>
> >> * Ensure it builds and runs with the new UI in place of the o

Re: LICENSE file questions - MIT, binary, process

[Richard Downer]

Hi Alex,

Catching up on this email thread. Sorry I'm late and if I cover things that
have already been discussed.

Just as a general note I wrote this page on the Brooklyn website to turn
the generic Apache legal requirements into something tailored for our
Java+Maven+JS project. If during this exercise we discover an error or
omission on that page, let's update it.
https://brooklyn.apache.org/v/latest/dev/code/licensing.html

On Wed, 20 Jun 2018 at 13:47, Alex Heneveld 
wrote:

> In prepping the new UI contribution I've been working on the LICENSE
> file generation.  It is rather extensive because by using Angular we
> pull in hundreds of JS deps for the binary, most of them under MIT
> license which as I understand it means copyright information must be
> reproduced in the LICENSE for the binary dist.  This is based on the MIT
> clause "The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software" in
> accordance with the principle that copyright extends to translations.
> While it would be tempting to treat the compiled/minified version as not
> a copy and so not requiring the copyright -- and that may well be the
> intention of many MIT license users (contrasted with BSD which
> explicitly calls out binaries as requiring the copyright) -- I don't
> believe we can hide behind that.  (So JS devs please take note, please
> use the Apache License! :) )
>
>
> Question 1:  Is this correct, our binaries LICENSE files need to list
> all MIT, BSD, ISC licensed dependencies whose minified/compiled output
> is included in our binary dist?
>

Yes I believe this is correct. Copyright generally follows "is X a
derivative of Y", and if X is the compiler output from source Y then yes it
is a derivative - unless the license makes a distinction it's safest to
assume that the compiled output is subject to the same license as the
source input.

https://www.apache.org/dev/licensing-howto.html contains some relevant
information here. In particular, it clarifies that the license of all
bundled dependencies must be included in LICENSE, and also that "what
applies to canonical source distributions also applies to all
redistributions, including binary redistributions", and that "when
assembling binary distributions, it is common to pull in and bundle
additional dependencies which are not bundled with the source distribution.
These additional dependencies must be accounted for in LICENSE and NOTICE."

In the process I've noticed we in Brooklyn don't currently distinguish
> consistently between the source LICENSE and binary LICENSE.  As I
> understand it from [1], the LICENSE file included with source projects
> -- including I believe the one at the root of the git repo -- should
> refer to resources included in the source only.  Dependencies that are
> downloaded as part of the build and included in the binary should not be
> listed in those LICENSE files, but they must be included in any binary
> build (eg the RPM, TGZ).
>

Yes this is true. Generally the ready-to-run binaries bundle a lot more
stuff then the source archives so have a much bigger LICENSE. Just to make
life even more interesting, sometimes things in the source distribution
disappear during compilation and don't appear in the binary! I believe that
this is the case for Google Auto Value - it's annotations are compile-time
only so don't appear in the JAR file, Auto Value does all its work during
the build, and nothing of Auto Value itself appears in the compilation
output.



> It's not yet a big issue as it doesn't matter for Apache licensed
> dependencies as they do not require copyright inclusion or attribution
> and these are the bulk of what we do.  Where we do need to look more
> closely I think are:
>
[...]

> Question 2:  Does the above sound right?
>

Good catch on these. Yes they sound like there's some attention needed
there.

Finally one more question -- it's easy to tweak the process to include
> Apache-licensed dependencies used in the binary.  While this isn't
> legally required AFAIK it seems like a nice thing to do.
>
> Question 3:  Is everyone okay with giving a shout-out to Apache-licensed
> deps in addition to MIT, BSD, etc, within our binary LICENSE ?
>

I don't know of any reason why not. We're all one big happy family here,
seems inappropriate to give big shouts to external dependencies but not to
our fellow ASF projects, without which we would not be here!

Thanks for looking into this Alex. License compliance is an ugly task. The
PMC owes you a beer :-)

Richard.

Re: WARN: invalid asfext:pmc 'https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees/brooklyn.rdf' in https://git-wip-us.apache.org/repos/asf?p=brooklyn.git;a=blob_plain;f=doap_Br

[Richard Downer]

Sebb,

Thanks for bringing this to our attention. I've submitted a PR to make this
change, I expect it will be merged quickly!
https://github.com/apache/brooklyn/pull/14

Richard.


On Mon, 30 Apr 2018 at 12:45, sebb  wrote:

> Please don't use URLs for the default committee RDF files.
> Only use an URL if the RDF is maintained by the Brooklyn project itself.
>
> The line should read:
>
> http://brooklyn.apache.org"; />
>
> Thanks.
>
> -- Forwarded message --
> From: Projects 
> Date: 30 April 2018 at 03:00
> Subject: WARN: invalid asfext:pmc
> '
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees/brooklyn.rdf
> '
> in
> https://git-wip-us.apache.org/repos/asf?p=brooklyn.git;a=blob_plain;f=doap_Brooklyn.rdf;hb=HEAD
> To: Site Development 
>
>
> WARN: invalid asfext:pmc
> '
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees/brooklyn.rdf
> '
> in
> https://git-wip-us.apache.org/repos/asf?p=brooklyn.git;a=blob_plain;f=doap_Brooklyn.rdf;hb=HEAD
>

Re: [DISCUSSION] Kubernetes Helm

[Richard Downer]

Firstly I'd like to make it clear that I *do* appreciate the work that
Andrea has done here! I never want to turn down a good contribution, and
this is a good contribution, so I'm very reluctant but have to agree with
Thomas that the Helm PRs should be reverted (as I'm sure that Thomas was
very reluctant to revert them). Please don't be put off!

As the Apacheites say frequently, "patches welcome" :-)

As we know, the existing Helm contribution has some issues which prevents
in being in master and in any releases. But if the contribution can have
these issues resolved, then it can be merged. I would say that if it works
in our Karaf build (since the classic build is now obsolete) without
requiring platform-specific downloads, then it can be merged without much
issue.

If it's *not* possible to avoid the platform-specific downloads - then it's
still not the end of the road, but the contribution needs to address this
problem and make it workable for the whole project. Personally I'd be
reluctant to accept any proposal which removed our platform-independent
binary releases, unless a significant number of *users* came and told us
that it's what they want. Perhaps the main Apache Brooklyn build excludes
Helm, but there's a small, optional, drop-in pack of platform-specific code
that is an official Brooklyn release artifact. However, the effort around
process, documentation and website updates needed to support multi-platform
releases is not small, and I'd much rather that effort was directed into
creating a pure-Java solution.

But, I know nothing about Kubernetes Helm, and not very much about this
specific problem, so ignore me if I am barking up the wrong tree :-)

Remember we do already have a platform-specific component in Brooklyn - the
`br` CLI. It's optional, simple to package the different platforms, and
simple to install separately, so adding it was a relatively low-friction
change to our processes. If Helm can be supported in the same way then I'd
be quite happy.

It's up to the contributor, Andrea - and anyone else here who is interested
in the work and wants to work with Andrea - to decide where to go from
here. In it's present form, we can't merge it. It is up to contributors to
decide if they want to change the contribution to make it suitable, or to
maintain it out-of-tree for a while. Or drop it, but I really hope that
doesn't happen (see first paragraph).

Richard.


On 18 April 2018 at 19:56, Geoff Macartney 
wrote:

> hi all,
>
> just to check what is the resolution on this, is the k8s-helm location
> going to be left out of Brooklyn, and done in a community repo?
>
> regards
> Geoff
>
>
>
> On Tue, 17 Apr 2018 at 14:03 Andrea Turli  wrote:
>
> > Thomas,
> >
> > thanks for taking care of this.
> >
> > Geomacy,
> >
> > I've built brooklyn-{server,dist} on OSX and ran it from CentOS 7 and it
> > works fine as I think `os-maven-plugin` is doing the right incantation
> >
> > Richard,
> >
> > I think helm is a well appreciated tool for kubernetes ecoystem.
> >
> > I think I can donate my work as community-supported addon although it is
> > designed as a Brooklyn location not a simple application blueprint, but
> > worth noticing that it was not part of the core but was committed in
> > `brooklyn-server/locations/container` module, which seems a perfect
> match
> > to me,
> > I undestand the helm location works with the classic launcher, but there
> is
> > an extra complexity to OSGify grpc (a transitive dependency of
> > microbean-helm) to make it work with brooklyn-karaf.
> >
> > I may resubmit the contribution without bringing in the microbean-helm
> java
> > client but writing a simpler restful client for Helm/Tiller, but not sure
> > how hard it would be to refactor the location yet.
> >
> > Best,
> > Andrea
> >
> >
> >
> > On Tue, 17 Apr 2018 at 11:50 Richard Downer  wrote:
> >
> > > All,
> > >
> > > I'm sorry but I'm not really aware of the Kubernetes ecosystem in much
> > > detail. Do we have an indication of how much demand there is for Helm
> > > support in Brooklyn?
> > >
> > > This sounds like a significant change - both to our build process, but
> > also
> > > our release process and website (supporting multiple platform
> downloads).
> > > I'd be opposed to doing it unless there's a significant demand for
> Helm.
> > > I'd prefer to see this as a community-supported addon (like most of our
> > > blueprints are) instead of being core Brooklyn, until there's evidence
> of
> > > demand for this t

Re: [DISCUSSION] Kubernetes Helm

[Richard Downer]

All,

I'm sorry but I'm not really aware of the Kubernetes ecosystem in much
detail. Do we have an indication of how much demand there is for Helm
support in Brooklyn?

This sounds like a significant change - both to our build process, but also
our release process and website (supporting multiple platform downloads).
I'd be opposed to doing it unless there's a significant demand for Helm.
I'd prefer to see this as a community-supported addon (like most of our
blueprints are) instead of being core Brooklyn, until there's evidence of
demand for this to be in core.

Richard.



On 17 April 2018 at 09:07, Geoff Macartney 
wrote:

> hi Thomas
>
> It certainly doesn't sound right to have to have separate builds of
> Brooklyn for different platforms, and especially not just for this
> feature.  Can we build the dependency package into a bundle for each
> platform, so that it is the only thing that is platform specific, and
> provide all three bundles along with the distribution of Brooklyn? Then on
> whatever target platform you are on, OSX, Linux, Windows, you install the
> right dependency bundle for that platform into Brooklyn's Karaf?
>
> Geoff
>
>
>
> On Mon, 16 Apr 2018 at 12:18 Thomas Bouron  com>
> wrote:
>
> > Hi Brooklyners.
> >
> > You might have noticed that the Brooklyn builds started to fail more than
> > usual recently. I spent some time last week to fix those issues but I
> just
> > realised that there is a deeper one with the recent change I merged
> (about
> > Kubernetes Helm)
> >
> > This change requires a dependency, which depends on some native code.
> Now,
> > this dependency exists for 3 platforms: macOS, Linux and Window. The
> issue
> > is that the "right" dependency is included at build time via the maven
> > classifier, and the way it is picked is by looking at the current build
> OS
> > and selecting the corresponding one[1]. Obviously, this leads to nasty
> > problem: as all our builds are done on Linux, Brooklyn artifacts only
> work
> > on Linux. Not only that, the classifier is dynamically picked and set as
> > envvar by a plugin. This is also an issue for any downstream projects.
> >
> > While we want this feature in Brooklyn, I don't think this is acceptable
> > for our users therefore I reverted the changes and started this
> > conversation. What do you think would be the best approach to fix this?
> > Having 1 build per platform doesn't sound good as it won't be portable
> > anymore. Maybe we can find another dependency without a link to native
> > code?
> >
> > Best.
> >
> > [1]
> >
> > https://github.com/apache/brooklyn-dist/pull/119/files#diff-
> 01b5eceed5fb6499e99a42e711695648R139
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>

Re: Build failed in Jenkins: brooklyn-master-build-docker #344

[Richard Downer]

Joel,

To unsubscribe, send a blank email to: dev-unsubscr...@brooklyn.apache.org

If you're having trouble unsubscribing, you can email
dev-ow...@brooklyn.apache.org which will reach a human who can assist you.

Richard.


On 10 April 2018 at 11:10, Joel Gil León  wrote:

> unsubscribe
>
> On Tue, Apr 10, 2018 at 12:22 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See <
> > https://builds.apache.org/job/brooklyn-master-build-docker/
> 344/display/redirect
> > >
> >
> > --
> > [...truncated 7.26 MB...]
> > at
> > org.apache.brooklyn.core.test.entity.LocalManagementContextForTests
> .(LocalManagementContextForTests.java:45)
> > at
> > org.apache.brooklyn.core.test.entity.LocalManagementContextForTests
> $Builder.build(LocalManagementContextForTests.java:185)
> > at
> > org.apache.brooklyn.camp.brooklyn.AbstractYamlTest.
> newTestManagementContext(AbstractYamlTest.java:117)
> > at
> > org.apache.brooklyn.camp.brooklyn.AbstractYamlTest$1.newMgmtContext(
> AbstractYamlTest.java:103)
> > at
> > org.apache.brooklyn.camp.brooklyn.BrooklynCampPlatformLauncherAb
> stract.launch(BrooklynCampPlatformLauncherAbstract.java:48)
> > at
> > org.apache.brooklyn.camp.brooklyn.AbstractYamlTest.setUpPlatform(
> AbstractYamlTest.java:106)
> > at
> > org.apache.brooklyn.camp.brooklyn.AbstractYamlTest.
> setUp(AbstractYamlTest.java:95)
> > at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> > org.testng.internal.MethodInvocationHelper.invokeMethod(
> MethodInvocationHelper.java:104)
> > at
> > org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:515)
> > at
> > org.testng.internal.Invoker.invokeConfigurations(Invoker.java:217)
> > at org.testng.internal.Invoker.invokeMethod(Invoker.java:590)
> > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:
> 851)
> > at org.testng.internal.Invoker.invokeTestMethods(Invoker.
> java:1177)
> > at
> > org.testng.internal.TestMethodWorker.invokeTestMethods(
> TestMethodWorker.java:129)
> > at
> > org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
> > at org.testng.TestRunner.privateRun(TestRunner.java:756)
> > at org.testng.TestRunner.run(TestRunner.java:610)
> > at org.testng.SuiteRunner.runTest(SuiteRunner.java:387)
> > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:382)
> > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:340)
> > at org.testng.SuiteRunner.run(SuiteRunner.java:289)
> > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.
> java:52)
> > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1293)
> > at org.testng.TestNG.runSuitesLocally(TestNG.java:1218)
> > at org.testng.TestNG.runSuites(TestNG.java:1133)
> > at org.testng.TestNG.run(TestNG.java:1104)
> > at
> > org.apache.maven.surefire.testng.TestNGExecutor.run(
> TestNGExecutor.java:132)
> > at
> > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(
> TestNGDirectoryTestSuite.java:193)
> > at
> > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(
> TestNGDirectoryTestSuite.java:94)
> > at
> > org.apache.maven.surefire.testng.TestNGProvider.invoke(
> TestNGProvider.java:147)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.
> invokeProviderInSameClassLoader(ForkedBooter.java:290)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
> ForkedBooter.java:242)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.main(
> ForkedBooter.java:121)
> >
> > 2018-04-10 09:21:39,388 WARN  - Management Context
> > LocalManagementContext[?-WoqhFMe5] running, creation stacktrace:
> > java.lang.Throwable: for construction stacktrace
> > at
> > org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(
> LocalManagementContext.java:141)
> > at
> > org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(
> LocalManagementContext.java:163)
> > at
> > org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(
> LocalManagementContext.java:159)
> > at
> > org.apache.brooklyn.core.test.entity.LocalManagementContextForTests
> .(LocalManagementContextForTests.java:45)
> > at
> > org.apache.brooklyn.core.test.entity.LocalManagementContextForTests
> $Builder.build(LocalManagementContextForTests.java:185)
> > at
> > org.apache.brooklyn.camp.brooklyn.AbstractYamlTest.
> newTestManagementContext(AbstractYamlTest.java:117)
> > at
> > org.apache.brooklyn.

Re: Making First Contact

[Richard Downer]

All,

I think that we - the incumbent development community - should be prepared
to be stretched and challenged by new contributions! I would love to see
something that shows that things can be done *differently* to the way we've
always done it - after all, it *might* be better :-)

Maintainability by the community as a whole is obviously a key concern, but
all these modern JS frameworks are learnable!

Richard.


On 23 March 2018 at 14:31, John McCabe  wrote:

> Agree on the experience in the community feeding into weighing up the
> framework choice - it shouldn't rule anything out, but is a very important
> factor.
>
> The pro's/con's of each are still extremely value to explore, perhaps even
> have a look at vue.js while comparing.
>
> On Wed, 21 Mar 2018 at 21:18 Geoff Macartney  >
> wrote:
>
> > hi all,
> >
> > Something to consider is not just the technology but the community.  I
> have
> > an idea that there are more people in the Apache Brooklyn community who
> > have experience with Angular than with React (in fact I don't know anyone
> > in the community who knows React).  It might mean that it would be easier
> > to find people to maintain and further develop a new UI if it were done
> in
> > Angular.
> >
> > Brooklyners, what do you all think?  Has anyone a view on the best choice
> > of framework, for people or technological reasons? My thought is that,
> > while both frameworks have their cheerleaders, in the end of the day they
> > are probably broadly equivalent in terms of capability, and it may be
> best
> > to pick the path that will maximise the opportunity for people to
> > contribute.
> >
> > regards
> > Geoff
> >
> >
> >
> > On Wed, 21 Mar 2018 at 20:55 Mert Kahyaoğlu 
> wrote:
> >
> > > Hi Thomas,
> > >
> > > Yes, I'm working full-time for a startup called iyzico. I'm planning to
> > > spare 2-3 hours after work for at least 4 week days and 6-8 hours at
> > > weekends each day. I'm not going to vacation during GSoC period. As I
> > said,
> > > my priority will be GSoC. There should be no doubt for that. According
> to
> > > my estimation, I might be able to complete the project a couple of
> weeks
> > > before the deadline. I was a bit generous while estimating time in the
> > > proposal.
> > >
> > > Regarding the technology side, React is around for 3 years which makes
> > it a
> > > lot stable while Angular just started to be stable with version 5.
> Before
> > > that switching between versions was very hard. A few months ago,
> Facebook
> > > React team released React Fiber
> > >  (v16.0) which
> is a
> > > reimplementation of React's core algorithm. This made React much faster
> > and
> > > much more responsive than ever. Also this release opened up new
> concepts
> > > like Async Rendering 
> which
> > > makes it game-changing.
> > >
> > > I believe React is currently the most stable and fresh framework out
> > there
> > > and won't become old for a long time. These are my thoughts, of course.
> > I'm
> > > not a fanboy of any framework. I always love trying out new
> technologies.
> > > If the community thinks Angular 5 is the best fit for Brooklyn UI, I
> > > definitely go for it and give it a shot.
> > >
> > > Best,
> > > Mert
> > >
> > > 2018-03-21 21:01 GMT+03:00 Thomas Bouron <
> > thomas.bou...@cloudsoftcorp.com
> > > >:
> > >
> > > > Hi Mert.
> > > >
> > > > I saw that your proposal is in the final stage in GSoC website,
> that's
> > > > great. I wanted to ask you more questions but hadn't had the time
> > before
> > > > now, apologies to that. I'm going to ask you here then.
> > > >
> > > > Regarding other commitments, you said that you are currently working
> > > > full-time for a web agency, is that correct? How do you plan to make
> > this
> > > > work with GSoC? Do you have a rough idea how much time and effort you
> > > will
> > > > put in this project? Have you any vacation planned?
> > > >
> > > > Regarding the technology side of things, you said that you choose
> React
> > > > mostly because that's what you know, is that a fair statement? React
> is
> > > > almost 3 years old now. Angular 5 seems to be the new cool kid out
> > there,
> > > > how does it compare to it? What are you thoughts on that? Is it worth
> > > going
> > > > for an "old" (old as in the JavaScript world) technology?
> > > >
> > > > Best
> > > >
> > > > On Sat, 10 Mar 2018, 10:44 Mert Kahyaoğlu, 
> > wrote:
> > > >
> > > > > Absolutely right. We should really think about user experience when
> > > > > rewriting the UI. In my demo app, I followed the same UI guide with
> > the
> > > > > current one but the real application won't have the same
> > > characteristics.
> > > > > We should think over how we can make users life easier than before
> > and
> > > > > implement the new UI accordingly.
> > > > >
> > > > > 2018-03-10 0:12 GMT+03:00 Geoff Macartney <
> > > geoff.macart...@cloudsoft.io>
> > > 

Re: Failing Go build: NodePrime/jsonpath missing?

[Richard Downer]

Oh no it's left-pad[1] all over again! 😆


[1] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

On 22 March 2018 at 10:40, Aled Sage  wrote:

> Hi all,
>
> The Apache Brooklyn master build [1] has failed the last couple of times
> for the Go build of brooklyn-client (see end of email for the error text).
>
> It looks to me like our dependency github.com/NodePrime/jsonpath has been
> deleted! It definitely used to be there (lots of google hits pointing at
> that [2]), but 404 when visiting the page.
>
> The build presumably only works for me locally because I have it cached
> locally:
>
>[exec] [INFO]  Downloading dependencies. Please wait...
>[exec] [INFO]  --> Found desired version locally
>github.com/NodePrime/jsonpath 84403ded544328c99be3472727667179eef23a91!
>
> Can someone else please double-check my findings?
>
> I couldn't find any record of jsonpath having moved. Anyone have any
> opinions how best to fix this?
>
> ---
> The error shown in jenkins console is:
>
>all:
>  [exec] Starting build.sh (brooklyn-client go build script)
>  [exec] Installing glide
>  [exec] Installing dependencies
>  [exec] [WARN]The name listed in the config file
>(github.com/apache/brooklyn-client) does not match the current
>location (.)
>  [exec] [INFO]Downloading dependencies. Please wait...
>  [exec] [INFO]--> Fetching golang.org/x/crypto
>  [exec] [INFO]--> Fetching github.com/NodePrime/jsonpath
>  [exec] [INFO]--> Fetching github.com/urfave/cli
>  [exec] [WARN]Unable to checkout github.com/NodePrime/jsonpath
>  [exec] [ERROR]Update failed for
>github.com/NodePrime/jsonpath: Unable to get repository: Cloning
>into '/root/.glide/cache/src/https-github.com-NodePrime-jsonpath'...
>  [exec] fatal: could not read Username for
>'https://github.com': No such device or address
>  [exec] : exit status 128
>  [exec] [ERROR]Failed to install: Unable to get repository:
>Cloning into
>'/root/.glide/cache/src/https-github.com-NodePrime-jsonpath'...
>  [exec] fatal: could not read Username for
>'https://github.com': No such device or address
>  [exec] : exit status 128
>  [exec] Building br for default OS/ARCH:
>  [exec] darwin/amd64
>  [exec] ../models/catalog.go:28:2: cannot find package
>"github.com/NodePrime/jsonpath" in any of:
>  [exec]
>/usr/build/brooklyn-client/cli/target/src/github.com/apache
> /brooklyn-client/cli/vendor/github.com/NodePrime/jsonpath
>(vendor tree)
>  [exec] /usr/lib/go-1.7/src/github.com/NodePrime/jsonpath (from
>$GOROOT)
>  [exec]
>/usr/build/brooklyn-client/cli/target/src/github.com/NodePrime/jsonpath
>(from $GOPATH)
>  [exec] ../command_metadata/command_metadata.go:21:8: cannot
>find package "github.com/urfave/cli" in any of:
>  [exec]
>/usr/build/brooklyn-client/cli/target/src/github.com/apache
> /brooklyn-client/cli/vendor/github.com/urfave/cli
>(vendor tree)
>  [exec] /usr/lib/go-1.7/src/github.com/urfave/cli (from
>$GOROOT)
>  [exec]
>/usr/build/brooklyn-client/cli/target/src/github.com/urfave/cli
>(from $GOPATH)
>  [exec] ../commands/login.go:37:2: cannot find package
>"golang.org/x/crypto/ssh/terminal" in any of:
>  [exec]
>/usr/build/brooklyn-client/cli/target/src/github.com/apache
> /brooklyn-client/cli/vendor/golang.org/x/crypto/ssh/terminal
>(vendor tree)
>  [exec] /usr/lib/go-1.7/src/golang.org/x/crypto/ssh/terminal
>(from $GOROOT)
>  [exec]
>/usr/build/brooklyn-client/cli/target/src/golang.org/x/cryp
> to/ssh/terminal
>(from $GOPATH)
>
> Aled
>
> [1] https://builds.apache.org/job/brooklyn-master-build-docker/
> [2] https://github.com/NodePrime/jsonpath
>
>

Re: Get access to Docker Hub

[Richard Downer]

Thanks for arranging this Andrea. Please add me as well:

rdowner at Docker Hub
richard at ASF

Richard.


On 21 March 2018 at 09:04, Andrea Turli  wrote:

> hi team,
>
> thinking about this comment from duncangrant [1]  I think we could ask ASF
> infra to get access to apache docker hub organization and start pushing
> docker images for brooklyn to `apache/brooklyn`.
>
> Searching for other ASF projects [2] seems pretty common to ask ASF infra
> to grant access to dockerhub id and apache id of whoever among committers
> are interested.
>
> Here's the draft body of the ticket
>
> 
> Hi there,
>
> The `brookly-dist` project plans to use com.spotify:dockerfile-maven-
> plugin
> to build, tag and push images to DockerHub.
> We'd like to start using 'apache/brooklyn' to host Brooklyn's Docker
> images.
> We think the builder.apache.org will need access to `apache` Docker Hub
> organization to upload images generated
>
> The following Docker Hub users will also need access to that Docker Hub
> organization to maintain those images, along with the description page for
> the image itself:
>
> Docker Hub ID  ASF committer ID
>
> andreaturliandreaturli
>
> ---
>
> Feel free to add your details here so we can issue a similar ticket to ASF
> infra,
> Andrea
>
>
> [1]:
> https://github.com/apache/brooklyn-dist/pull/118#
> pullrequestreview-105439038
> [2]:
> https://issues.apache.org/jira/browse/FLINK-8259?jql=
> text%20~%20%22dockerhub%22
>

[jira] [Updated] (BROOKLYN-577) GSoC: Modernise Brooklyn's authentication system

[Richard Downer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-577:

Description: 
This is an idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC). Potential students, please 
read https://brooklyn.apache.org/community/gsoc.html

Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon EC2. 
In more detail, it's a tool for describing applications and their components, 
deploying these applications to the cloud, and managing the ongoing health and 
responsiveness. Brooklyn does this using blueprints - human readable documents 
which describe in detail an application component, or a whole application. 
Blueprints are stored in a catalog, essentially a built-in database of 
components and applications. An application blueprint can call on component 
blueprints from the catalog, therefore allowing complex applications to be 
built from simple pieces.

Apache Brooklyn currently uses a simple authentication/authorisation system. 
Runtime authentication relies on HTTP Basic Authentication. While this has been 
satisfactory for some time, it has many shortcomings. HTTP Basic Authentication 
caches credentials on the client side, which is a weakness. It's not possible 
for a server policy to enforce session expiry timeouts. Even trivial things 
such as providing a "logout" button are difficult to reliably implement. This 
makes enterprise adoption of Brooklyn problematic as it cannot comply with the 
security policy requirements that enterprises typically have.

Apache Brooklyn's authorisation systems on the server side are basic. Usernames 
and passwords can be put into the server configuration by an administrator. 
This means that users do not have the ability to change their own password, and 
enterprise security policies such as password rotation cannot be supported. (As 
an alternative, Brooklyn can integrate with external directory services, but it 
is often overkill to deploy a heavy directory server alongside a Brooklyn 
server.)

This project would be to overhaul Apache Brooklyn's login system to a modern 
system. Considerations include:
 * A built-in user directory that is easy to get started with yet which guides 
the administrator towards a secure system
 * Credentials stored in a secure manner
 * A login screen in the UI, and the appropriate API methods to log in and 
issue tokens
 * Revise the server side API code to validate tokens
 * UI and API support for logging out, changing password, other appropriate 
operations
 * UI and API support for an administrator to manage users
 * Security policy features such as:
 ** Logged in sessions expire after a fixed time
 ** User must change their password on first login
 ** User passwords expire after a fixed time and must be changed
 ** Lock out accounts after a number of failed logins
 ** Audit log
 * Retain ability to integrate with an external directory service

This project will involve the use of Java for the server-side development (this 
is where most of the work will take place), and HTML+CSS+Javascript for the 
client-side development (this is less important as we expect others will be 
on-hand to help with the visual development). It will require study and 
implementation of "best practices" for security.

  was:
This is an idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon EC2. 
In more detail, it's a tool for describing applications and their components, 
deploying these applications to the cloud, and managing the ongoing health and 
responsiveness. Brooklyn does this using blueprints - human readable documents 
which describe in detail an application component, or a whole application. 
Blueprints are stored in a catalog, essentially a built-in database of 
components and applications. An application blueprint can call on component 
blueprints from the catalog, therefore allowing complex applications to be 
built from simple pieces.

Apache Brooklyn currently uses a simple authentication/authorisation system. 
Runtime authentication relies on HTTP Basic Authentication. While this has been 
satisfactory for some time, it has many shortcomings. HTTP Basic Authentication 
caches credentials on the client side, which is a weakness. It's not possible 
for a server policy to enforce session expiry timeouts. Even trivial things 
such as providing a "logout" button are difficult to reliably implement. This 
makes enterprise adoption of Brooklyn problematic as it cannot comply with the 
security policy requirements that enterprises typically have.

Apache Brooklyn's authorisation systems on the server side are basic. Usernames 
and passwords can be put into the server configuration by

[jira] [Commented] (BROOKLYN-577) GSoC: Modernise Brooklyn's authentication system

[Richard Downer (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365356#comment-16365356
 ] 

Richard Downer commented on BROOKLYN-577:
-

Information on the Brooklyn mailing lists can be found at 
https://brooklyn.apache.org/community/mailing-lists.html.

I note that your comment was marked as "Restricted to jira-users" which meant 
it cannot be seen by anyone not logged into Jira. Please avoid restricting Jira 
content, we prefer to keep all but the most sensitive material open to all.

> GSoC: Modernise Brooklyn's authentication system
> 
>
> Key: BROOKLYN-577
> URL: https://issues.apache.org/jira/browse/BROOKLYN-577
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Richard Downer
>Priority: Major
>  Labels: cloud, gsoc2018, java, javascript, rest
>
> This is an idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon 
> EC2. In more detail, it's a tool for describing applications and their 
> components, deploying these applications to the cloud, and managing the 
> ongoing health and responsiveness. Brooklyn does this using blueprints - 
> human readable documents which describe in detail an application component, 
> or a whole application. Blueprints are stored in a catalog, essentially a 
> built-in database of components and applications. An application blueprint 
> can call on component blueprints from the catalog, therefore allowing complex 
> applications to be built from simple pieces.
> Apache Brooklyn currently uses a simple authentication/authorisation system. 
> Runtime authentication relies on HTTP Basic Authentication. While this has 
> been satisfactory for some time, it has many shortcomings. HTTP Basic 
> Authentication caches credentials on the client side, which is a weakness. 
> It's not possible for a server policy to enforce session expiry timeouts. 
> Even trivial things such as providing a "logout" button are difficult to 
> reliably implement. This makes enterprise adoption of Brooklyn problematic as 
> it cannot comply with the security policy requirements that enterprises 
> typically have.
> Apache Brooklyn's authorisation systems on the server side are basic. 
> Usernames and passwords can be put into the server configuration by an 
> administrator. This means that users do not have the ability to change their 
> own password, and enterprise security policies such as password rotation 
> cannot be supported. (As an alternative, Brooklyn can integrate with external 
> directory services, but it is often overkill to deploy a heavy directory 
> server alongside a Brooklyn server.)
> This project would be to overhaul Apache Brooklyn's login system to a modern 
> system. Considerations include:
>  * A built-in user directory that is easy to get started with yet which 
> guides the administrator towards a secure system
>  * Credentials stored in a secure manner
>  * A login screen in the UI, and the appropriate API methods to log in and 
> issue tokens
>  * Revise the server side API code to validate tokens
>  * UI and API support for logging out, changing password, other appropriate 
> operations
>  * UI and API support for an administrator to manage users
>  * Security policy features such as:
>  ** Logged in sessions expire after a fixed time
>  ** User must change their password on first login
>  ** User passwords expire after a fixed time and must be changed
>  ** Lock out accounts after a number of failed logins
>  ** Audit log
>  * Retain ability to integrate with an external directory service
> This project will involve the use of Java for the server-side development 
> (this is where most of the work will take place), and HTML+CSS+Javascript for 
> the client-side development (this is less important as we expect others will 
> be on-hand to help with the visual development). It will require study and 
> implementation of "best practices" for security.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

ApacheCon North America in Montreal, Canada, September 24-28

[Richard Downer]

Hello Apache Brooklyn community!

An announcement from Apache's VP Conferences, Rich Bowen, about this year's
ApacheCon:

---

As you may have seen on the Apache blog -
https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces28
- we will be holding ApacheCon North America in Montreal, Canada, September
24-28, at the Marriott.

More details will be coming as fast as we have them, but you can get
started at http://apachecon.com/ and by following us on @ApacheCon on
Twitter.

Also, note that the CFP is already open. Follow the link from
http://apachecon.com/acna18/

---

Separately, it was also announced that the Travel Assistance Committee will
be supporting this event and are open for applications:

---

The Travel Assistance Committee (TAC) are pleased to announce that travel
assistance applications for ApacheCon NA 2018 are now open!

We will be supporting ApacheCon NA Montreal, Canada on 24th - 29th
September 2018

 TAC exists to help those that would like to attend ApacheCon events, but
are unable to do so for financial reasons.
For more info on this years applications and qualifying criteria, please
visit the TAC website at < http://www.apache.org/travel/ >. Applications
are now open and will close 1st May.

Important: Applications close on May 1st, 2018. Applicants have until the
closing date above to submit their applications (which should contain as
much supporting material as required to efficiently and accurately process
their request), this will enable TAC to announce successful awards shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a diverse
range of backgrounds. We therefore encourage (as always) anyone thinking
about sending in an application to do so ASAP.
We look forward to greeting many of you in Montreal

Kind Regards,
Gavin - (On behalf of the Travel Assistance Committee)

---

Is anyone from the Brooklyn community planning to attend this conference?
If so I'd encourage you to submit a proposal for a talk about Brooklyn, in
some shape or form. I and others would certainly support you with material
and content, if helpful.

Richard.

Re: Google Summer of Code 2018

[Richard Downer]

Final call for more ideas for GSoC projects - please post to this thread
TODAY if you have an idea!

Cheers
Richard.


On 23 January 2018 at 10:45, Richard Downer  wrote:

> Hi all,
>
> Apache is gearing up for Google Summer of Code 2018. All Apache projects
> have been invited to submit their ideas for GSoC projects.
>
> For those not familiar with GSoC, the idea is during that students will
> use their summer break to embark on a 3-month programming project with an
> open source organisation.
>
> If we want to take part then we simply need to come up with some suitable
> ideas and open a JIRA ticket with suitable labels. We'll also need mentors
> to work with our students - mentors will need to keep a continuous dialog
> with their student and expect to consume 3-5 hours a week in that role.
>
> **Deadline for this is 30th January - Tuesday next week**
>
> Any ideas for GSoC projects - projects that can be completed in 3 months
> by a student?
>
> Our GUI is somewhat dated - a replacement GUI project?
>
> A project to add support for updating a blueprint of a running application?
>
> Anything else?
>
>
> A bit more information from Ulrich Stärk who is running the Apache side of
> GSoC:
>
> Google Summer of Code [1] is a program sponsored by Google allowing
> students to spend their summer working on open source software. Students
> will receive stipends for developing open source software full-time for
> three months. Projects will provide mentoring and project ideas, and in
> return have the chance to get new code developed and - most importantly -
> to identify and bring in new committers.
>
> The ASF will apply as a participating organization meaning individual
> projects don't have to apply
> separately.
>
> If you want to participate with your project we ask you to do the
> following things as soon as
> possible but please no later than 2017-01-30:
>
> 1. understand what it means to be a mentor [2].
>
> 2. record your project ideas.
>
>
> [1] https://summerofcode.withgoogle.com/
> [2] http://community.apache.org/guide-to-being-a-mentor.html
>

Re: Google Summer of Code 2018

[Richard Downer]

Hi Thomas,

Your proposal for the UI looks good now. Let's give it another day or two
to see if there's more comments, and then I'd be in favour of making it
official and adding the gsoc2018 tag.

About my proposal for the authentication rework - I was actually worried
that the basic task might be too easy, which is why I fleshed out the
requirements in more detail! After all, adding authorisation by token and a
basic user directory should be possible in one month, let alone three.
However I'd imagine that the only essential part is the basic functionality
as long as its designed with the other goals in mind - the rest of it can
be stretch goals, and done after GSoC conclusion if necessary. Are my
expectations realistic or am I on a different planet? :-)

JWT is definitely a suggestion I'd make too, but probably at the stage
where the project kicks off rather than making it a requirement at this
stage.

Cheers
Richard.


On 23 January 2018 at 17:03, Thomas Bouron 
wrote:

> I updated the JIRA with your ideas Richard, available at [1].
>
> Regarding the one you created, I like it very much, that would be great to
> have this! I'm just a bit afraid about the scope, sounds very large. Maybe
> should we try to reduce it by suggesting a particular direction, i.e. JWT?
> I remember Mark talking about this but it never got implemented. WDYT?
>
> Best.
>
> [1] https://issues.apache.org/jira/browse/BROOKLYN-575
>
> On Tue, 23 Jan 2018 at 16:10 Thomas Bouron  com>
> wrote:
>
> > Thanks for the feedback Richard!
> >
> > I like your ideas and it's probably worth indeed. Although, I read the
> > GSoC FAQ and it does says[1]
> >
> > > There is an art to writing a project description that leads to good
> > student applications. It is tempting to write a detailed project plan for
> > the student to follow. However, students tend to echo such plans in their
> > applications, making it difficult to evaluate their quality. It is better
> > to briefly describe a general high-level need, and the motivation behind
> > that need. Keeping the scope modest helps encourage more applicants,
> while
> > adding a “stretch” goal to the project description may encourage stronger
> > students to take on the challenge of meeting it.
> >
> > So I'm not sure we need to go into that length. Maybe something in
> > between? I'll make some amends and get back to you.
> >
> > Best
> >
> > [1]
> > https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
> >
> > On Tue, 23 Jan 2018 at 15:41 Richard Downer  wrote:
> >
> >> This is a great start :-) and thanks for volunteering to mentor, too.
> >>
> >> I'm wondering if we should expand this out with some more introductory
> >> material, and expand a bit more on the skills required? I'm assuming
> that
> >> prospective GSoC students would see only the content of the JIRA, so
> maybe
> >> setting some more context would be appropriate.
> >>
> >> Perhaps open with...
> >>
> >> "Apache Brooklyn is a tool for running stuff in "the cloud", such as
> >> Amazon
> >> EC2. In more detail, it's a tool for describing applications and their
> >> components, deploying these applications to the cloud, and managing the
> >> ongoing health and responsiveness. Brooklyn does this using blueprints -
> >> human readable documents which describe in detail an application
> >> component,
> >> or a whole application. Blueprints are stored in a catalog, essentially
> a
> >> built-in database of components and applications. An application
> blueprint
> >> can call on component blueprints from the catalog, therefore allowing
> >> complex applications to be built from simple pieces."
> >>
> >> I'd maybe also remove the prescribed list of views in favour of
> something
> >> more general. Our student may come up with a radical new idea that we
> had
> >> not considered! Example:
> >>
> >> "The UI should facilitate three main tasks: (1) deploying an
> application;
> >> (2) viewing and managing deployed applications; (3) viewing and managing
> >> the catalog. There may also be further auxiliary tasks that the UI will
> >> need to support, such as a REST API explorer."
> >>
> >> Finally I'd suggest we talk about the skills that the task will require
> -
> >> although we should be careful not to frame these as prerequisites, as it
> >> is
> >> the aim that the student will have to learn something :-)
>

Re: Google Summer of Code 2018

[Richard Downer]

I've added a proposal here:
https://issues.apache.org/jira/browse/BROOKLYN-577

GSoC: Modernise Brooklyn's authentication system

Apache Brooklyn currently uses a simple authentication/authorisation
system. Runtime authentication relies on HTTP Basic Authentication. While
this has been satisfactory for some time, it has many shortcomings. HTTP
Basic Authentication caches credentials on the client side, which is a
weakness. It's not possible for a server policy to enforce session expiry
timeouts. Even trivial things such as providing a "logout" button are
difficult to reliably implement. This makes enterprise adoption of Brooklyn
problematic as it cannot comply with the security policy requirements that
enterprises typically have.

Apache Brooklyn's authorisation systems on the server side are basic.
Usernames and passwords can be put into the server configuration by an
administrator. This means that users do not have the ability to change
their own password, and enterprise security policies such as password
rotation cannot be supported. (As an alternative, Brooklyn can integrate
with external directory services, but it is often overkill to deploy a
heavy directory server alongside a Brooklyn server.)

This project would be to overhaul Apache Brooklyn's login system to a
modern system.

More on the JIRA ticket.


On 23 January 2018 at 10:45, Richard Downer  wrote:

> Hi all,
>
> Apache is gearing up for Google Summer of Code 2018. All Apache projects
> have been invited to submit their ideas for GSoC projects.
>
> For those not familiar with GSoC, the idea is during that students will
> use their summer break to embark on a 3-month programming project with an
> open source organisation.
>
> If we want to take part then we simply need to come up with some suitable
> ideas and open a JIRA ticket with suitable labels. We'll also need mentors
> to work with our students - mentors will need to keep a continuous dialog
> with their student and expect to consume 3-5 hours a week in that role.
>
> **Deadline for this is 30th January - Tuesday next week**
>
> Any ideas for GSoC projects - projects that can be completed in 3 months
> by a student?
>
> Our GUI is somewhat dated - a replacement GUI project?
>
> A project to add support for updating a blueprint of a running application?
>
> Anything else?
>
>
> A bit more information from Ulrich Stärk who is running the Apache side of
> GSoC:
>
> Google Summer of Code [1] is a program sponsored by Google allowing
> students to spend their summer working on open source software. Students
> will receive stipends for developing open source software full-time for
> three months. Projects will provide mentoring and project ideas, and in
> return have the chance to get new code developed and - most importantly -
> to identify and bring in new committers.
>
> The ASF will apply as a participating organization meaning individual
> projects don't have to apply
> separately.
>
> If you want to participate with your project we ask you to do the
> following things as soon as
> possible but please no later than 2017-01-30:
>
> 1. understand what it means to be a mentor [2].
>
> 2. record your project ideas.
>
>
> [1] https://summerofcode.withgoogle.com/
> [2] http://community.apache.org/guide-to-being-a-mentor.html
>

[jira] [Updated] (BROOKLYN-577) Modernise Brooklyn's authentication system

[Richard Downer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-577:

Description: 
This is an idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon EC2. 
In more detail, it's a tool for describing applications and their components, 
deploying these applications to the cloud, and managing the ongoing health and 
responsiveness. Brooklyn does this using blueprints - human readable documents 
which describe in detail an application component, or a whole application. 
Blueprints are stored in a catalog, essentially a built-in database of 
components and applications. An application blueprint can call on component 
blueprints from the catalog, therefore allowing complex applications to be 
built from simple pieces.

Apache Brooklyn currently uses a simple authentication/authorisation system. 
Runtime authentication relies on HTTP Basic Authentication. While this has been 
satisfactory for some time, it has many shortcomings. HTTP Basic Authentication 
caches credentials on the client side, which is a weakness. It's not possible 
for a server policy to enforce session expiry timeouts. Even trivial things 
such as providing a "logout" button are difficult to reliably implement. This 
makes enterprise adoption of Brooklyn problematic as it cannot comply with the 
security policy requirements that enterprises typically have.

Apache Brooklyn's authorisation systems on the server side are basic. Usernames 
and passwords can be put into the server configuration by an administrator. 
This means that users do not have the ability to change their own password, and 
enterprise security policies such as password rotation cannot be supported. (As 
an alternative, Brooklyn can integrate with external directory services, but it 
is often overkill to deploy a heavy directory server alongside a Brooklyn 
server.)

This project would be to overhaul Apache Brooklyn's login system to a modern 
system. Considerations include:
 * A built-in user directory that is easy to get started with yet which guides 
the administrator towards a secure system
 * Credentials stored in a secure manner
 * A login screen in the UI, and the appropriate API methods to log in and 
issue tokens
 * Revise the server side API code to validate tokens
 * UI and API support for logging out, changing password, other appropriate 
operations
 * UI and API support for an administrator to manage users
 * Security policy features such as:
 ** Logged in sessions expire after a fixed time
 ** User must change their password on first login
 ** User passwords expire after a fixed time and must be changed
 ** Lock out accounts after a number of failed logins
 ** Audit log
 * Retain ability to integrate with an external directory service

This project will involve the use of Java for the server-side development (this 
is where most of the work will take place), and HTML+CSS+Javascript for the 
client-side development (this is less important as we expect others will be 
on-hand to help with the visual development). It will require study and 
implementation of "best practices" for security.

  was:
Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon EC2. 
In more detail, it's a tool for describing applications and their components, 
deploying these applications to the cloud, and managing the ongoing health and 
responsiveness. Brooklyn does this using blueprints - human readable documents 
which describe in detail an application component, or a whole application. 
Blueprints are stored in a catalog, essentially a built-in database of 
components and applications. An application blueprint can call on component 
blueprints from the catalog, therefore allowing complex applications to be 
built from simple pieces.

Apache Brooklyn currently uses a simple authentication/authorisation system. 
Runtime authentication relies on HTTP Basic Authentication. While this has been 
satisfactory for some time, it has many shortcomings. HTTP Basic Authentication 
caches credentials on the client side, which is a weakness. It's not possible 
for a server policy to enforce session expiry timeouts. Even trivial things 
such as providing a "logout" button are difficult to reliably implement. This 
makes enterprise adoption of Brooklyn problematic as it cannot comply with the 
security policy requirements that enterprises typically have.

Apache Brooklyn's authorisation systems on the server side are basic. Usernames 
and passwords can be put into the server configuration by an administrator. 
This means that users do not have the ability to change their own password, and 
enterprise security policies such as password rotation cannot be supported.

[jira] [Updated] (BROOKLYN-577) GSoC: Modernise Brooklyn's authentication system

[Richard Downer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer updated BROOKLYN-577:

Summary: GSoC: Modernise Brooklyn's authentication system  (was: Modernise 
Brooklyn's authentication system)

> GSoC: Modernise Brooklyn's authentication system
> 
>
> Key: BROOKLYN-577
> URL: https://issues.apache.org/jira/browse/BROOKLYN-577
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Richard Downer
>Priority: Major
>  Labels: cloud, java, javascript, rest
>
> This is an idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon 
> EC2. In more detail, it's a tool for describing applications and their 
> components, deploying these applications to the cloud, and managing the 
> ongoing health and responsiveness. Brooklyn does this using blueprints - 
> human readable documents which describe in detail an application component, 
> or a whole application. Blueprints are stored in a catalog, essentially a 
> built-in database of components and applications. An application blueprint 
> can call on component blueprints from the catalog, therefore allowing complex 
> applications to be built from simple pieces.
> Apache Brooklyn currently uses a simple authentication/authorisation system. 
> Runtime authentication relies on HTTP Basic Authentication. While this has 
> been satisfactory for some time, it has many shortcomings. HTTP Basic 
> Authentication caches credentials on the client side, which is a weakness. 
> It's not possible for a server policy to enforce session expiry timeouts. 
> Even trivial things such as providing a "logout" button are difficult to 
> reliably implement. This makes enterprise adoption of Brooklyn problematic as 
> it cannot comply with the security policy requirements that enterprises 
> typically have.
> Apache Brooklyn's authorisation systems on the server side are basic. 
> Usernames and passwords can be put into the server configuration by an 
> administrator. This means that users do not have the ability to change their 
> own password, and enterprise security policies such as password rotation 
> cannot be supported. (As an alternative, Brooklyn can integrate with external 
> directory services, but it is often overkill to deploy a heavy directory 
> server alongside a Brooklyn server.)
> This project would be to overhaul Apache Brooklyn's login system to a modern 
> system. Considerations include:
>  * A built-in user directory that is easy to get started with yet which 
> guides the administrator towards a secure system
>  * Credentials stored in a secure manner
>  * A login screen in the UI, and the appropriate API methods to log in and 
> issue tokens
>  * Revise the server side API code to validate tokens
>  * UI and API support for logging out, changing password, other appropriate 
> operations
>  * UI and API support for an administrator to manage users
>  * Security policy features such as:
>  ** Logged in sessions expire after a fixed time
>  ** User must change their password on first login
>  ** User passwords expire after a fixed time and must be changed
>  ** Lock out accounts after a number of failed logins
>  ** Audit log
>  * Retain ability to integrate with an external directory service
> This project will involve the use of Java for the server-side development 
> (this is where most of the work will take place), and HTML+CSS+Javascript for 
> the client-side development (this is less important as we expect others will 
> be on-hand to help with the visual development). It will require study and 
> implementation of "best practices" for security.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BROOKLYN-577) Modernise Brooklyn's authentication system

[Richard Downer (JIRA)]

Richard Downer created BROOKLYN-577:
---

 Summary: Modernise Brooklyn's authentication system
 Key: BROOKLYN-577
 URL: https://issues.apache.org/jira/browse/BROOKLYN-577
 Project: Brooklyn
  Issue Type: Improvement
Affects Versions: 1.0.0
Reporter: Richard Downer


Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon EC2. 
In more detail, it's a tool for describing applications and their components, 
deploying these applications to the cloud, and managing the ongoing health and 
responsiveness. Brooklyn does this using blueprints - human readable documents 
which describe in detail an application component, or a whole application. 
Blueprints are stored in a catalog, essentially a built-in database of 
components and applications. An application blueprint can call on component 
blueprints from the catalog, therefore allowing complex applications to be 
built from simple pieces.

Apache Brooklyn currently uses a simple authentication/authorisation system. 
Runtime authentication relies on HTTP Basic Authentication. While this has been 
satisfactory for some time, it has many shortcomings. HTTP Basic Authentication 
caches credentials on the client side, which is a weakness. It's not possible 
for a server policy to enforce session expiry timeouts. Even trivial things 
such as providing a "logout" button are difficult to reliably implement. This 
makes enterprise adoption of Brooklyn problematic as it cannot comply with the 
security policy requirements that enterprises typically have.

Apache Brooklyn's authorisation systems on the server side are basic. Usernames 
and passwords can be put into the server configuration by an administrator. 
This means that users do not have the ability to change their own password, and 
enterprise security policies such as password rotation cannot be supported. (As 
an alternative, Brooklyn can integrate with external directory services, but it 
is often overkill to deploy a heavy directory server alongside a Brooklyn 
server.)

This project would be to overhaul Apache Brooklyn's login system to a modern 
system. Considerations include:
 * A built-in user directory that is easy to get started with yet which guides 
the administrator towards a secure system
 * Credentials stored in a secure manner
 * A login screen in the UI, and the appropriate API methods to log in and 
issue tokens
 * Revise the server side API code to validate tokens
 * UI and API support for logging out, changing password, other appropriate 
operations
 * UI and API support for an administrator to manage users
 * Security policy features such as:
 ** Logged in sessions expire after a fixed time
 ** User must change their password on first login
 ** User passwords expire after a fixed time and must be changed
 ** Lock out accounts after a number of failed logins
 ** Audit log
 * Retain ability to integrate with an external directory service

This project will involve the use of Java for the server-side development (this 
is where most of the work will take place), and HTML+CSS+Javascript for the 
client-side development (this is less important as we expect others will be 
on-hand to help with the visual development). It will require study and 
implementation of "best practices" for security.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Google Summer of Code 2018

[Richard Downer]

This is a great start :-) and thanks for volunteering to mentor, too.

I'm wondering if we should expand this out with some more introductory
material, and expand a bit more on the skills required? I'm assuming that
prospective GSoC students would see only the content of the JIRA, so maybe
setting some more context would be appropriate.

Perhaps open with...

"Apache Brooklyn is a tool for running stuff in "the cloud", such as Amazon
EC2. In more detail, it's a tool for describing applications and their
components, deploying these applications to the cloud, and managing the
ongoing health and responsiveness. Brooklyn does this using blueprints -
human readable documents which describe in detail an application component,
or a whole application. Blueprints are stored in a catalog, essentially a
built-in database of components and applications. An application blueprint
can call on component blueprints from the catalog, therefore allowing
complex applications to be built from simple pieces."

I'd maybe also remove the prescribed list of views in favour of something
more general. Our student may come up with a radical new idea that we had
not considered! Example:

"The UI should facilitate three main tasks: (1) deploying an application;
(2) viewing and managing deployed applications; (3) viewing and managing
the catalog. There may also be further auxiliary tasks that the UI will
need to support, such as a REST API explorer."

Finally I'd suggest we talk about the skills that the task will require -
although we should be careful not to frame these as prerequisites, as it is
the aim that the student will have to learn something :-)

"The project for green-field development of a new web based UI will
involve: selecting a modern Javascript web framework; working with REST
APIs; a visually appealing design; an easy-to-use user experience. The
server side API is written in Java but an understanding of Java is NOT
required."

WDYT?

Cheers
Richard

On 23 January 2018 at 15:02, Thomas Bouron 
wrote:

> Hi all.
>
> I create a JIRA for this[1] following the instructions from Ulrich. I
> haven't tag it properly because I wanted to run the JIRA through you all to
> check if everything was ok and in case you wanted to add something else.
>
> Assuming I don't get comments, I would gladly put myself as a mentor for
> this one.
>
> WDYT?
>
> Best.
>
> [1] https://issues.apache.org/jira/browse/BROOKLYN-575
>
> On Tue, 23 Jan 2018 at 11:21 Thomas Bouron  com>
> wrote:
>
> > Hi Richard.
> >
> > I love the idea of having a replacement GUI project for this, sounds like
> > a very good opportunity for everyone to learn a new thing.
> > I'll try to draft a proposal this week.
> >
> > Best.
> >
> > On Tue, 23 Jan 2018 at 10:45 Richard Downer  wrote:
> >
> >> Hi all,
> >>
> >> Apache is gearing up for Google Summer of Code 2018. All Apache projects
> >> have been invited to submit their ideas for GSoC projects.
> >>
> >> For those not familiar with GSoC, the idea is during that students will
> >> use
> >> their summer break to embark on a 3-month programming project with an
> open
> >> source organisation.
> >>
> >> If we want to take part then we simply need to come up with some
> suitable
> >> ideas and open a JIRA ticket with suitable labels. We'll also need
> mentors
> >> to work with our students - mentors will need to keep a continuous
> dialog
> >> with their student and expect to consume 3-5 hours a week in that role.
> >>
> >> **Deadline for this is 30th January - Tuesday next week**
> >>
> >> Any ideas for GSoC projects - projects that can be completed in 3 months
> >> by
> >> a student?
> >>
> >> Our GUI is somewhat dated - a replacement GUI project?
> >>
> >> A project to add support for updating a blueprint of a running
> >> application?
> >>
> >> Anything else?
> >>
> >>
> >> A bit more information from Ulrich Stärk who is running the Apache side
> of
> >> GSoC:
> >>
> >> Google Summer of Code [1] is a program sponsored by Google allowing
> >> students to spend their summer working on open source software. Students
> >> will receive stipends for developing open source software full-time for
> >> three months. Projects will provide mentoring and project ideas, and in
> >> return have the chance to get new code developed and - most importantly
> -
> >> to identify and bring in new committers.
> >>
> >> The ASF will apply as a participating organiz

Re: Getting NodeMetadata available to entities

[Richard Downer]

Hi Alex,

On 23 January 2018 at 10:39, Alex Heneveld 
wrote:

> What values does it need?  Would it make sense to put it into
> BasicMachineMetadata and adjust JcloudsLocation.getMachineMetadata to add
> it for everything?
>

That would be a good solution for the medium or long term - there's not
much reason for having all the `NodeMetadata`, cherry-picking out the IP
address and then throwing the rest away! I suppose it's theoretically
possible that the metadata might include some sensitive information that is
not appropriate to be exposed in some kinds of service provider use cases
but I think that's unlikely to be a general problem.

What I specifically need is the `userMetadata`. The particular cloud
provider in question sets additional metadata k/v pairs, and one of these
values I would like to expose in the GUI.

However I'm really looking for a way to do this in the short term (without
waiting for a release cycle).

The other option if you want to opt-in at an initializer is for it to do
> `location.getConfig(CALLER_CONTEXT)` -- there isn't guaranteed to be
> exactly one Entity for each Location
> (might have multiple, might have none) so there isn't a
> `Location.getEntity()` and this value might not be an `Entity`, but if
> there _is_ such a one-to-one releationship where an entity creates a
> location, the usual pattern is that the Entity will set itself as this
> context.
>

Thanks, I'll look into this.

Cheers
Richard.

Google Summer of Code 2018

[Richard Downer]

Hi all,

Apache is gearing up for Google Summer of Code 2018. All Apache projects
have been invited to submit their ideas for GSoC projects.

For those not familiar with GSoC, the idea is during that students will use
their summer break to embark on a 3-month programming project with an open
source organisation.

If we want to take part then we simply need to come up with some suitable
ideas and open a JIRA ticket with suitable labels. We'll also need mentors
to work with our students - mentors will need to keep a continuous dialog
with their student and expect to consume 3-5 hours a week in that role.

**Deadline for this is 30th January - Tuesday next week**

Any ideas for GSoC projects - projects that can be completed in 3 months by
a student?

Our GUI is somewhat dated - a replacement GUI project?

A project to add support for updating a blueprint of a running application?

Anything else?


A bit more information from Ulrich Stärk who is running the Apache side of
GSoC:

Google Summer of Code [1] is a program sponsored by Google allowing
students to spend their summer working on open source software. Students
will receive stipends for developing open source software full-time for
three months. Projects will provide mentoring and project ideas, and in
return have the chance to get new code developed and - most importantly -
to identify and bring in new committers.

The ASF will apply as a participating organization meaning individual
projects don't have to apply
separately.

If you want to participate with your project we ask you to do the following
things as soon as
possible but please no later than 2017-01-30:

1. understand what it means to be a mentor [2].

2. record your project ideas.


[1] https://summerofcode.withgoogle.com/
[2] http://community.apache.org/guide-to-being-a-mentor.html

Getting NodeMetadata available to entities

[Richard Downer]

Hi all.

I'm trying to solve a problem which basically involves getting a value from
the jclouds `NodeMetadata` into a sensor on all entities in that
`JcloudsLocation`. A `JcloudsLocationCustomizer` would appear to be useful
as it gets all the `NodeMetadata`, but as it doesn’t get a reference to the
entity it can’t add the sensor itself.

I looked at other possible solution but it seems that the `NodeMetadata` is
thrown away by Brooklyn once the machine is started, so a solution like
`EntityInitializer` isn’t going to work either. My current plan is to use a
location customizer to get the data needed and stash it somewhere in the
`MachineLocation` config, and an initializer to retrieve it and set a
sensor, but this sounds messy and also requires blueprints to be modified
to add the initializer.

Are there any other possible solutions?

Thanks
Richard.

[jira] [Resolved] (BROOKLYN-572) Brooklyn CLI has problems on windows

[Richard Downer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer resolved BROOKLYN-572.
-
   Resolution: Fixed
Fix Version/s: 1.0.0

Resolution is in PR https://github.com/apache/brooklyn-client/pull/66 which has 
been merged.

> Brooklyn CLI has problems on windows
> 
>
> Key: BROOKLYN-572
> URL: https://issues.apache.org/jira/browse/BROOKLYN-572
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Duncan Godwin
>    Assignee: Richard Downer
> Fix For: 1.0.0
>
>
> * The CLI seems not to zip all artefacts correctly on windows
> * Paths starting {{C://}} or another drive name have the error: 
> {{Unrecognised protocol scheme: c}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (BROOKLYN-572) Brooklyn CLI has problems on windows

[Richard Downer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Downer reassigned BROOKLYN-572:
---

Assignee: Richard Downer

> Brooklyn CLI has problems on windows
> 
>
> Key: BROOKLYN-572
> URL: https://issues.apache.org/jira/browse/BROOKLYN-572
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Duncan Godwin
>    Assignee: Richard Downer
> Fix For: 1.0.0
>
>
> * The CLI seems not to zip all artefacts correctly on windows
> * Paths starting {{C://}} or another drive name have the error: 
> {{Unrecognised protocol scheme: c}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [PROPOSAL] Using docker for jenkins builds

[Richard Downer]

+1

Having seen some of the conversations on the bui...@apache.org list, it
does seem like this is the way to go as far as getting the right build
environment on the Apache Jenkins cluster. This is the best solution for
getting the `rpm` and `deb` built regularly.

Build consistency is also a great driver. I can see this being useful for
the release process too, as a release build would have an identical
environment to that used to build the snapshots.

Richard.


On 14 November 2017 at 15:43, Thomas Bouron  wrote:

> Hi Brooklyners!
>
> Few months ago, I pushed a PR[1] to simplify `brooklyn-vagrant` by using
> the RPM package. This is still on hold because we don't build RPM package
> of SNAPSHOT versions and therefore, our vagrant install script won't work
> for bleeding edge versions.
> For the record, RPM are not built on SNAPSHOT because INFRA does not offer
> centos/RHEL machines as Jenkins slaves.
>
> But that is coming to an end. INFRA did install (recently-ish) docker on
> all Jenkins slaves which means that a new world is opened to us! In the
> past weeks, I have created a clone[2] of the `brooklyn-dist-master`[3] job
> and configured it to use a custom docker image I created[4]. It is based on
> `maven:alpine` and adds `rpm` and `dpkg` binaries (for the `dist` tag).
> As my test was successful, I decided to go a little further by creating 2
> other tags for this image:
> - `client, based on `maven:alpine` with the `go` binary
> - `latest` which is the combination of the last 2.
>
> My plan is to migrate all jenkins jobs to use docker. I'll donate the
> `Dockerfile` to each git repo so that jenkins will be able to build and
> publish them on docker hub instead of using my account/image. Once we have
> everything dockerised, we can look at improving current builds, like using
> jenkins pipelines rather than relying on upstream<->downstream projects'
> relationships.
>
> It also makes the integration/live tests rise from the ashes. This is the
> perfect opportunity to fix and make then part of our CI.
>
> WDYT? Even if it's obvious, the main advantage here is the portability of
> the build environment. It also means that we can use any jenkins slaves,
> potentially saving us a lot of time when waiting for a build executor.
>
> Best.
>
> [1] https://github.com/apache/brooklyn-dist/pull/105
> [2]
> https://builds.apache.org/view/B/view/Brooklyn/job/
> brooklyn-dist-master-docker/
> [3] https://builds.apache.org/view/B/view/Brooklyn/job/
> brooklyn-dist-master/
> [4] https://hub.docker.com/r/tbouron/brooklyn-build/
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Re: New `website` branch in brooklyn-docs

[Richard Downer]

ates.

I think it's also worth mentioning that our website is actually pretty
small, and maybe 90% of those pages are not related to features. There's
very little content that genuinely is dependent on a Brooklyn release. Many
feature-related content is actually a link to /v/latest/... So even if we
do want to do more of these kinds of update, it will remain a small number.

This is what I mean by "it optimises for rare conditions at the expense of
common conditions". In the history of the Brooklyn website, the majority of
changes are for immediate release. A passer-by looking to make a fix to our
website would almost certainly be looking to make an immediate release. But
under this workflow, the common case is the harder one to do.

Efforts in that direction will backfire and make the risks Richard speaks
> of (wrong content live on our website) more likely IMO.


I disagree. If you have multiple branches containing the website it's more
likely that:
- a submitter makes a PR against the wrong branch
- a committer merges a PR into the wrong branch, or does not merge it into
all applicable branches
- a pre/post-release merge between website branches is not done, or is done
incorrectly
- a website update is generated from the wrong branch

I've been in this scenario - I've tried to update the Brooklyn website with
newly-added content, only to run `svn diff` and find that other content has
disappeared, and I've lost hours if not days trying to keep the published
website coherent. It's a mess, and a plurality of branches has been
responsible for website problems.

OTOH, the risk around accidentally publishing an update for a new feature
too early are small, simply because we generally don't make that content
:-)  And if we do want to make more of those types of updates, we can
surely come up with a lighter-weight process than having multiple branches.

--

To put the "immediate update required" scenario into perspective, I'd like
to go back to an example you wrote earlier in this thread:

* Primary reason for branching (in my view) is lifecycle, and here the two

have very similar versioning and release lifecycles: master for both will
> be relevant to master of codebase, where eg v0.12.0 will be relevant to
> last release of 0.12.0 and what is live; there will be times we want to
> update what is live with something more reason relevant to that version,
> but we'll do that by pushing to 0.12, and we can release (publish) that
> immediately


My unhappiness here is the statement "v0.12.0 will be relevant to last
release of 0.12.0 and what is live" - this requires that the *submitter*
knows that if an immediate website update is required, that he must make
his PR against branch v0.12.0, and the committer must also merge it to that
branch, and build the website from that branch. This is putting the onus on
the *submitter* - and, to a lesser extent, the committer - to know this.

But there's another problem. In the hopefully not-too-distant future, we
will have more users using Brooklyn in production, and we are more likely
to hit "immediate bug-fix release required" problems, and we must support
users on a previous version.

Say we've published versions 1.0.0 and 1.1.0. We have many users in
production on 1.0.0, but not many on 1.1.0 as it's just been released. Then
we discover that one of the bugs we fixed in 1.1.0 was actually a security
vulnerability. Our 1.0.0 production users don't want to move up a whole
version to get a security vulnerability fixed, so we backport that fix and
make a new 1.0.1 release.

Q: Where do we document the CVE security advisories that urgently need to
go on the live website, and any subsequent live website updates? 1.0.1 (the
version we just released), master (seen by default when you go to GitHub),
1.1.0 (the highest-numbered release but not the most recent release), or a
combination?

Yes we can come up with a policy that explains this, but again it's causing
ambiguity and putting the onus on the PR submitter to know that policy
exists and to follow it.

--

In summary: keep it simple. There's only one website. So there shouldn't be
multiple website branches. It's in `master`, because if someone sees and
fixes a problem with the website that's where they will submit a PR. No
branches, no merges, no multiple PRs.

In the (currently rare) event of a website update that needs to be held
back for the next release, clearly say so in the PR title so that a
committer doesn't merge it. It's common in Brooklyn to mark a PR as "WIP"
or "For review only"; non-guide updates for new features could be handled
in the same way.


To repeat my earlier disclaimer, this is just an opinion, and writing it in
an email does not imply that it is correct! I am always open to listening
to the alternatives, and I am often persua

Re: New `website` branch in brooklyn-docs

[Richard Downer]

Hi Alex, Mark, sorry for the late reply.

Alex - you make fair points. It does somewhat obscure the location of the
website and complicate raising PRs.

I think that a separate repo is probably the best long-term solution, but I
didn't want to rush into it - creating repos is cheap (Infra can do that
relatively easily) but deleting repos is nearly impossible for legal policy
reasons. So I wanted to make sure we were making the right decision for a
docs/website split before we commit to a separate repo.

I'm not convinced of your argument about website_0.12 etc. IMO the website
has a lifecycle which is independent of releases and as a general rule
there should only ever be one website branch. Having multiple copies of the
website on different branches with content for different purposes is a
recipe for confusion. Such confusion risks updates on the website appearing
and disappearing when the site is regenerated different branches, either
accidentally or when content is not merged to all appropriate branches. If
we do want to have a holding space for "v.Next" content on the main site,
then I think there are other ways of handling this.

Could I suggest we remain with the current setup (different branch in docs
repo) for the short term, until we are absolutely happy with our new
arrangement, and then switch to a new brooklyn-website repo (or alternative
if we don't like the new arrangement)? My thoughts are that this would
happen once we've made a 1.0 release and tested out all the process, or to
set a deadline if a 1.0 release starts getting pushed out, but I'm happy to
hear thoughts on this.

Richard.


On 27 October 2017 at 10:15, Mark McKenna  wrote:

> Richard , Alex
>
> I think its fine on a branch short term (few weeks)
>
> I think we should follow the pattern from other projects and split our
> website into its own repository.
>
> Alex I think the technology of the website and the docs should diverge ie
> we choose the best technology for each.
>
> RE PRs ... splitting the site / docs makes the most sense as we deal with
> making prs across Brooklyn's numerous repositories
>
>
> Mark
>
>
>
> On 27 October 2017 at 09:01, Alex Heneveld  com>
> wrote:
>
> >
> > Sorry - I really don't like website being hidden on a branch.
> >
> > Why?
> >
> > * It's non-obvious and one more thing to remember (or forget, or explain)
> > * Primary reason for branching (in my view) is lifecycle, and here the
> two
> > have very similar versioning and release lifecycles: master for both will
> > be relevant to master of codebase, where eg v0.12.0 will be relevant to
> > last release of 0.12.0 and what is live; there will be times we want to
> > update what is live with something more reason relevant to that version,
> > but we'll do that by pushing to 0.12, and we can release (publish) that
> > immediately unlike code, but what we _can't_ assume for both is that
> master
> > can always be published, because we may have added unreleased features to
> > docs for both site and guide; with site in a `website` branch we will
> have
> > to have branches there eg `website_0.12` alongside `0.12` of guide
> > * PRs become more difficult, remembering which branch to open them
> against
> > and merge against
> > * PRs become even more difficult if adding a feature which goes onto both
> > the site and into the docs (which we should do more of), we add to one
> > branch, switch branches add to the other, then open PRs for both branches
> > * Ideally they converge to use the same technology (not both gitbook and
> > markdown) so if in the same project they can share themes and utils etc;
> if
> > in different branches we have to cherry-pick between branches (always
> > opening and reviewing 2 identical PRs!)
> >
> > My ideal would be different subdirs but if they really need to be
> separate
> > then we could do a different project (resolves reasons 1 2 3 and
> improves 4
> > and 5)
> >
> > Best
> > Alex
> >
> >
> >
> > On 26/10/2017 14:04, Richard Downer wrote:
> >
> >> All,
> >>
> >> Following on from Thomas's gitbook work[1] - now merged[2] - it means
> that
> >> the brooklyn-docs `master` branch does not contain the public website
> >> (just
> >> the documentation).
> >>
> >> In those threads it was discussed that most branches would remove the
> >> website, and a separate branch would be used to store the public website
> >> (a
> >> bit like how GitHub pages used a `gh-pages` branch for a repository's
> >> publis website). I'm assuming that the

New `website` branch in brooklyn-docs

[Richard Downer]

All,

Following on from Thomas's gitbook work[1] - now merged[2] - it means that
the brooklyn-docs `master` branch does not contain the public website (just
the documentation).

In those threads it was discussed that most branches would remove the
website, and a separate branch would be used to store the public website (a
bit like how GitHub pages used a `gh-pages` branch for a repository's
publis website). I'm assuming that the acceptance and merging of gitbooks
is passive consensus of this concept too.

Therefore, I've created a new branch in the Apache brooklyn-docs repo
called `website`, which is taken from `master` immediately prior to the
merge of the gitbook conversion.

If anybody disagrees with this passive consensus approach and thinks that
this branch is a bad idea, then please feel free to speak up. After all,
source control means that things can always be undone :-)

Expect a forthcoming PR on the `website` branch to remove the documentation
files and leave just the website files (like the opposite of Thomas's PR).

Richard.

[1]
https://lists.apache.org/thread.html/760a3e2fdefaff8d8ac4ea3f98a45060fbaa0d886fa57c8f44e4742e@%3Cdev.brooklyn.apache.org%3E
[2] https://github.com/apache/brooklyn-docs/pull/222

-- Forwarded message --
From: 
Date: 26 October 2017 at 13:50
Subject: [brooklyn-docs] Git Push Summary
To: comm...@brooklyn.apache.org


Repository: brooklyn-docs
Updated Branches:
  refs/heads/website [created] e1d08e53c

Re: Call for release: Brooklyn 0.12.1

[Richard Downer]

Looks like there's consensus for a release. Any volunteers to be RM?

Richard.


On 20 October 2017 at 12:22, Alex Heneveld 
wrote:

> +1
>
>
> On 20/10/2017 10:06, Duncan Godwin wrote:
>
>> +1
>>
>> On 20 October 2017 at 09:55, Geoff Macartney <
>> geoff.macart...@cloudsoft.io>
>> wrote:
>>
>> +1 (and agree we should just do it with the cherry pick)
>>>
>>>
>>>
>>> On Fri, 20 Oct 2017 at 09:50 Thomas Bouron >> com>
>>> wrote:
>>>
>>> I agree with you Mark. I would cherry-pick only the fix for vagrant.
>>>>
>>>> On Fri, 20 Oct 2017 at 09:46 Duncan Grant 
>>>> wrote:
>>>>
>>>> +1 (non-binding)
>>>>>
>>>>>
>>>>> On Fri, 20 Oct 2017 at 09:44 Mark McKenna 
>>>>>
>>>> wrote:
>>>>
>>>>> +1
>>>>>>
>>>>>> IMO 0.12.1 should only contain this fix
>>>>>>
>>>>>> *Mark McKenna*
>>>>>>
>>>>>> *Twitter ::* @m4rkmckenna <https://twitter.com/m4rkmckenna>
>>>>>>
>>>>>> *Github :: *m4rkmckenna <https://github.com/m4rkmckenna>
>>>>>>
>>>>>> *PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
>>>>>> <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>*
>>>>>>
>>>>>> On 19 October 2017 at 16:12, Richard Downer 
>>>>>>
>>>>> wrote:
>>>>
>>>>> +1
>>>>>>>
>>>>>>> On 19 October 2017 at 16:07, Thomas Bouron
>>>>>>>
>>>>>> >>>>
>>>>>> com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi all
>>>>>>>>
>>>>>>>> A couple a people on IRC and the ML had issues with
>>>>>>>>
>>>>>>> `brooklyn-vagrant`.
>>>>>
>>>>>> This is unfortunately broken in Brooklyn 0.12.0, but it is the
>>>>>>>>
>>>>>>> main
>>>
>>>> installation method that we promote on the Brooklyn website.
>>>>>>>>
>>>>>>>> As a new user, this can be a very frustrating first experience
>>>>>>>>
>>>>>>> with
>>>
>>>> Brooklyn which, IMO, does not send the right message.
>>>>>>>>
>>>>>>>> For this reason, I think we should do a Brooklyn 0.12.1 release
>>>>>>>>
>>>>>>> as
>>>
>>>> soon
>>>>>
>>>>>> as
>>>>>>>
>>>>>>>> possible.
>>>>>>>>
>>>>>>>> Let us know your opinions and if there are no other outstanding
>>>>>>>>
>>>>>>> problems.
>>>>>>
>>>>>>> Best.
>>>>>>>> --
>>>>>>>>
>>>>>>>> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation
>>>>>>>>
>>>>>>> •
>>>
>>>> https://cloudsoft.io/
>>>>>>>> Github: https://github.com/tbouron
>>>>>>>> Twitter: https://twitter.com/eltibouron
>>>>>>>>
>>>>>>>> --
>>>>
>>>> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
>>>> https://cloudsoft.io/
>>>> Github: https://github.com/tbouron
>>>> Twitter: https://twitter.com/eltibouron
>>>>
>>>>
>

Re: Call for release: Brooklyn 0.12.1

[Richard Downer]

+1

On 19 October 2017 at 16:07, Thomas Bouron 
wrote:

> Hi all
>
> A couple a people on IRC and the ML had issues with `brooklyn-vagrant`.
> This is unfortunately broken in Brooklyn 0.12.0, but it is the main
> installation method that we promote on the Brooklyn website.
>
> As a new user, this can be a very frustrating first experience with
> Brooklyn which, IMO, does not send the right message.
>
> For this reason, I think we should do a Brooklyn 0.12.1 release as soon as
> possible.
>
> Let us know your opinions and if there are no other outstanding problems.
>
> Best.
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Re: [PROPOSAL] Split Brooklyn website and documentation

[Richard Downer]

 away a lot of our home-grown docs-building and
> >> toc-building code and have good search.  Look forward to seeing how it
> >> shapes up with styling and guide-v-website integration.
> >>
> >> Best
> >> Alex
> >>
> >>
> >> On 09/10/2017 09:54, Thomas Bouron wrote:
> >> > Thanks Mark.
> >> >
> >> > Regarding maintenance, it will be as easy as the current version.
> >> Updating
> >> > docs means updating markdown files. Adding/moving pages requires to
> >> modify
> >> > the `SUMMARY.md` but that's it.
> >> > One really cool thing is that Gitbook is a node app: really simple to
> >> > install/run compare to our current solution which runs only on an old
> >> > version of ruby => no more pain of using different versions of ruby on
> >> your
> >> > environment.
> >> >
> >> > In terms of feature gaps, Gitbook provides the same or more features
> >> than
> >> > Jekyll out the box:
> >> > - search! That is a big one, not available with Jekyll
> >> > - include of external files
> >> > - syntax highlighting
> >> > - plugins system
> >> > - custom theme
> >> >
> >> > Best.
> >> >
> >> > On Sat, 7 Oct 2017, 17:10 Mark McKenna, 
> wrote:
> >> >
> >> >> Thomas this looks really clean great work.
> >> >>
> >> >> How much work do you think it will take to maintain vs our current
> >> >> solution?
> >> >> What do you see as being the current feature gaps?
> >> >>
> >> >> M
> >> >>
> >> >> On Fri, 6 Oct 2017 at 14:55 Thomas Bouron <
> >> thomas.bou...@cloudsoftcorp.com
> >> >> wrote:
> >> >>
> >> >>> Hi Richard.
> >> >>>
> >> >>> Of course, I pushed it to my fork on the branch
> >> `experiment/gitbook`[1]
> >> >>> Glad you like it :)
> >> >>>
> >> >>> Best.
> >> >>>
> >> >>> [1] https://github.com/tbouron/brooklyn-docs/tree/experiment/
> gitbook
> >> >>>
> >> >>> On Fri, 6 Oct 2017 at 13:53 Andrea Turli 
> wrote:
> >> >>>
> >> >>>> +1 Thomas, didn't know Gitbook at all (that's why I suggested
> >> >>> readthedocs)
> >> >>>> but looks pretty good!
> >> >>>>
> >> >>>> Il 06/ott/2017 15:37, "Richard Downer"  ha
> >> >> scritto:
> >> >>>> Hi Thomas,
> >> >>>>
> >> >>>> I withdraw my previous comments - I looked at ReadTheDocs last year
> >> and
> >> >>> was
> >> >>>> pessimistic, but it seems that GitBook this year is a different
> story
> >> >> :-)
> >> >>>> This is worth pursuing IMO. What did you need to do to get this
> >> >> working?
> >> >>>> Did you have to do any work on the brooklyn-docs source - if so
> could
> >> >> you
> >> >>>> share a link to your repo?
> >> >>>>
> >> >>>> Thanks
> >> >>>> Richard.
> >> >>>>
> >> >>>>
> >> >>>> On 6 October 2017 at 13:18, Thomas Bouron
> >>  >> >>> com
> >> >>>> wrote:
> >> >>>>
> >> >>>>> Hi All.
> >> >>>>>
> >> >>>>> A demo is worth a thousand words so here is a gitbook adaptation
> of
> >> >> our
> >> >>>>> current documentation[1] (and only documentation)
> >> >>>>> This took me only a couple of hours. There are still things to
> >> >>>>> fix/update/remove like unsupported liquid tags but for the most
> >> part,
> >> >>> it
> >> >>>>> works like a charm.
> >> >>>>> Search is available from the search field on the top left and
> >> PDF[2],
> >> >>>>> epub[3] amd mobi[4] versions are also available.
> >> >>>>> The build took only 10 sec + 10 more per offline version.
> >> >>>>>
> >> >>>>> The table of content mirrors exactly what we current

Google Analytics for brooklyn.apache.org

[Richard Downer]

All,

Our website is sending Google Analytics metadata to UA-30530918-1. I've
been unable to find out who owns this account (it quite possibly dates back
to pre-Apache times) so I plan to create a new Google Analytics account and
push a website update to send analytics to that new account. (I'd then
share the details privately amongst the PMC so it's not held by one person.)

So this is a final call:

- Does anyone have access to the Google Analytics account for UA-30530918-1?

- Does anyone object to me changing this to a new Google Analytics account?

Thanks
Richard

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Richard Downer]

I offer my opinion through the medium of GIFs:

https://media.giphy.com/media/vohOR29F78sGk/giphy.gif

Richard.


On 9 October 2017 at 12:13, Aled Sage  wrote:

> Hi all,
>
> I propose that we *delete* Brooklyn classic-mode from master now, in
> preparation for the 1.0.0 release.
>
> ---
>
> In 0.12.0, we switched the main distro to be the karaf-mode. We also built
> the classic-mode distro - the intent being for users to have a usable
> classic mode, rather than being forced immediately to switch to karaf
> without advanced warning.
>
> However, we unfortunately did not deprecate classic-mode as clearly as we
> should have (e.g. didn't explicitly say that it will be deleted in an
> upcoming release, and didn't deprecate the `Main` class).
>
> I think it's still ok to delete it for several reasons:
>
> 1. This is a "mode" of running Brooklyn, rather than underlying
>Brooklyn functionality.
> 2. The `Main` class [1] etc should not be considered part of our
>*public* API (even though we didn't explicitly tell people that it
>was internal).
> 3. As part of 0.12.0 release, we added to the docs instructions for
>upgrading to Karaf [2].
> 4. Supporting classic to the same standard as Karaf will become
>increasingly painful as we do more and more with Bundles!
> 5. It's a major release, so if we are going to delete it then 1.0.0 is
>the perfect time!
>
> Aled
>
> [1] https://github.com/apache/brooklyn-server/blob/master/server
> -cli/src/main/java/org/apache/brooklyn/cli/Main.java
>
> [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> -from-apache-brooklyn-0110-and-below
>
>
>

Re: [PROPOSAL] Split Brooklyn website and documentation

[Richard Downer]

Hi Thomas,

I withdraw my previous comments - I looked at ReadTheDocs last year and was
pessimistic, but it seems that GitBook this year is a different story :-)

This is worth pursuing IMO. What did you need to do to get this working?
Did you have to do any work on the brooklyn-docs source - if so could you
share a link to your repo?

Thanks
Richard.


On 6 October 2017 at 13:18, Thomas Bouron 
wrote:

> Hi All.
>
> A demo is worth a thousand words so here is a gitbook adaptation of our
> current documentation[1] (and only documentation)
> This took me only a couple of hours. There are still things to
> fix/update/remove like unsupported liquid tags but for the most part, it
> works like a charm.
> Search is available from the search field on the top left and PDF[2],
> epub[3] amd mobi[4] versions are also available.
> The build took only 10 sec + 10 more per offline version.
>
> The table of content mirrors exactly what we currently have, except that I
> have limited it to only 2 sub-levels. It means that some pages are missing
> but I think it demonstrates that our current menu organisation could be
> vastly improved.
>
> Couple of thoughts on Alex's points:
>
> > * for the examples, import source code that is actually used in tests
> (!!!)
>
> Indeed, an overhaul does not solve it, nor our current framework. But both
> can implement it.
>
> > * check links
>
> Gitbook checks internal links at compile time and refuses to build if
> something is wrong. AFAIK, there is nothing in the Gitbook world to check
> the validity of external links like the Jekyll plugin does. There are
> probably external tools that we can integrate in our build pipeline to
> cover this. However, it seems that even if we have this tool, we don't use
> it when pushing the website (as I get a lot of errors locally)
> Realistically, we will always have broken links, things move around all the
> time. Checking external links is a nice-to-have but far from being a
> perfect solution. In any case, I don't see this point as important as you
> do.
>
> > * think through user flow
>
> The clear Gitbook menu exposes this pretty well IMO and better compared to
> the current version so that's a win.
>
> Best.
>
> [1] https://tbouron.github.io/brooklyn-docs/
> [2] https://tbouron.github.io/brooklyn-docs/brooklyn.pdf
> [3] https://tbouron.github.io/brooklyn-docs/brooklyn.epub
> [4] https://tbouron.github.io/brooklyn-docs/brooklyn.mobi
>
>
> On Thu, 5 Oct 2017 at 12:47 Richard Downer  wrote:
>
> > Thank you for the research you have done Thomas. I've had similar
> thoughts
> > myself. The original goal of our web+docs was to integrate them in such a
> > way that we had a versioned user guide that integrated perfectly with the
> > main website. At the time, Markdown tools were relatively immature, with
> > Jekyll leading the pack (and being the fashionable choice), and very
> little
> > in the way of viable apps for generating books with structure and tables
> of
> > contents. We did the best we could with the tools we had, but they needed
> > significant extensions (via Jekyll plugins and build scripting). Those
> > plugins and scripts have turned into something fairly hairy - IMO we
> > shouldn't need to have to write this much code[1] to generate a static
> site
> > and manual. With hindsight, I would not have argued in favour of this
> > model. If I do write my book[2] I will most likely be writing it in
> > ReStructuredText and processing it with Sphinx (and no additional
> > scripting/tooling!).
> >
> > That said, when I have looked at changing Brooklyn's documentation
> system,
> > it has not looked easy. With our home-grown TOC generating code, we're
> not
> > off-the-shelf compatible with other systems. Moving to another system,
> even
> > if it is Markdown-based, would still involve a lot of manual work
> changing
> > our document metadata to the new system, and adapting to replace the
> Jekyll
> > plugins and the content that uses them (e.g. syntax highlighting, file
> > inclusion). Unless you have discovered something I didn't, Thomas, then I
> > fear this will be a lot of work, mostly manual.
> >
> > In short, yes I like the idea of replacing our home-grown and
> > home-maintained code with an existing and supported app, but no I don't
> > think the effort of a big-bang migration justifies the results *at this
> > time*.
> >
> > Some things I would support:
> >
> > - Continued incremental improvements to both the website and the user
> > guide. IMO we have more problems with the content than with the t

Re: Apache Brooklyn 1.0 release

[Richard Downer]

Hi all,

Improving our authentication is a good feature to have, but I don't think
it's a blocker to a 1.0 release. I'd love to see this feature, but I don't
think we need to hold back 1.0 for it (better to think such a feature
through properly than to try and rush it into the next release.)

Andrea, I've looked at readthedocs myself - I love the idea of making the
drudgery of doc generation tooling Somebody Else's Problem, but when I last
looked, it wasn't suited to the way our user guide was written. It would
have needed quite a lot of manual effort to migrate from our home-grown
tooling into the way that readthedocs wants things to be written. See my
response[1] to Thomas' thread for a bit more.

[1]
https://lists.apache.org/thread.html/15b819cdecdcb717aa45e2efc7e4e5d3f1fcd491d1255a8aa72cd1c7@%3Cdev.brooklyn.apache.org%3E

On 5 October 2017 at 11:22, Andrea Turli  wrote:

> +1 to stronger authN
>
> FYI I've quickly tried readthedocs -- see
> https://readthedocs.org/projects/brooklyn-docs/ and it is nice and free,
> maybe we should consider it for the website. It is an hosted service well
> integrated with github which offers full text seatrch out of the box.
> Many others ASF projects already use them, it's maybe worth a try.
>
> My two cents,
> Andrea
>
>
>
> On 5 October 2017 at 12:07, Thomas Bouron  >
> wrote:
>
> > I would agree with Geoff on the auth. I think it would be nice to move to
> > JWT for 1.0.
> >
> > I would also point out the Brooklyn website. I'm the one to blame on
> this,
> > I redesigned the home page but not the rest (mostly due to the currently
> > complexity of it)
> > I'll send a proposal on this today.
> >
> > Best.
> >
> > On Wed, 4 Oct 2017 at 17:57 Geoff Macartney <
> geoff.macart...@cloudsoft.io>
> > wrote:
> >
> > > +1 with observation that there are still some things we might want to
> do
> > > before making that 1.0 release. (In re. Richard's comment about "Are we
> > > feature complete", you may think we are not.)
> > >
> > > For example something I think it would be good to do before announcing
> a
> > > 1.0 is to get away from basic auth on the UI and REST API and having a
> > > session token based approach, perhaps based on JWT tokens.  (Don't like
> > > storing the auth credentials for the CLI)
> > >
> > > That's one example but you may have your own suggestions - shout out!
> > >
> > > Geoff
> > >
> > >
> > >
> > > On Wed, 4 Oct 2017 at 16:41 Richard Downer  wrote:
> > >
> > > > +1 with conditions :-)
> > > >
> > > > Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that
> we
> > > > would get ASF PR involved to generate a bit of buzz around this, and
> > > > possibly approach some of our commercial users and friends to chip in
> > > with
> > > > some PR too.
> > > >
> > > > But going to 1.0 (and generating some media buzz around it) brings
> > > > responsibilities. If the media buzz brings in new users, we want to
> > make
> > > > sure our usability is as high as possible - this covers the app
> itself,
> > > as
> > > > well as the website and the documentation.
> > > >
> > > > So to answer your question with some more questions...
> > > >
> > > > Are we feature-complete?
> > > >
> > > > Do we have great usability? Good user stories for all our types of
> > users?
> > > >
> > > > Are we happy to freeze our API in its current state?
> > > >
> > > > Are we happy to accept a stricter deprecation policy going forward?
> > > >
> > > > Is there nothing that we want to deprecate before 1.0? (That would
> > imply
> > > > another 0.x release cycle)
> > > >
> > > > Have we removed every deprecated thing that we can? (If something is
> > > > deprecated but cannot be removed, why?)
> > > >
> > > > Do we have great documentation?
> > > >
> > > > Do we have a great website?
> > > >
> > > > Does our documentation and examples reflect the "best" (not
> deprecated,
> > > > outdated or suboptimal) way of doing things?
> > > >
> > > > Will the blueprints in the wider community be compatible with the
> > > proposed
> > > > 1.0 release or do they need updating? (We will need to work w

Re: [PROPOSAL] Split Brooklyn website and documentation

[Richard Downer]

Thank you for the research you have done Thomas. I've had similar thoughts
myself. The original goal of our web+docs was to integrate them in such a
way that we had a versioned user guide that integrated perfectly with the
main website. At the time, Markdown tools were relatively immature, with
Jekyll leading the pack (and being the fashionable choice), and very little
in the way of viable apps for generating books with structure and tables of
contents. We did the best we could with the tools we had, but they needed
significant extensions (via Jekyll plugins and build scripting). Those
plugins and scripts have turned into something fairly hairy - IMO we
shouldn't need to have to write this much code[1] to generate a static site
and manual. With hindsight, I would not have argued in favour of this
model. If I do write my book[2] I will most likely be writing it in
ReStructuredText and processing it with Sphinx (and no additional
scripting/tooling!).

That said, when I have looked at changing Brooklyn's documentation system,
it has not looked easy. With our home-grown TOC generating code, we're not
off-the-shelf compatible with other systems. Moving to another system, even
if it is Markdown-based, would still involve a lot of manual work changing
our document metadata to the new system, and adapting to replace the Jekyll
plugins and the content that uses them (e.g. syntax highlighting, file
inclusion). Unless you have discovered something I didn't, Thomas, then I
fear this will be a lot of work, mostly manual.

In short, yes I like the idea of replacing our home-grown and
home-maintained code with an existing and supported app, but no I don't
think the effort of a big-bang migration justifies the results *at this
time*.

Some things I would support:

- Continued incremental improvements to both the website and the user
guide. IMO we have more problems with the content than with the tooling,
and we can still make a lot of improvements to the usability of our docs
and website without tooling changes.

- Breaking the tight integration between website and user guide. "Fork" the
existing infrastructure but then have two build systems tailored for their
purpose rather than one that tried to meet two different needs. Would allow
the existing stuff to continue to work while opening the door to replacing
the guide tooling and redeveloping the website, independently of each
other, at a future date.

- Evaluating how other systems use metadata to describe the book structure,
and gradually adding support for this to our own tools and migrating
content. Then at a later date, when the content is nearly-compatible with
GitBook or some other system, it'll be easier to do the migration.

What do you think? Will following an incremental approach like this allow
us to make improvements gradually rather than a "big bang" replacement of
tooling?

Richard.

[1] https://gist.github.com/rdowner/a09a268b37904a03c452797e7afe56ca but
consider the COCOMO figures with appropriate cynicism
[2]
https://lists.apache.org/thread.html/6f19475bbc0570a3b9e3d1ae1b75b2b8ee4b2485b3b41d085c342dff@%3Cdev.brooklyn.apache.org%3E

On 5 October 2017 at 11:23, Thomas Bouron 
wrote:

> Hi all.
>
> It's been a couple of weeks that I started to look at how to improve and
> simplify the Brookyln website[1]. As I said on the Brooklyn 1.0 thread[2],
> I think we need to sort this out before releasing 1.0.
>
> I have looked for a framework / library to handle both the website and
> documentation the same way we do it right now. To determine what was the
> best fit, I based my analysis on the following criteria:
> - Able to take markdown files and generate HTML from them.
> - Keep the folder structure intact (currently, pages that seems in the same
> logical group - take pages in the download section[3] menu - jump into a
> different folder/category/section which is very confusing)
> - Be skinnable
> - Able to handle versions for documentation.
> - Able to generate PDF version of documentation.
> - Be as "stock" as possible to limit maintenance and pain during upgrade
> (our current website still uses Jekyll 2.x).
>
> 2 contenders clearly jumped out from this:
> - Jekyll[4]
> - Gitbook[5]
>
> 
> Jekyll
>
> With the version 3, Jekyll now has a concept of collections[6] which can
> generate pages from markdown files and keep the folder structure.
> The menu can be generated based on this folder structure (with depth
> limitation for example) in combination of some clever liquid tags and
> `include`. However, it will be hard to control the order of items appearing
> on the menu. Another easy solution would be maintain list of links for the
> menu to be generated.
> There are plugins to generate PDF[7], which happens during compile time.
> Finally, Jekyll is highly skinnable with built-in or custom themes.
>
> 
> Gitbook
>
> Gitbook, in its open source version, handles out of the box doc versioning,
> PDF generation at runtime (so it seems) HTML pages genera

Re: [ANNOUNCE] New committer: Thomas Bouron

[Richard Downer]

Welcome aboard Thomas :-) and thank you for the contributions - both to the
code and the community - that you have made so far!

Richard.


On 5 October 2017 at 09:42, Geoff Macartney  wrote:

> The Apache Brooklyn PMC (Project Management Committee) has invited
> Thomas Bouron to become a committer, and we are delighted that he has
> accepted.
>
> Thomas is an experienced contributor to Brooklyn, and brings in some
> specialised skills that will be very valuable for the project.
>
> Please join me in welcoming him to the Apache Brooklyn committers group.
>
> Geoff Macartney
>

Apache Brooklyn logo

[Richard Downer]

Hi all,

While we're thinking about Apache Brooklyn 1.0 and (in my opinion at least)
hoping to generate some media buzz at release time, I wonder if everybody
is happy with our logo and visual identity? Our logo is one that was
inherited from Cloudsoft when it owned the project. We've never actually
discussed this in our community in Apache.

We obviously have a few choices:

- Do nothing. The current logo is fine, and combined with our current
website design it looks pretty smart.

- Devise a new logo (or tweak the current logo) within our community -
subject to individuals with the appropriate creativity and graphic design
skills!

- Commission a new logo, for example from 99designs. This would obviously
cost money - a "logo and social media pack" from 99designs would cost £309
for the basic package - so I expect we'd be looking at crowdfunding.

What do people think?

Richard.

Re: Apache Brooklyn 1.0 release

[Richard Downer]

+1 with conditions :-)

Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that we
would get ASF PR involved to generate a bit of buzz around this, and
possibly approach some of our commercial users and friends to chip in with
some PR too.

But going to 1.0 (and generating some media buzz around it) brings
responsibilities. If the media buzz brings in new users, we want to make
sure our usability is as high as possible - this covers the app itself, as
well as the website and the documentation.

So to answer your question with some more questions...

Are we feature-complete?

Do we have great usability? Good user stories for all our types of users?

Are we happy to freeze our API in its current state?

Are we happy to accept a stricter deprecation policy going forward?

Is there nothing that we want to deprecate before 1.0? (That would imply
another 0.x release cycle)

Have we removed every deprecated thing that we can? (If something is
deprecated but cannot be removed, why?)

Do we have great documentation?

Do we have a great website?

Does our documentation and examples reflect the "best" (not deprecated,
outdated or suboptimal) way of doing things?

Will the blueprints in the wider community be compatible with the proposed
1.0 release or do they need updating? (We will need to work with those
blueprint owners to get the blueprints updated.)

Are we prepared to personally get involved in a media and visibility push?
(e.g. using our own Twitter, networks, getting more people involved in
managing the official Apache Brooklyn social media channels, etc.)

Are we prepared - in the event of a successful media blitz - to handle more
users coming to this list, IRC, Twitter etc. looking for help?


If we can answer "yes" to all of these questions, then we are ready to
release 1.0. If any of these questions is answered "no" or "maybe" then we
should wait, or consider making a 0.13.0 release first.

Richard.


On 3 October 2017 at 16:33, Duncan Godwin  wrote:

> Hi All,
>
> Following the release last week of Apache Brooklyn 0.12.0 I propose that we
> make the next version of Apache Brooklyn 1.0.0.
>
> Apache Brooklyn is robust, stable, feature rich and being used in
> production by multiple enterprises. Our deprecation policy means we haven't
> treated it like a 0.x release in a very long time.
>
> With 0.12.0, we did the last major thing needed before a 1.0 release: we
> switched to Karaf as the primary distribution and we deprecated the
> "classic mode". What does everyone think?
>
> Many thanks
>
> Duncan
>

Re: [VOTE] Release Apache Brooklyn 0.12.0 [rc3]

[Richard Downer]

+1 binding.

Tests:

* Hashes and signatures check out
* Source distribution matches repository tag (apart from excluded files)
* No binary files in source distribution
* `br` client CLI for Linux works
* `deb` artifact works


On 26 September 2017 at 10:06, Mark Mc Kenna  wrote:

> +1 (binding)
>
>
>- Deployed simple app (Jenkins) to [aws, gce, openstack]
>- Checked rebind of the above
>- Eyeballed all the UI views
>
>
> *Mark McKenna*
>
> *Twitter ::* @m4rkmckenna 
>
> *Github :: *m4rkmckenna 
>
> *PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
> *
>
> On 26 September 2017 at 09:14, Светослав Нейков 
> wrote:
>
> > +1 (binding)
> >
> > Tried the .tgz karaf build.
> > Deployed clocker-swarm to AWS successfully, following the instructions
> > on the clocker site. Restarted Brooklyn and rebinded successfully
> > (ignoring the exceptions from
> > https://issues.apache.org/jira/browse/BROOKLYN-539).
> >
> > Svet.
> >
> > 2017-09-25 23:03 GMT+03:00 Duncan Godwin :
> > > +1 (binding)
> > >
> > > I've tested downloading and starting both the RPM and tar.gz
> > distributions
> > > on Linux. I then ran the following blueprints from
> > > https://github.com/brooklyncentral testing each on both GCE and AWS
> and
> > all
> > > tests passed.
> > >
> > > alfresco
> > > ansible
> > > cassandra
> > > cassandra-database-fabric
> > > cassandra-node
> > > couchdb-cluster
> > > couchdb-node
> > > couchdb-v2-node
> > > elasticsearch
> > > elk-elasticsearch
> > > elk-kibana
> > > elk-logstash
> > > etcd
> > > jboss6
> > > jboss7
> > > jenkins
> > > mariadb
> > > mongodb
> > > mysql-master-slave-cluster
> > > mysql-node
> > > nodejs
> > > postgresql-java
> > > postgresql-yaml
> > > rabbitmq
> > > redis
> > > rethinkdb-node
> > > riak-cluster
> > > riak-node
> > > salt
> > > solr
> > > squid
> > > tomcat7
> > > tomcat8
> > > zookeeper
> > > zookeeper-ensemble
> > >
> > > Many thanks
> > >
> > > Duncan
> > >
> > > On 25 September 2017 at 17:40, Aled Sage  wrote:
> > >
> > >> +1 (binding)
> > >>
> > >> I focused mainly on upgrade and rebind testing:
> > >>
> > >>  * I deployed a simple app to AWS, which I susbsequently used for
> > testing.
> > >>  * Tested upgrade from 0.11.0 to 0.12.0-rc3 on CentOS 7.
> > >>(I installed 0.11 and deployed an app, then followed the
> > >>instructions in https://github.com/apache/brooklyn-docs/pull/212
> to
> > >>upgrade.)
> > >>  * Tested upgrade again, where 0.11's catalog included a .bom that
> > >>referenced a bundle.
> > >>  * Restarted Brooklyn a few times (rebinding to its persisted state).
> > >>
> > >> I saw https://issues.apache.org/jira/browse/BROOKLYN-539 (a benign
> > >> exception is logged), but given it is benign we can live with that for
> > this
> > >> release.
> > >>
> > >> Aled
> > >>
> > >>
> > >>
> > >> On 22/09/2017 10:33, Duncan Godwin wrote:
> > >>
> > >>> This is to call for a vote for the release of Apache Brooklyn 0.12.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.12.0-rc3
> > >>>
> > >>> The artifact SHA-256 checksums are as follows:
> > >>>
> > >>>f748ff53ea665a0cabcf42df4ecb346d0f688574286e8a251b37dec282b63a47
> > >>> *apache-brooklyn-0.12.0-rc3-1.noarch.rpm
> > >>>54c85747d3622cac5842adcc738f93da9d160cd8a11f8903583c86363c8a6c4e
> > >>> *apache-brooklyn-0.12.0-rc3-bin.tar.gz
> > >>>f63f6a950d8ea40694988fde3575653653c63808bf9311cbc6bf8c074e28f2b1
> > >>> *apache-brooklyn-0.12.0-rc3-bin.zip
> > >>>de8c2098594edd7e2b60a4a6a44d8b957a7c1b9e7498015e27571e7835054e16
> > >>> *apache-brooklyn-0.12.0-rc3-classic.tar.gz
> > >>>5a913a085e0425f38c50e6a117d0aed7f0624f0f528fc63b5d68266c6036046d
> > >>> *apache-brooklyn-0.12.0-rc3-classic.zip
> > >>>2e3f2acba804b81efa74f71fa48e90965503e8eaf50aecc2b0d14a6f4a08f31a
> > >>> *apache-brooklyn-0.12.0-rc3-client-cli-linux.tar.gz
> > >>>9fef1a73117f568ffeb41da6e4d4cb8ed895b36305df079289f31b3b874d5e4c
> > >>> *apache-brooklyn-0.12.0-rc3-client-cli-linux.zip
> > >>>54004fcec86ff22cea23d460c7e25c243d3a1f67227931adb0067a8611bc1ee3
> > >>> *apache-brooklyn-0.12.0-rc3-client-cli-macosx.tar.gz
> > >>>b2e26523bee04420dadac73989a3265360b30f4041c68ed364c4aaf10e0addee
> > >>> *apache-brooklyn-0.12.0-rc3-client-cli-macosx.zip
> > >>>86a7848f1f1eb81eaa20116df2caa2d80409515a1268b085f6fde828b18b08ac
> > >>> *apache-brooklyn-0.12.0-rc3-client-cli-windows.tar.gz
> > >>>36f14ecbced097561ef9621a28beba6343d96402424974a302560bb429b2685f
> > >>> *apache-brooklyn-0.12.0-rc3-client-cli-windows.zip
> > >>>ed0e89f635501adc8cc347d22a412f29b03

Re: Deprecating `@Catalog` annotation?

[Richard Downer]

+1

On 15 September 2017 at 14:12, Aled Sage  wrote:

> Hi all,
>
> I'd like to deprecate the `@Catalog` annotation [1], and the support for
> `scanFromAnnotations` [2].
>
> Previously, we annotated some entity/policy Java classes with catalog
> information, such as descriptions and icon urls. However, we've moved to
> using .bom files as the way to define catalog items. Therefore the
> `@Catalog` is not normally used.
>
> It is also supported/used by the `./brooklyn list-objects` CLI, to scan
> jars [3]. It find the annotated entities etc, gets the catalog metadata,
> and writes that out in json format. However, I don't think that's what we
> want to do moving forward. We should focus on getting the metadata from the
> .bom files, which is how things should be defined for the catalog.
>
> Any objections to deprecating these?
>
> Aled
>
> [1] https://github.com/apache/brooklyn-server/blob/master/api/
> src/main/java/org/apache/brooklyn/api/catalog/Catalog.java
> [2] https://github.com/apache/brooklyn-server/blob/master/core/
> src/main/java/org/apache/brooklyn/core/catalog/internal/
> CatalogClasspathDo.java#L199-L209
> [3] https://github.com/apache/brooklyn-server/blob/master/server
> -cli/src/main/java/org/apache/brooklyn/cli/ItemLister.java#L88-L94
>
>

Re: Call for release: Brooklyn 0.12.0

[Richard Downer]

+1 to everything so far.

I'd also tempted to ask for Alex's REST API changes for bundle management
merged:
https://lists.apache.org/thread.html/0dd24780fc8491b6c735a7cedeba8c
5fb332c21f208c1cfa7259f012@%3Cdev.brooklyn.apache.org%3E
These seem like an important part of the "easy bundle management for
blueprint developers" story.

Replacing the classic RPM with a Karaf one makes me slightly nervous; I'm
concerned if an `rpm --upgrade` would work from a classic version into a
Karaf version without breaking anything. But I think there are few users
using the RPM, and we are in a 0.x release series, so I would be content if
the release notes described a manual uninstall-old, install-new procedure.

I'm also wondering if there's anything that should be marked "deprecated"
while we have the chance. I think we should aim for Brooklyn 1.0 after this
next release, and so this is our last chance to shine a torch on the legacy
stuff before we hit the big number (and a stricter deprecation policy).
(See also the mailing list link above.)

I had considered if we should call this one "1.0", but that would mean that
we would have to support the classic version for the 1.x series, which is
probably not something we want to do.

Richard.


On 8 September 2017 at 17:15, Thomas Bouron  wrote:

> Hi all
>
> I just pushed a PR for the RPM/DEB packages[1]. It's mostly done but still
> have issue with DEB and upstart.
> I'll try to fix it as quickly as I can.
>
> Best.
>
>
> [1] https://github.com/apache/brooklyn-dist/pull/104
>
> On Fri, 8 Sep 2017 at 12:19 Thomas Bouron  >
> wrote:
>
> > I think it would be confusing for a user to have 2 sets of RPM/DEB
> > packages: one for classic launcher and one for Karaf launcher.
> >
> > I'm in favour of having only one set that uses exclusively the Karaf
> > launcher (also, that mirrors what we had up until now, i.e. only one
> > RPM/DEB set that was using the classic launcher instead of Karaf)
> >
> > Best.
> >
> > On Fri, 8 Sep 2017 at 11:36 Duncan Godwin  om>
> > wrote:
> >
> >> Following on from that, I have made a PR to make the karaf release the
> >> primary one and release the old one as `classic`
> >>
> >> https://github.com/apache/brooklyn-dist/pull/103
> >>
> >> Thanks for your input Thomas. I think that we should only release one
> set
> >> of RPM and deb packages and make those the karaf version in this
> release.
> >> This means that anyone who wants to use the classic version will need to
> >> use the classic tar.gz or zip. What does everyone think?
> >>
> >> Many thanks
> >>
> >> Duncan
> >>
> >>
> >>
> >>
> >> On 7 September 2017 at 17:19, Thomas Bouron <
> >> thomas.bou...@cloudsoftcorp.com
> >> > wrote:
> >>
> >> > Hi Duncan.
> >> >
> >> > I agree, a new version of Brooklyn would be great. I particularly
> >> support
> >> > the change of making Karaf the default distribution.
> >> > I'm actually working on various improvements of the RPM and DEB
> >> packages,
> >> > and make them use Karaf as well. I should push a PR for this next
> week.
> >> >
> >> > Regarding the PR, brooklyn-server/799 has been merged already.
> >> >
> >> > Cheers
> >> >
> >> > On Thu, 7 Sep 2017 at 16:54 Duncan Godwin <
> >> duncan.god...@cloudsoftcorp.com
> >> > >
> >> > wrote:
> >> >
> >> > > Hi All,
> >> > >
> >> > > It's probably about time for a Brooklyn 0.12.0 release. There have
> >> been
> >> > > significant developments since 0.11.0 which warrant a new release.
> >> Before
> >> > > we produce this however I propose we make the following changes:
> >> > >
> >> > > - Make Karaf the default distribution with the current `classic`
> >> launch
> >> > > method depreciated
> >> > > - Update the documentation accordingly
> >> > > - Merge brooklyn-server/805 and probably brooklyn-server/799
> >> > >
> >> > > Are there any other changes which people think should be included?
> >> > >
> >> > > Let us know your opinions and if there are no outstanding problems I
> >> can
> >> > > progress with the release next week.
> >> > >
> >> > > Many thanks
> >> > >
> >> > > Duncan
> >> > >
> >> > --
> >> >
> >> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> >> > https://cloudsoft.io/
> >> > Github: https://github.com/tbouron
> >> > Twitter: https://twitter.com/eltibouron
> >> >
> >>
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Re: Config keys with values that are entities

[Richard Downer]

Thanks Duncan. That bit of the blueprint is working well - the server
cluster is able to come up normally, the first member being the bootstrap
server, and subsequent members able to detect the first and automatically
join the cluster, through the chained attributeWhenReady calls that you
noticed. So it does not look like that is a problem.

I should have been clearer and said that it is the sample-blueprint.yaml
that demonstrates the problem. It uses the catalog items (which can be
added with `br catalog add catalog`).

Thanks
Richard.


On 17 July 2017 at 13:03, Duncan Grant 
wrote:

> Richard,
>
> I haven't quite got my head round what you're doing but I did notice that
> you were chaining attributeWhenReady calls
> https://github.com/rdowner/brooklyn-consul/blob/master/
> catalog/consul/consul-server-cluster.bom#L50
> which
> I don't think you can do as attributeWhenReady returns a
> BrooklynDSLDeferredSupplier.
>
> Could that be related?
>
> cheers
>
> Duncan
>
> On Mon, 17 Jul 2017 at 12:45 Richard Downer  wrote:
>
> > Thanks Alex. Your blueprint is similar to mine, although consul.server in
> > my case is taken from the cluster.first.entity sensor of a
> DynamicCluster.
> > I've uploaded my code to https://github.com/rdowner/brooklyn-consul -
> can
> > you spot anything odd there?
> >
> > Thanks
> > Richard.
> >
> > On 17 July 2017 at 10:58, Alex Heneveld  >
> > wrote:
> >
> > >
> > > Hi Richard-
> > >
> > > What you're doing looks fine.  Maybe something is wrong with the
> > > "consul.serverReference" value, or there is a bug around special
> > treatment
> > > of parameters.  The blueprint below shows what I think you're doing,
> > > several ways, and all work, both in bash and in the config view (IE
> fully
> > > resolved).  If "consul.serverReference" doesn't resolve I see the
> values
> > > you describe and I get a nice error in the Summary view when I try to
> use
> > > it ( Error resolving config consul.serverReference,
> > > $brooklyn:entity("MISSING"), ... NoSuchElementException: No entity
> > matching
> > > id).
> > >
> > > Can you share your blueprint?
> > >
> > > Best
> > > Alex
> > >
> > >
> > > location: localhost
> > > services:
> > > - type: org.apache.brooklyn.entity.software.base.
> VanillaSoftwareProcess
> > >   id: consul.server
> > >   launch.command: |
> > >   echo hello | nc -l 4321 &
> > >   echo $! > $PID_FILE
> > > - type: org.apache.brooklyn.entity.software.base.
> VanillaSoftwareProcess
> > >   launch.command: |
> > >   echo hello | nc -l 4322 &
> > >   echo $! > $PID_FILE
> > >   brooklyn.config:
> > > consul.serverReference: $brooklyn:entity("consul.server")
> > >     shell.env:
> > >   consul_join0: $brooklyn:entity(config("consu
> > > l.serverReference")).attributeWhenReady("entity.id")
> > >   consul_join1: $brooklyn:entity(config("consu
> > > l.join1")).attributeWhenReady("entity.id")
> > >   consul_join2: $brooklyn:config("consul.join2")
> > > consul.join1: $brooklyn:config("consul.serverReference")
> > > consul.join2: $brooklyn:entity(config("consu
> > > l.serverReference")).attributeWhenReady("entity.id")
> > >
> > > END
> > >
> > >
> > >
> > >
> > > On 17/07/2017 09:54, Richard Downer wrote:
> > >
> > >> Hello all.
> > >>
> > >> I have a catalog item for an entity type. This has a number of
> > parameters,
> > >> including one parameter which is intended to hold a reference to an
> > >> entity.
> > >> This works fine; I can see in the "config" pane of the entity this:
> > >>
> > >> consul.serverReference Consul Server (bootstrap)
> > >>
> > >> What I want to do is extract some of the referenced entity's
> attributes
> > >> and
> > >> use them in my entity's blueprint. I'm struggling to find out how to
> do
> > >> that. While experimenting, I've ended up with this in my blueprint:
> > >>
> > >>consul.join1: $brooklyn:config("consul.serverReference")
> > >>consul.join2: $brooklyn:entity(config("consu

Re: Config keys with values that are entities

[Richard Downer]

Thanks Alex. Your blueprint is similar to mine, although consul.server in
my case is taken from the cluster.first.entity sensor of a DynamicCluster.
I've uploaded my code to https://github.com/rdowner/brooklyn-consul - can
you spot anything odd there?

Thanks
Richard.

On 17 July 2017 at 10:58, Alex Heneveld 
wrote:

>
> Hi Richard-
>
> What you're doing looks fine.  Maybe something is wrong with the
> "consul.serverReference" value, or there is a bug around special treatment
> of parameters.  The blueprint below shows what I think you're doing,
> several ways, and all work, both in bash and in the config view (IE fully
> resolved).  If "consul.serverReference" doesn't resolve I see the values
> you describe and I get a nice error in the Summary view when I try to use
> it ( Error resolving config consul.serverReference,
> $brooklyn:entity("MISSING"), ... NoSuchElementException: No entity matching
> id).
>
> Can you share your blueprint?
>
> Best
> Alex
>
>
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
>   id: consul.server
>   launch.command: |
>   echo hello | nc -l 4321 &
>   echo $! > $PID_FILE
> - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
>   launch.command: |
>   echo hello | nc -l 4322 &
>   echo $! > $PID_FILE
>   brooklyn.config:
> consul.serverReference: $brooklyn:entity("consul.server")
> shell.env:
>   consul_join0: $brooklyn:entity(config("consu
> l.serverReference")).attributeWhenReady("entity.id")
>   consul_join1: $brooklyn:entity(config("consu
> l.join1")).attributeWhenReady("entity.id")
>   consul_join2: $brooklyn:config("consul.join2")
> consul.join1: $brooklyn:config("consul.serverReference")
> consul.join2: $brooklyn:entity(config("consu
> l.serverReference")).attributeWhenReady("entity.id")
>
> END
>
>
>
>
> On 17/07/2017 09:54, Richard Downer wrote:
>
>> Hello all.
>>
>> I have a catalog item for an entity type. This has a number of parameters,
>> including one parameter which is intended to hold a reference to an
>> entity.
>> This works fine; I can see in the "config" pane of the entity this:
>>
>> consul.serverReference Consul Server (bootstrap)
>>
>> What I want to do is extract some of the referenced entity's attributes
>> and
>> use them in my entity's blueprint. I'm struggling to find out how to do
>> that. While experimenting, I've ended up with this in my blueprint:
>>
>>consul.join1: $brooklyn:config("consul.serverReference")
>>consul.join2: $brooklyn:entity(config("consu
>> l.serverReference"))
>>consul.join3:
>> $brooklyn:component(config("consul.serverReference"))
>>consul.join4:
>> $brooklyn:config("consul.serverReference").attributeWhenReady("entity.id
>> ")
>>consul.join5:
>> $brooklyn:entity(config("consul.serverReference")).attributeWhenReady("
>> entity.id")
>>consul.join6:
>> $brooklyn:component(config("consul.serverReference")).attrib
>> uteWhenReady("
>> entity.id")
>>
>> None of those are resolving. They appear in the config pane looking like
>> this:
>>
>> consul.join1
>> {"component":{"componentId":"","componentIdSupplier":null,"s
>> copeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"}
>> consul.join2
>> {"componentId":null,"componentIdSupplier":{"component":{"
>> componentId":"","componentIdSupplier":null,"scopeComponent":
>> null,"scope":"THIS"},"keyName":"consul.serverReference"},"sc
>> opeComponent":null,"scope":"GLOBAL"}
>> consul.join3
>> {"componentId":null,"componentIdSupplier":{"component":{"
>> componentId":"","componentIdSupplier":null,"scopeComponent":
>> null,"scope":"THIS"},"keyName":"consul.serverReference"},"sc
>> opeComponent":null,"scope":"GLOBAL"}
>> consul.join4
>> {"object":{"component":{"componentId":"","componentIdSupplie
>> r":null,"scopeComponent":null,"scope":"THIS"},"keyName":"
>> consul.serverReference"},"fnName":"attributeWhenReady","args":["
>> entity.id"]}
>> consul.join5
>> {"component":{"componentId":null,"componentIdSupplier":{"com
>> ponent":{"componentId":"","componentIdSupplier":null,"scopeC
>> omponent":null,"scope":"THIS"},"keyName":"consul.serverRefer
>> ence"},"scopeComponent":null,"scope":"GLOBAL"},"sensorName":"
>> entity.id"}
>> consul.join6
>> {"component":{"componentId":null,"componentIdSupplier":{"com
>> ponent":{"componentId":"","componentIdSupplier":null,"scopeC
>> omponent":null,"scope":"THIS"},"keyName":"consul.serverRefer
>> ence"},"scopeComponent":null,"scope":"GLOBAL"},"sensorName":"
>> entity.id"}
>>
>> Is it possible to do what I want?
>>
>> Thanks
>> Richard.
>>
>>
>

Config keys with values that are entities

[Richard Downer]

Hello all.

I have a catalog item for an entity type. This has a number of parameters,
including one parameter which is intended to hold a reference to an entity.
This works fine; I can see in the "config" pane of the entity this:

consul.serverReference Consul Server (bootstrap)

What I want to do is extract some of the referenced entity's attributes and
use them in my entity's blueprint. I'm struggling to find out how to do
that. While experimenting, I've ended up with this in my blueprint:

  consul.join1: $brooklyn:config("consul.serverReference")
  consul.join2: $brooklyn:entity(config("consul.serverReference"))
  consul.join3:
$brooklyn:component(config("consul.serverReference"))
  consul.join4:
$brooklyn:config("consul.serverReference").attributeWhenReady("entity.id")
  consul.join5:
$brooklyn:entity(config("consul.serverReference")).attributeWhenReady("
entity.id")
  consul.join6:
$brooklyn:component(config("consul.serverReference")).attributeWhenReady("
entity.id")

None of those are resolving. They appear in the config pane looking like
this:

consul.join1
{"component":{"componentId":"","componentIdSupplier":null,"scopeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"}
consul.join2
{"componentId":null,"componentIdSupplier":{"component":{"componentId":"","componentIdSupplier":null,"scopeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"},"scopeComponent":null,"scope":"GLOBAL"}
consul.join3
{"componentId":null,"componentIdSupplier":{"component":{"componentId":"","componentIdSupplier":null,"scopeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"},"scopeComponent":null,"scope":"GLOBAL"}
consul.join4
{"object":{"component":{"componentId":"","componentIdSupplier":null,"scopeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"},"fnName":"attributeWhenReady","args":["
entity.id"]}
consul.join5
{"component":{"componentId":null,"componentIdSupplier":{"component":{"componentId":"","componentIdSupplier":null,"scopeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"},"scopeComponent":null,"scope":"GLOBAL"},"sensorName":"
entity.id"}
consul.join6
{"component":{"componentId":null,"componentIdSupplier":{"component":{"componentId":"","componentIdSupplier":null,"scopeComponent":null,"scope":"THIS"},"keyName":"consul.serverReference"},"scopeComponent":null,"scope":"GLOBAL"},"sensorName":"
entity.id"}

Is it possible to do what I want?

Thanks
Richard.

Catalog adding unexpected behaviour

[Richard Downer]

Hello all,

If I create a catalog.bom with these contents and try to add this to the
catalog with `br catalog add`:

brooklyn.catalog:
  version: 0.1.3.SNAPSHOT
  items:
- id: inner
  itemType: entity
  item:
services:
  - type: server
- id: outer
  itemType: entity
  item:
services:
  - type: inner

it fails with error `Server error (400): Could not resolve item 'outer'; 2
errors including: Transformer for Brooklyn OASIS CAMP interpreter gave an
error creating this plan: Unable to match plan item:
Service[name=,description=,serviceType=inner,characteristics=[],customAttributes={}]`

If I split this into two different catalog.bom files, and add them one
after the other, it works.

It seems to me that what works with two individual catalog.bom files should
also work when both files are combined into one. What do others think about
this?

Changing `entity` for `template` resolves this problem - as I understand
it, `template` causes in-depth parsing to be deferred until something tries
to use the catalog item. Unfortunately that means that some errors in the
catalog item may not be discovered until deployment time.

Richard.

Re: Bundles in Brooklyn

[Richard Downer]

Hi Aled,

On 22 June 2017 at 18:51, Aled Sage  wrote:

> _*Business Case (aka value to end-users)*_
> It would be good to be clearer on the user-value we deliver from this (but
> please shout if others think that is already clear enough).
>

I have a fairly simple use case. At the moment (and I may be using Brooklyn
wrongly) when I'm incrementally developing blueprints and their related
resources in my IDE, I tell Brooklyn to install a BOM file which looks a
bit like this:

brooklyn.catalog:
  brooklyn.libraries:
- name: foo.bar.MyApp
  version: 0.1.0.SNAPSHOT
  url: mvn:foo.bar/myapp/0.1.0-SNAPSHOT
  items:
- "classpath://x.bom"
- "classpath://y.bom"
- "classpath://z.bom"

This installs the bundle and adds multiple BOMs, which in turn install
multiple catalog items.

But if I want to clean up my development work, I have to uninstall all the
catalog items manually, as well as my bundle.

Now the ZIP support is making this easier, but I would like it to be easier
still - I want to install the ZIP, and have all the catalog items magically
appear. I also want to be able to uninstall the ZIP, and have all the
catalog items disappear, everything cleaned up! And I also want this to be
true for Java entities inside OSGI bundles, not just ZIPs.

It's about have a single artifact which is treated as a unit, and
JustWorks(tm) - install it and everything is ready in one go, uninstall it
and everything is cleaned up in one go.

Richard.