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

[John McCabe]

Awesome, congratulations to you all !

On Tue, Feb 25, 2020 at 1:57 PM Geoff Macartney 
wrote:

> Thanks Richard,
>
> That's great news. I don't know about you all but I find this very
> exciting!
>
> Many congratulations to everyone who has contributed to building Apache
> Brooklyn in the first place, and thanks to everyone who's helped pull
> together the fixes and polish for the 1.0.0 release, and especially Richard
> for doing the onerous task of Release Master.
>
> Geoff
>
>
>
> On Tue, 25 Feb 2020 at 07:48, Светослав Нейков 
> wrote:
>
> > Congrats on the 1.0.0 release!
> >
> > A little bit late to the party, but here's one from me as well.
> >
> > +1 (binding)
> >
> > I downloaded the zip package on MacOS and successfully started the
> "Python
> > Web Server" example template on the jclouds-vagrant location.
> >
> > Svet.
> >
> >
> > На вт, 25.02.2020 г. в 8:38 Juan Cabrerizo  написа:
> >
> > > +1 from me.
> > > I run some tests with the zip version on Windows 10 pro
> > >
> > > Juan
> > >
> > > On Fri, 21 Feb 2020 at 16:22, Geoff Macartney <
> geoff.macart...@gmail.com
> > >
> > > wrote:
> > >
> > > > > For the dockerfile not working out-of-the-box with base image
> > > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> > release
> > > > > notes (saying what the simple workaround is). However, I don't
> think
> > > > > this has to be a blocker - we don't use this to release an image to
> > > > > doc>ker hub (or equivalent) as part of the brooklyn release. Also,
> > that
> > > > > dockerfile is a convenience for building (if I understand
> correctly)
> > > > > rather than impacting end-users who are running Brooklyn; the build
> > > > > outside of docker still works.
> > > >
> > > > OK, you have convinced me Aled!  :-)
> > > >
> > > > +1 from me
> > > >
> > > > Geoff
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 21 Feb 2020 at 12:46, Iuliana Cosmina <
> > > > iuliana.cosm...@cloudsoftcorp.com> wrote:
> > > >
> > > > > +1 from me
> > > > >
> > > > > Successfully started unpacked and started
> > > > > apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3.
> All
> > > > nodes
> > > > > were correctly created.
> > > > >
> > > > > Observation:  Since this is a RC release, the
> > files/install_brooklyn.sh
> > > > > had to be modified and the BROOKLYN_URL variable had to be
> explicitly
> > > > set to
> > > > > "
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > > > ”.
> > > > > Because the script seems to be meant to work only with final
> > releases.
> > > > >
> > > > >
> > > > > Also, successfully unpacked and started
> > > > > apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On
> > this
> > > > > instance I tried all templates in the Quick Launch and they all
> > > deployed
> > > > > correctly on AWS instances.  I used Firefox 73.0.2 to access Apache
> > > > > Brooklyn.
> > > > >
> > > > > Observation: for the composed templates ( 3 and 4 use template 2 )
> > the
> > > > > blueprints composer cannot visually display the blueprint because
> it
> > > does
> > > > > not recognise the `locations: []` construct and the workaround is
> to
> > > edit
> > > > > the YAML file and replace it with `location: your_location`, than
> the
> > > > > blueprint is recognised and the visual components are depicted
> > > correctly.
> > > > >
> > > > >
> > > > > Iuliana Cosmina
> > > > > SoftwareEngineer
> > > > >
> > > > > Cloudsoft | Bringing Business to the Cloud
> > > > >
> > > > > E: iuli...@cloudsoft.io
> > > > > M: 07745054173
> > > > > T: _iulianacosmina
> > > > > L: https://www.linkedin.com/in/iulianacosmina/
> > > > > On 21 Feb 2020, 10:42 +, Aled Sage ,
> wrote:
> > > > > > +1 from me.
> > > > > >
> > > > > > I did some exploratory testing on OS X with the tar.gz, and
> > deployed
> > > a
> > > > > > few blueprints.
> > > > > >
> > > > > > --
> > > > > >
> > > > > > For the dockerfile not working out-of-the-box with base image
> > > > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> > > release
> > > > > > notes (saying what the simple workaround is). However, I don't
> > think
> > > > > > this has to be a blocker - we don't use this to release an image
> to
> > > > > > docker hub (or equivalent) as part of the brooklyn release. Also,
> > > that
> > > > > > dockerfile is a convenience for building (if I understand
> > correctly)
> > > > > > rather than impacting end-users who are running Brooklyn; the
> build
> > > > > > outside of docker still works.
> > > > > >
> > > > > > Aled
> > > > > >
> > > > > >
> > > > > > On 18/02/2020 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.
> > > > > > >
> > > > > > > 

Re: Brooklyn 1.0.0 release candidate?

[John McCabe]

Congratulations all, great to see!!

On Fri, Jan 17, 2020, 4:16 PM Richard Downer  wrote:

> +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: go version on Jenkins

[John McCabe]

You should definitely go with the library golang image as a builder rather
than rely on external configuration in the CI executors.

This is what we use in OpenFaaS
https://github.com/openfaas/faas-cli/blob/master/Dockerfile.redist

On Fri, Aug 9, 2019, 5:39 PM Geoff Macartney 
wrote:

> Ah, I'm looking at the pull request job
>
> https://builds.apache.org/view/B/view/Brooklyn/job/brooklyn-client-pull-requests/
>
> That's a bit of a mismatch perhaps, doing one in Docker and the other not.
> At the very least we would need to keep the build environments matching,
> i.e. ensure that toolchain versions are the same between the jobs.
>
> Regarding the version of Go, am I right in thinking that the Go version is
> coming simply from the build node? We just specify label "ubuntu", and the
> builds look like they are done on Xenial nodes, for which the default
> version of Go is 1.6.2.  If we want a higher version then our only current
> option on Jenkins is to specify ubuntu&, which will give us a
> default version of Go of 1.10.4.  (Also there are only three build nodes
> for general project use at that version of Ubuntu, but I guess that's ok.)
>
>
>
>
>
> On Fri, 9 Aug 2019 at 17:13, Duncan Grant 
> wrote:
>
> > I think it is done with docker.  I'm looking at jobs like
> >
> >
> https://builds.apache.org/view/B/view/Brooklyn/job/brooklyn-client-master-docker/
> >  and
> >
> >
> https://builds.apache.org/view/B/view/Brooklyn/job/brooklyn-master-build-docker/
> > .
> > Unless those are the wrong jobs.
> >
> > On Fri, 9 Aug 2019 at 17:10, Geoff Macartney 
> > wrote:
> >
> > > I don't think the build is done with Docker is it? The Jenkins job
> Build
> > > step is just configured to run mvn clean install, so presumably uses
> the
> > > locally installed Go on the build machine.  I don't know anything much
> > how
> > > that aspect of things works though. How can we change the Go version,
> and
> > > how to do so without affecting anyone else?
> > >
> > > G
> > >
> > > On Fri, 9 Aug 2019 at 16:52, Duncan Grant 
> > > wrote:
> > >
> > > > So the CLI part of the build worked with the updated image.  But the
> > > build
> > > > is either hanging or failing during the UI build with an npm update
> > > error.
> > > > I'll try to look into that over the weekend.
> > > >
> > > > On Fri, 9 Aug 2019 at 11:03, Duncan Grant  >
> > > > wrote:
> > > >
> > > > > I'm not totally sure how the jenkins build is set up but I assume
> it
> > is
> > > > > using a docker image built using the Dockerfile in apache/brooklyn?
> > > > > If I try to build that locally I end up with an image with Docker
> > 1.7.4
> > > > so
> > > > > possibly as a quick fix we could replace the current image with an
> > > > updated
> > > > > one.
> > > > > But is is installing docker using apt-get install do-lang so I
> assume
> > > it
> > > > > would be a bigger change to move to 1.12.
> > > > >
> > > > > I'll try running the build locally against Geoff's PR using the
> > docker
> > > > > image I just built to check whether that works.  That way we can
> > > consider
> > > > > splitting the big version change out into a separate change.
> > > > >
> > > > > On Fri, 9 Aug 2019 at 10:50, John McCabe 
> > wrote:
> > > > >
> > > > >> Regarding Go, I'd be inclined to jump to 1.12 asap.
> > > > >>
> > > > >> On Fri, Aug 9, 2019, 9:34 AM Geoff Macartney <
> > > geoff.macart...@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> > Hm that's a thought. I'll look at that, but the question on Go
> > > version
> > > > >> > still stands, I'd say, irrespective of this particular issue.
> What
> > > do
> > > > >> you
> > > > >> > think?
> > > > >> >
> > > > >> > G
> > > > >> >
> > > > >> > On Fri, 9 Aug 2019 at 00:16, John McCabe 
> > > wrote:
> > > > >> >
> > > > >> > > Hi Geoff,
> > > > >> > > Have you looked at the jsonpath package used by kubernetes.
> > > > >> > >
> > > > >> > >
> 

Re: go version on Jenkins

[John McCabe]

Regarding Go, I'd be inclined to jump to 1.12 asap.

On Fri, Aug 9, 2019, 9:34 AM Geoff Macartney 
wrote:

> Hm that's a thought. I'll look at that, but the question on Go version
> still stands, I'd say, irrespective of this particular issue. What do you
> think?
>
> G
>
> On Fri, 9 Aug 2019 at 00:16, John McCabe  wrote:
>
> > Hi Geoff,
> > Have you looked at the jsonpath package used by kubernetes.
> >
> > https://github.com/kubernetes/client-go/tree/master/util/jsonpath
> >
> > It may be a better choice than an implementation with a single
> contributor.
> > Best,
> > John
> >
> >
> > On Thu, Aug 8, 2019 at 10:48 PM Geoff Macartney <
> geoff.macart...@gmail.com
> > >
> > wrote:
> >
> > > Hi all,
> > >
> > > I raised https://github.com/apache/brooklyn-client/pull/78 to update
> the
> > > jsonpath package (following the changes back in
> > > https://github.com/apache/brooklyn-client/pull/68), but I see the
> build
> > > has
> > > broken on Jenkins. It turns out the package I wanted to use requires Go
> > 1.7
> > > at least, see comment on PR. We currently use Go 1.6 on Jenkins.
> > >
> > > I think it's probably about time we updated to a more recent Go anyway.
> > > Would anyone object if I updated the README to specify a more recent
> > > version? Could jump to the current 1.12, or just go as far as 1.11?
> > >
> > > If that's OK, how do we go about getting the version of Go on the
> > > build.apache.org Jenkins servers updated?
> > >
> > > Geoff
> > >
> >
>

Re: go version on Jenkins

[John McCabe]

Hi Geoff,
Have you looked at the jsonpath package used by kubernetes.

https://github.com/kubernetes/client-go/tree/master/util/jsonpath

It may be a better choice than an implementation with a single contributor.
Best,
John


On Thu, Aug 8, 2019 at 10:48 PM Geoff Macartney 
wrote:

> Hi all,
>
> I raised https://github.com/apache/brooklyn-client/pull/78 to update the
> jsonpath package (following the changes back in
> https://github.com/apache/brooklyn-client/pull/68), but I see the build
> has
> broken on Jenkins. It turns out the package I wanted to use requires Go 1.7
> at least, see comment on PR. We currently use Go 1.6 on Jenkins.
>
> I think it's probably about time we updated to a more recent Go anyway.
> Would anyone object if I updated the README to specify a more recent
> version? Could jump to the current 1.12, or just go as far as 1.11?
>
> If that's OK, how do we go about getting the version of Go on the
> build.apache.org Jenkins servers updated?
>
> Geoff
>

Re: Website question

[John McCabe]

Geoff, have you tried using Docker rather than install locally.

This has worked well for the OpenFaaS site -
https://github.com/openfaas/openfaas.github.io/blob/master/docker-compose.yml

On Wed, Mar 20, 2019, 1:56 PM Thomas Bouron 
wrote:

> Hey Geoff.
>
> I'm on the same boat as you, but I managed to recompile ruby 2.1.2 with
> open ssl using:
>
> rvm reinstall 2.1.2 --with-opt-dir=/usr/local
> --with-openssl-dir=/usr/local/opt/openssl
> (OpenSSL has been installed with brew)
>
> `bundle install` does not complain anymore about openssl. However, it fails
> to install nokogiri even though I have the XCode CLI:
>
> ```
> Installing nokogiri 1.6.5 with native extensions
> Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
>
> current directory:
> /Users/thomasbouron/.rvm/gems/ruby-2.1.2@brooklyn-site
> /gems/nokogiri-1.6.5/ext/nokogiri
> /Users/thomasbouron/.rvm/rubies/ruby-2.1.2/bin/ruby -r
> ./siteconf20190320-3453-1vglirq.rb extconf.rb
> checking if the C compiler accepts ... yes
> checking if the C compiler accepts
> -Wno-error=unused-command-line-argument-hard-error-in-future... no
> Building nokogiri using packaged libraries.
> -
> The file "/usr/include/iconv.h" is missing in your build environment,
> which means you haven't installed Xcode Command Line Tools properly.
>
> To install Command Line Tools, try running `xcode-select --install` on
> terminal and follow the instructions.  If it fails, open Xcode.app,
> select from the menu "Xcode" - "Open Developer Tool" - "More Developer
> Tools" to open the developer site, download the installer for your OS
> version and run it.
> -
> *** extconf.rb failed ***
> Could not create Makefile due to some reason, probably lack of necessary
> libraries and/or headers.  Check the mkmf.log file for more details.  You
> may
> need configuration options.
> ```
>
> On Wed, 20 Mar 2019 at 00:16 Peter Abramowitsch 
> wrote:
>
> > Hi Geoff
> >
> > Not that long ago I was using a much more recent ruby with openssl.
> >
> >
> > I'm running 2.3.2 and just re-installed openssl
> >
> > cogitext:~ peterabramowitsch$ rvm list
> > rvm rubies
> > =* ruby-2.3.2 [ x86_64 ]
> > # => - current
> > # =* - current && default
> > #  * - default
> >
> >
> > cogitext:~ peterabramowitsch$ gem list openssl
> > *** LOCAL GEMS ***
> > openssl (2.1.2)
> >
> > The gemsite can function with http or https, I think yours is an issue
> > with bundler which I've seen before which is caused by a kind of
> > catch-22.   It needs ssl to do a download of openssl which it needs to
> > do the download.
> >
> > Fix 1.
> > Change the first line of the gemfile to http:
> > source 'http://rubygems.org'
> > And now do a bundle install
> > After a successful bundle install you might be able to change it back
> >
> > Fix 2.
> > manually install openssl  via "gem install openssl"
> > and then your bundle install should work correctly
> >
> >
> >
> > -P.
> >
> > Sent from my iPad
> >
> >
> > > On Mar 19, 2019, at 16:38, Geoff Macartney 
> > wrote:
> > >
> > > Hi all,
> > >
> > > I made a start to adding changes to the Apache Brooklyn website to
> > comply with Apache Foundation naming guidelines, wip is at [1].
> > >
> > > However I’ve run into a problem trying to test it with Jekyll, which I
> > haven’t installed on this machine up to now (it’s a MacBook Pro). I’ve
> > added the version of Ruby that’s required (very old now, 2.1.2) via rvm,
> > but when I run the “bundle install” per the docs at [2] I get complaints
> > about openssl.
> > >
> > > This is even when I install 2.1.2 with
> > >
> > > rvm install 2.1.2 --with-opt-dir=/usr/local --with-openssl
> > >
> > > Despite requesting openssl, when I do bundle install I get
> > >
> > > $ bundle install
> > > Could not load OpenSSL.
> > > You must recompile Ruby with OpenSSL support or change the sources in
> > your Gemfile from 'https' to 'http'. Instructions for compiling with
> > OpenSSL using RVM are
> > > available at rvm.io/packages/openssl.
> > >
> > > I’m loth to start building 2.1.2 from source just to get the openssl
> > support, before I launch into that has anyone encountered this problem or
> > can advise on an alternative approach?
> > >
> > > Cheers
> > > Geoff
> > >
> > > [1] https://github.com/apache/brooklyn-docs/pull/280
> > > [2]
> > https://github.com/apache/brooklyn-docs/tree/website#workstation-setup
> > >
> >
> --
> 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: [VOTE] New Angular UI for Brooklyn

[John McCabe]

This is fantastic news, congrats to all involved !!

On Thu, Jul 26, 2018 at 11:54 AM Alex Heneveld <
alex.henev...@cloudsoftcorp.com> wrote:

>
> Thanks Richard, Thomas.
>
> i have done as you suggest, pushing from a merged branch directly to
> master.  [1] is the result of `mkdir new ; cd new ;  curl
>
> https://issues.apache.org/jira/secure/attachment/12932670/brooklyn-ui-angular.tgz
> | tar xvz`.  [2] is a few minor RAT/license header tweaks needed.
>
> I confirm that `mvn clean install` now works:
>
> * At `brooklyn-ui/` (root) to build the old UI with no errors
> * In `brooklyn-ui-new/` to build the new UI with no errors
>
> The next will be a set of linked PRs to replace `/brooklyn-ui/` with
> `/brooklyn-ui/new/`, and update all related code and documentation.
>
> Best
> Alex
>
> [1]
>
> https://github.com/apache/brooklyn-ui/commit/29927b734a8db268814ea180c1d117858a747c3c
> [2]
>
> https://github.com/apache/brooklyn-ui/commit/9b8bb9c156368143219c13ecbdeb5d1ba1e60b3b
>
>
> On 26/07/2018 11:19, Richard Downer wrote:
> > 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 <
> thomas.bou...@cloudsoftcorp.com>
> > 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 

Re: Making First Contact

[John McCabe]

o>
> > > :
> > > >
> > > > > One thing to think about I have noted in a comment here:
> > > > > https://issues.apache.org/jira/browse/BROOKLYN-575?
> > > > > focusedCommentId=16393594=com.atlassian.jira.
> > > > > plugin.system.issuetabpanels:comment-tabpanel#comment-16393594
> > > > >
> > > > > Something to think about for this proposal  - we should avoid
> > thinking
> > > > that
> > > > > the idea is to reproduce the current interface using more modern
> > > > > technologies. This is an opportunity to rethink the structure of
> the
> > > user
> > > > > interface, irrespective of the technology. The current interface
> > > > presents a
> > > > > fairly data-structure oriented view of applications, drilling down
> > > > through
> > > > > nested entity structures and presenting tables of properties and
> > action
> > > > > records.  This might be an opportunity to introduce a new structure
> > > using
> > > > > modern ideas of UI design, thinking about how to highlight what's
> > > > important
> > > > > to users and present that in a human-oriented way.  For example
> when
> > > > there
> > > > > are errors in activities it should not require a long series of
> > clicks
> > > to
> > > > > navigate to them, rather the errors should be visible without any
> > > clicks
> > > > or
> > > > > with just one. Sensors are probably the most important aspects of
> > > > entities
> > > > > so good presentation of sensors is important.  I'm no sort of UI
> > expert
> > > > but
> > > > > perhaps there are some out there who could help design the new UI.
> > > > >
> > > > > regards
> > > > > Geoff
> > > > >
> > > > > On Fri, 9 Mar 2018 at 16:59 Mert Kahyaoğlu <bytecod...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Thank you so much John and Thomas for your time and wishes.
> > > > > >
> > > > > > Thomas, I really appreciate your feedback. Those are great
> > > suggestions
> > > > to
> > > > > > add to my proposal. I will think over them and update my proposal
> > > > > > accordingly.
> > > > > >
> > > > > > Many thanks,
> > > > > > Mert
> > > > > >
> > > > > > 2018-03-09 17:34 GMT+03:00 Thomas Bouron
> > > <thomas.bouron@cloudsoftcorp.
> > > > > com
> > > > > > >:
> > > > > >
> > > > > > > Another thing to consider (I meant to add it to the list but
> send
> > > my
> > > > > > email
> > > > > > > too quickly): you plan to use Brace for the YAML editor. Any
> > reason
> > > > for
> > > > > > > that? What about browsers compatibility?
> > > > > > >
> > > > > > > That's it for me, I let you think about it :)
> > > > > > >
> > > > > > > Best.
> > > > > > >
> > > > > > > On Fri, 9 Mar 2018 at 14:29 Thomas Bouron <
> > > > > > thomas.bou...@cloudsoftcorp.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Mert.
> > > > > > > >
> > > > > > > > Thanks for sharing your proposal, that looks really good!
> > > > > > > > I quite like that you went the extra-mile to make a quick
> > > prototype
> > > > > > > (which
> > > > > > > > also looks good BTW)
> > > > > > > >
> > > > > > > > May I suggest few things that you could add to improve your
> > > > proposal:
> > > > > > > > - you want to use React + Redux stack but what about other
> > > > frameworks
> > > > > > > > available like Angular? Would be great to know why you think
> > > React
> > > > is
> > > > > > the
> > > > > > > > right tool for the job
> > > > > > > > - same question for the CSS framework (looks like Ant design
> is
> > > > very

Re: Failing Go build: NodePrime/jsonpath missing?

[John McCabe]

@Geoff, I recommend vendoring dependencies while you're addressing this.
I've switched from glide to dep in recent months for this and its pretty
painless.

On Fri, 23 Mar 2018 at 10:52 John McCabe <j...@johnmccabe.net> wrote:

> There may be something odd going on with that Github account, the linked
> website is flagged as a security threat by Cisco Umbrella on the corp
> network here [1].
>
> 1 - https://i.imgur.com/jTZlRUH.png
>
>
>
> On Fri, 23 Mar 2018 at 10:04 Geoff Macartney <geoff.macart...@cloudsoft.io>
> wrote:
>
>> Let's give them a bit of time to reply, hopefully it is just a mistake, as
>> you say.  I had a look and while there are other JSONPath golang libs out
>> there, this seems to be the one most highly recommended, so it would be a
>> bit of a shame to lose it.
>>
>> Geoff
>>
>> On Fri, 23 Mar 2018 at 09:54 Thomas Bouron <
>> thomas.bou...@cloudsoftcorp.com>
>> wrote:
>>
>> > Geoff, I asked them if it was intentional for the lib to go dark and if
>> so,
>> > if they know a suitable replacement for it.
>> > I hope it's just a mistake from them, like making the repo private so
>> > hopefully, it will fix itself soon.
>> >
>> > But if you want to take a look by replacing the lib, go for it, you know
>> > the CLI better than anyone ;)
>> >
>> > Best.
>> >
>> > On Fri, 23 Mar 2018 at 09:36 Geoff Macartney <
>> geoff.macart...@cloudsoft.io
>> > >
>> > wrote:
>> >
>> > > hi all,
>> > >
>> > > I can have a look at this, unless anyone else has already picked it
>> up?
>> > >
>> > > Geoff
>> > >
>> > > On Thu, 22 Mar 2018 at 11:28 Richard Downer <rich...@apache.org>
>> wrote:
>> > >
>> > > > 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 <aled.s...@gmail.com> 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
>> > &

Re: Failing Go build: NodePrime/jsonpath missing?

[John McCabe]

There may be something odd going on with that Github account, the linked
website is flagged as a security threat by Cisco Umbrella on the corp
network here [1].

1 - https://i.imgur.com/jTZlRUH.png



On Fri, 23 Mar 2018 at 10:04 Geoff Macartney 
wrote:

> Let's give them a bit of time to reply, hopefully it is just a mistake, as
> you say.  I had a look and while there are other JSONPath golang libs out
> there, this seems to be the one most highly recommended, so it would be a
> bit of a shame to lose it.
>
> Geoff
>
> On Fri, 23 Mar 2018 at 09:54 Thomas Bouron <
> thomas.bou...@cloudsoftcorp.com>
> wrote:
>
> > Geoff, I asked them if it was intentional for the lib to go dark and if
> so,
> > if they know a suitable replacement for it.
> > I hope it's just a mistake from them, like making the repo private so
> > hopefully, it will fix itself soon.
> >
> > But if you want to take a look by replacing the lib, go for it, you know
> > the CLI better than anyone ;)
> >
> > Best.
> >
> > On Fri, 23 Mar 2018 at 09:36 Geoff Macartney <
> geoff.macart...@cloudsoft.io
> > >
> > wrote:
> >
> > > hi all,
> > >
> > > I can have a look at this, unless anyone else has already picked it up?
> > >
> > > Geoff
> > >
> > > On Thu, 22 Mar 2018 at 11:28 Richard Downer 
> wrote:
> > >
> > > > 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:
> > > > >  

Re: Making First Contact

[John McCabe]

Looking good, best of luck with this Mert!!

On Thu, 8 Mar 2018 at 19:32 Mert Kahyaoğlu  wrote:

> Hi everyone,
>
> I prepared my proposal and wanted to share it with you. Your feedback is
> highly appreciated and will help me improve my proposal.
>
> Looking forward to hearing from you.
>
> Here is the link:
> https://gist.github.com/mertkahyaoglu/6836223c91f4b59c277663942b80f044
>
> Cheers,
> Mert
>
> 2018-03-06 19:28 GMT+03:00 Thomas Bouron  >:
>
> > Hi Mert.
> >
> > Welcome to the Apache Brooklyn community! I'm very excited to see your
> > proposal.
> > Don't hesitate to share it here before the official start of GSoC, if
> > ready.
> >
> > Best.
> >
> > On Tue, 6 Mar 2018 at 14:41 Mark McKenna  wrote:
> >
> > > Hi Mert,
> > > This sounds great ... looking forward to your proposal
> > >
> > > *Mark McKenna*
> > >
> > > *Twitter ::* @m4rkmckenna 
> > >
> > > *Github :: *m4rkmckenna 
> > >
> > > *PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
> > > *
> > >
> > > On 6 March 2018 at 13:05, Mert Kahyaoğlu  wrote:
> > >
> > > > Hi Duncan,
> > > >
> > > > Thanks so much for your response. Yes, I'm still preparing my
> proposal
> > > and
> > > > there are more details on it. I'm also developing a demo application
> > > beside
> > > > my proposal to show which technologies I'm planning to use for the
> > > project.
> > > >
> > > > Actually I was planning to share it on March 12 as it is scheduled on
> > the
> > > > GSoC website but I'm happy to share it with the community as soon as
> I
> > > > complete and get the community feedback about it to improve it even
> > > more. I
> > > > will let you know when I complete my proposal.
> > > >
> > > > Looking forward to get in touch.
> > > >
> > > > Cheers,
> > > > Mert
> > > >
> > > > 2018-03-06 12:51 GMT+03:00 Duncan Grant :
> > > >
> > > > > Hello Mert,
> > > > >
> > > > > Welcome to the Apache Brooklyn project.
> > > > >
> > > > > This sounds really exciting.  Are there more details on your
> proposal
> > > > > somewhere?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Duncan Grant
> > > > >
> > > > > On Mon, 5 Mar 2018 at 20:57 Mert Kahyaoğlu 
> > > wrote:
> > > > >
> > > > > > Hello Brooklyn developers,
> > > > > >
> > > > > > I would like to introduce myself. I'm Mert Kahyaoğlu from Turkey.
> > > I'm a
> > > > > > graduate student studying Bioinformatics at Mugla University.
> I'm a
> > > > GSoC
> > > > > > 2016 student and would love to attend this year's program as
> well.
> > > > > >
> > > > > > Apache Brooklyn excited me a lot when I first saw it on the
> project
> > > > list
> > > > > of
> > > > > > Apache Community. I really would like to work on developing a
> brand
> > > new
> > > > > UI
> > > > > > for Apache Brooklyn because not only I love crafting user
> > interfaces
> > > > but
> > > > > > also it motivates me to work on a project like Apache Brooklyn
> > which
> > > > will
> > > > > > have a direct impact on the community and makes people's life a
> lot
> > > > > easier.
> > > > > >
> > > > > > I already started working on the project. I built the
> application,
> > > > > > investigated the current Brooklyn UI and discovered the REST API
> > > > > endpoints.
> > > > > >
> > > > > > Looking forward to working with the Brooklyn community.
> > > > > >
> > > > > > Cheers,
> > > > > > Mert
> > > > > >
> > > > >
> > > >
> > >
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>

Re: [PROPOSAL] Using docker for jenkins builds

[John McCabe]

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
> > >
> >
>

Re: [ANNOUNCE] New committer: Thomas Bouron

[John McCabe]

Very well deserved, congratulations Thomas !!

On Thu, 5 Oct 2017 at 10:23 Richard Downer  wrote:

> 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
> >
>

Re: Missing .deb packaging for 0.11.0

[John McCabe]

Cool, thanks Richard, the RPM release works fine, was just looking at the
.deb as I'm in the habit of going Debian first.

On Wed, 31 May 2017 at 14:19 Rupinder Singh <rupi@gmail.com> wrote:

> Richard, thanks!
> On 31 May 2017 17:41, "Richard Downer" <rich...@apache.org> wrote:
>
> > Hmm, this is awkward. We don't release a `.deb` artifact (it's not been
> in
> > any of our recent releases).
> >
> > But if we are documenting that we do have a .deb - and since we do
> actually
> > produce a .deb in the build - we should really release that.
> >
> > I've raised this in JIRA as BROOKLYN-511 [1]
> >
> > [1] https://issues.apache.org/jira/browse/BROOKLYN-511
> >
> > On 27 May 2017 at 11:27, John McCabe <j...@johnmccabe.net> wrote:
> >
> > > Hey,
> > > Noticed that the apache-brooklyn_0.11.0_noarch.deb deb package is
> > missing.
> > > It doesn't appear to exist on any of the mirrors accessible from:
> > >
> > > https://www.apache.org/dyn/closer.lua/brooklyn/apache-
> > > brooklyn_0.11.0_noarch.deb
> > >
> > > Its referenced from the Getting Started for Debian/Ubuntu.
> > >
> > > All the best,
> > > John
> > >
> >
>

Missing .deb packaging for 0.11.0

[John McCabe]

Hey,
Noticed that the apache-brooklyn_0.11.0_noarch.deb deb package is missing.
It doesn't appear to exist on any of the mirrors accessible from:

https://www.apache.org/dyn/closer.lua/brooklyn/apache-brooklyn_0.11.0_noarch.deb

Its referenced from the Getting Started for Debian/Ubuntu.

All the best,
John

Re: [ANNOUNCE] Apache Brooklyn 0.11.0 released

[John McCabe]

The client on brew has been updated:

https://github.com/Homebrew/homebrew-core/commit/2f9e055be68ccce267477fe38d957d0f65119e1f
https://github.com/Homebrew/homebrew-core/commit/cc78a8539c0de48a2005a58ce736e5edb9a863f8

On Thu, 18 May 2017 at 13:55 Richard Downer  wrote:

> The Apache Brooklyn team is proud to announce the latest release of Apache
> Brooklyn 0.11.0.
>
> Apache Brooklyn is a framework for modelling, deploying, and managing
> applications through autonomic blueprints. More details on Apache Brooklyn
> can be found at https://brooklyn.apache.org/
>
> As well as a source code release, we offer a full binary distribution
> download, and a full set of Maven artifacts for developers.
>
> Release notes:
> https://brooklyn.apache.org/v/0.11.0/misc/release-notes.html
>
> Download:
> https://brooklyn.apache.org/download/
>
> User guide:
> https://brooklyn.apache.org/v/0.11.0/
>
> Maven artifacts have also been made available on repository.apache.org and
> Maven Central.
>
> Thanks
> Richard Downer
> release manager for 0.11.0
> on behalf of the Brooklyn PMC
>

Re: Code Contribution: Container Service

[John McCabe]

+1, it's awesome!!

On Wed, 10 May 2017, 13:22 Geoff Macartney, <
geoff.macart...@cloudsoftcorp.com> wrote:

> +1
>
> I'm planning to do a talk on Brooklyn next month and it would be great to
> be able to use Kubernetes in an example Blueprint.
>
>
>
> On Wed, 10 May 2017 at 13:16 Graeme Miller <
> graeme.mil...@cloudsoftcorp.com>
> wrote:
>
> > Hello,
> >
> > We at Cloudsoft Corporation have spent some time developing functionality
> > on top of Brooklyn that allows a user to deploy to Swarm, Kubernetes and
> > Openshift. We call this functionality the Cloudsoft Container Service.
> >
> > We'd like to contribute this code back to Apache Brooklyn. The code comes
> > complete with documentation and tests and has been well reviewed by
> people
> > within Cloudsoft. We view this as mature code, that has been shipped with
> > our product for some time.
> >
> > To find more information about how a user would use these locations
> please
> > see this documentation[1].
> >
> > If people are in favour of this, we can provide more deatails about the
> > code and put it to a vote.
> >
> > Regards,
> > Graeme Miller
> >
> > [1] https://docs.cloudsoft.io/ccs/locations/index.html
> >
>

Re: [ANNOUNCE] Mark McKenna join as Apache Brooklyn committer and PMC member

[John McCabe]

Congratulations Mark !!

On Mon, 8 May 2017 at 10:07 Thomas Bouron 
wrote:

> Congratulations Mark!
>
> On Mon, 8 May 2017 at 09:15 Ivana Yovcheva <
> ivana.yovch...@cloudsoftcorp.com>
> wrote:
>
> > Congratulations Mark!
> >
> > Ivana Yovcheva
> > Software Engineer
> > Cloudsoft Corporation Ltd.
> > www.cloudsoft.io
> >
> > On 8 May 2017 at 11:09, Richard Downer  wrote:
> >
> > > All,
> > >
> > > You may have noticed recently m4rkmckenna making commits and merging
> pull
> > > requests; Mark became a committer on 30th March at the invitation of
> the
> > > Apache Brooklyn PMC[1].
> > >
> > > Furthermore, last week the PMC decided to invite Mark to join the
> > > committee, which he accepted, so he is now a member of the PMC.
> > >
> > > Please join me in welcoming Mark!
> > >
> > > Richard Downer
> > > Chair, Apache Brooklyn PMC
> > >
> > >
> > > [1] PMC is the Project Management Committee. A project management
> > committee
> > > (PMC) is a committee of the Apache Software Foundation charged with
> > > responsibility and governance for their top level project. The PMC is
> the
> > > vehicle through which decision making power and responsibility for
> > > oversight is devolved to developers. For more information see
> > > https://www.apache.org/dev/pmc.html.
> > >
> >
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Re: Brooklyn website

[John McCabe]

+1 on Thomas's mock up, looks great.

Being able to see something in action before trying it can be useful,
perhaps something asciinema-like (https://asciinema.org/a/46498).

On Tue, 18 Apr 2017 at 08:21 Thomas Bouron 
wrote:

> On Tue, 18 Apr 2017 at 00:32 Alex Heneveld <
> alex.henev...@cloudsoftcorp.com>
> wrote:
>
> >
> > Wow - really like this!  Very clean and elegant.
> >
>
> Thanks!
>
>
> > I think we should /show/ a little bit more what we mean by
> > modeling/deploying/managing -- eg for modelling (code snippet), and a
> > graphic w cloud icons for deploy, and maybe a UI screenshot for manage ?
> >
>
> I'm not sure I agree with that. I deliberately went for less because I
> believe less is more, especially on the homepage. Adding a code snippet,
> screenshots abd logos will do the reverse IMO. You started this thread by
> saying that Brooklyn is always considered as complicated, doing this will
> reinforce this feeling IMO.
>
> That being said, we could add a page to have a UI tour, with a link to it
> in the "Get Started" menu item?
>
>
> > And not sure about curl-to-bash for install -- some people are
> > uncomfortable with that (in any case we should curl from an apache site
> > for a release, not github).
>
>
> I used github as an example, this is not a real URL.
>
>
> > But some one-line quick start would be
> > nice.  A docker image?  (And can say jump to Get Started for other
> > flavours of installs.)
> >
>
> Why not for the docker image. I went for the curl command because that's
> the only one that does not require the user to install anything else. If
> you think about it, a quick start guide that starts by "Install docker" or
> "Install vagrant AND VirtualBox" is far from a great way to start for a
> first-time Brooklyn user. Now I might be wrong about this and if it is the
> case, then I'm happy to change it (again, that's just a prototype)
> Regarding the other flavours of install, it's specified in a link, below
> the shell command ;)
>
> Lastly instead of the brooklyn logo font, can you just use the big logo
> > PNG that is currently in use on the site?
>
>
> I could do that but:
>
>1. the quality is not as nice as pure text
>2. from an semantic/SEO point of view, it's better to use the text as
>crawler will be able to read it
>
> Also, I don't know if you noticed but I rearranged the menu items. I was
> planning to do this + update all the web dependencies i.e. bootstrap,
> jquery, etc
>
> Best
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

[jira] [Created] (BROOKLYN-443) 0.10.0 and 0.11.0 snapshot docs links 404'ing

[John McCabe (JIRA)]

John McCabe created BROOKLYN-443:


 Summary: 0.10.0 and 0.11.0 snapshot docs links 404'ing
 Key: BROOKLYN-443
 URL: https://issues.apache.org/jira/browse/BROOKLYN-443
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Minor


Attempting to access the snapshot docs site for 0.10.0 or 0.11.0 results in a 
404.

Browsing from -  https://brooklyn.apache.org/meta/versions.html

Browsing to - https://brooklyn.apache.org/v/0.11.0-SNAPSHOT/, 
https://brooklyn.apache.org/v/0.10.0-SNAPSHOT/

Best,
John



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Beginner's issue in launching brooklyn from vagrant

[John McCabe]

Hi Rupinder,
I think you've added Svets suggested config update in the wrong place. It
should be added in the following block (note you're just adding the
vb.customize here):

  server_config.vm.provider :virtualbox do |vb|
vb.name = server["name"]
vb.memory = server["ram"]
vb.cpus = server["cpus"]
vb.customize ["modifyvm", :id, "--hwvirtex", "off"]
  end

Make sure to remove your earlier changes.

(Note: I don't have a non-VT-X system to validate this on)

/John

On Sat, 25 Feb 2017 at 00:57 Rupinder Singh  wrote:

attachments, which I missed in earlier email, here.

On Sat, Feb 25, 2017 at 5:57 AM, Rupinder Singh  wrote:

Hi Svet,
Thanks for your continued support.
I tried to change Vagrantfile as attached here in raw. The output remains
as before as attached here.

Rupinder

On Fri, Feb 24, 2017 at 9:42 PM, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

Hi rupinder,

In the Vagrantfile try to disable virtualization. Insert the following
before the end of the configure section [1]:

config.vm.provider :virtualbox do |vb|
  vb.customize ["modifyvm", :id, "--hwvirtex", "off"]
end

Svet.

[1]
https://github.com/apache/brooklyn-dist/blob/c9c688ccdea150817800b05d0a39aa0e812e27f4/vagrant/src/main/vagrant/Vagrantfile#L84

> On 24.02.2017 г., at 18:06, Rupinder Singh  wrote:
>
> 1. my pc doesn't have VT-X for sure.
>
> 2. But I run ubuntu out of Oracle VirtualBox and installation works.
>
> rupinder
>
>
>
> On Mon, Feb 20, 2017 at 9:02 PM, Rupinder Singh 
wrote:
>>
>>
>> Hi Svet
>> 1. No. I am not running vagrant inside another VM.
>>
>> 2. Windows 7. So it doesn't have hyper-V installed.
>>
>> rupinder
>>
>> On Mon, Feb 20, 2017 at 8:43 PM, Svetoslav Neykov <
> svetoslav.ney...@cloudsoftcorp.com> wrote:
>>>
>>> Hi Rupinder,
>>>
>>> If your machine doesn't support virtualisation you can still give
> Brooklyn a try by executing it directly in Windows.
>>> Download the zip[1] archive, extract it and run "bin/brooklyn launch"
> from the extracted folder. You can configure a cloud location
>>> and deploy an example blueprint to it. Drop by in our IRC channel
> #brooklyncentral (on FreeNode) if you need guidance on how to do that.
>>>
>>> Having said that, all recent processors should support virtualisation.
> If you don't have the option it could mean that it's already enabled.
>>> The error you get could (alternatively) be caused by one of the
> following:
>>>  * You are trying to run vagrant inside another VM. Is your Windows
> running locally in a VM? Are you working through an RDP session?
>>>  * You have Hyper-V (which is Microsoft's alternative to Virtualbox)
> enabled. Need to disable it - see the stackoverflow link sent by Mike
below.
>>>
>>>
>>> Svet.
>>>
>>>
>>> [1]
>
https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.10.0/apache-brooklyn-0.10.0-bin.zip
>>>
>>>
 On 20.02.2017 г., at 16:13, Rupinder Singh  wrote:

 I have Compaq R191B. Virtualization option is not there in BIOS.
> Doesn't
 support VT-X.

 On Mon, Feb 20, 2017 at 1:06 AM, Valentin Aitken <
 valentin.ait...@cloudsoftcorp.com> wrote:

> Hi Rupinder,
>
> The last log says vagrant cannot find rsync.
> Could you try installing and adding to PATH some Windows port of
> rsync?
> I suggest to try Cygwin [1].
>
> Valentin.
>
> [1] https://en.wikipedia.org/wiki/Cygwin
>
> На 19/02/17 в 18:25, Rupinder Singh написа:
>
>> Hi Mark, Duncan,
>>
>> Fresh output is as attached. Would this work?
>>
>> Rupinder
>>
>> On Sun, Feb 19, 2017 at 8:45 PM, Rupinder Singh > > wrote:
>>
>>   Thanks Mark, Duncan!
>>
>>   I'll try out and revert.
>>
>>   Rupinder
>>
>>   On Sun, Feb 19, 2017 at 8:28 PM, Mark Mc Kenna
>>   > wrote:
>>
>>   Hi Rupinder,
>>
>>   As Duncan said the ubuntu image is no longer supported by
> vagrant.
>>
>>   The updated centos7 version can be downloaded from the apache
>>   maven repo
>>   [1]
>>   It is worth noting that this is configured for the
>>   0.11.0-SNAPSHOT version
>>   of brooklyn. To change this please amend BROOKLYN_VERSION in
>>   servers.yaml
>>   [2].
>>
>>   I have confirmed the above is working for
>>   vagrant: 1.9.1
>>   virtualbox: 5.0.30 r112061
>>
>>   [1]
>>   https://repository.apache.org/content/groups/snapshots/org/a
>> pache/brooklyn/brooklyn-vagrant/0.11.0-SNAPSHOT/
>>   > apache/brooklyn/brooklyn-vagrant/0.11.0-SNAPSHOT/>
>>   [2]
>>   

Re: Call for release: Brooklyn 0.10.0

[John McCabe]

If there's a cli bump feel free to ping me about the homebrew release
process if necessary (it's pretty straight forward).
/John

On Thu, 17 Nov 2016, 15:19 Svetoslav Neykov, <
svetoslav.ney...@cloudsoftcorp.com> wrote:

> Nobody else stepped up so I guess that's me. I'll give it a go.
>
> Thanks.
> Svet.
>
>
> > On 17.11.2016 г., at 15:40, Richard Downer  wrote:
> >
> > The release-manager-to-be could also start running the release script[1]
> a
> > few times in dry run mode to catch any early issues.
> >
> > [1]
> >
> https://github.com/apache/brooklyn-dist/blob/master/release/make-release-artifacts.sh
> >
> >
> > On 17 November 2016 at 13:09, Aled Sage  wrote:
> >
> >> +1, sounds great - thanks Andrea!
> >>
> >> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
> >> that we want, such as an OutOfMemoryError deploying to Softlayer [1].
> >>
> >> It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
> >> release.
> >>
> >> In the meantime, we should still get our own house in order by doing the
> >> first of the steps below (i.e. dealing with open PRs; ensuring no-one
> has
> >> any imminent important contributions to make for 0.10.0, etc).
> >>
> >> Aled
> >>
> >> [1] https://issues.apache.org/jira/browse/BROOKLYN-364
> >>
> >>
> >>
> >> On 17/11/2016 11:37, Alex Heneveld wrote:
> >>
> >>> That would be a great solution Andrea!
> >>>
> >>> Best
> >>> Alex
> >>>
> >>> On 17 Nov 2016 08:18, "Andrea Turli" 
> >>> wrote:
> >>>
> >>> I'm happy to volunteer for releasing an official jclouds 1.9.3 which
> may
>  be
>  the half-house solution here.
> 
>  wdyt?
> 
>  Andrea
> 
>  On 17 November 2016 at 08:25, Svetoslav Neykov <
>  svetoslav.ney...@cloudsoftcorp.com> wrote:
> 
>  This is going to be the first release that actually works in Karaf.
> The
> > docs are still assuming classic though so I suggest we keep
> recommending
> > the classic distribution for 0.10.0.
> > For next release let's plan on updating the docs and switching the
> > recommended distribution to the Karaf based one.
> >
> > Svet.
> >
> >
> > On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> >>
> >> Hi all,
> >>
> >> It's far past time that we did a Brooklyn 0.10.0 release! I suggest
> we
> >>
> > aim for that soon.
> >
> >> To that end, I suggest the following steps:
> >>
> >> * Deal with open PRs:
> >> o People shout out about any PRs you think are very important to
> >>   be merged, before that release.
> >> o Review open PRs
> >>   (for any that won't get merged into 0.10.0, clearly mark them
> as
> >>   such and say why).
> >> * Any pending/remaining work:
> >> o Give people until Friday evening (uk time) to submit any other
> >>   very important PRs that are being working on.
> >> o People shout out about any known issues that they see as
> >>   blockers for a release.
> >> * Do some initial testing, using master (before Friday).
> >> * Aim to produce a first release candidate on Friday evening (uk
> time).
> >> * Do the usual QA/fix cycle until the release is ready.
> >> * Write release notes, etc.
> >>
> >> Of the first steps, reviewing the PRs is a big piece of work! If you
> >>
> > have time to help, then please lend a hand by reviewing and/or
> testing
> >
>  the
> 
> > PRs, and commenting on them.
> >
> >> I don't think we should try to squeeze lots of additional PRs into
> >>
> > 0.10.0 - there is already a huge amount in there compared to 0.9.0!
> >
> >> Richard, are our release process docs up-to-date at [1]?
> >>
> >> Aled
> >>
> >> [1] http://brooklyn.apache.org/developers/committers/release-
> >>
> > process/index.html
> >
> >>
> >>
> >
> >>
>
>

Re: [PROPOSAL] Remove unauthenticated localhost login

[John McCabe]

+1 on the prompt for user creation if none-exists

On Tue, 13 Sep 2016, 15:32 Aled Sage, <aled.s...@gmail.com> wrote:

> Hi all,
>
> I still think we really need to change the status quo. For me, there are
> two very compelling arguments:
>
>  1. In karaf, it will always prompt for a username and password.
> If running in localhost, you can enter any text and it will accept
> it. But you do have to "log in".
>  2. If running on a server, you need to find the auto-generated
> username:password from the log or from stdout.
>
> (1) is a bad user experience - the user doesn't know what to type, and
> then it turns out that it is a pointless login dialog! It happens
> because the login is controlled by the jaas configuration, which then
> delegates to Brooklyn code for checking the given username and password.
>
> For (2), I'd expect a fair number of users to go down this route.
> Currently the Brooklyn docs are not good at telling you how to find this
> username and password (partly because we have entirely different login
> behaviour for localhost, vagrant and remote-server). We are also all in
> agreement (I think) that it's a poor user experience.
>
> ---
> I'd like a consistent way for us to handle initial login on both
> localhost and server (and vagrant) - one that we are happy for users to
> experience, and for us to document well.
>
> ---
> _*New Proposal*_
>
> On initial connection via the web-console, it asks the server if there
> is any security configuration options set. If there is not, the
> web-console immediately re-directs the user to a page for creating the
> initial user:password. Once submitted, the username and hash of the
> password are written to $KARAF_HOME/etc/brooklyn.cfg for subsequent use.
>
> Over time, we'd further improve this to allow someone to set up the
> initial security configuration via this page (e.g. giving LDAP details,
> etc).
>
> _Implementation Considerations_
> Not sure of the details. It would be a bit fiddly, but hopefully not too
> hard.
>
> The web-console would need to do some initial requests to find out if a
> new user needs to be created. It would then redirect, POST the
> user-creation request, and automatically login with the new credentials.
>
> Server-side, we'd need some way for an unauthenticated user to submit
> the is-security-configured request and the initial-login-user-creation
> request. If we continue to use the existing Karaf jaas configuration,
> then the web-console could have submitted some garbage credentials so we
> get into the Brooklyn code (perhaps with default entitlements ensuring
> that all other access is forbidden); or we could have an unauthenticated
> REST endpoint that would handle its own security checks - always
> rejecting requests if any security configuration exists (which sounds
> scary).
>
> We'd need to extend the Brooklyn REST api for login-user-creation.
>
> For now, it would write to the $KARAF_HOME/etc/brooklyn.cfg file. Longer
> term, we could store the security config in the Brooklyn persisted state.
>
> We could also extend the Brooklyn CLI to support doing the
> initial-login-user-creation.
>
> ---
> _*Alternative Proposal 1*_
> If consensus is that folk really love the default of
> localhost-has-no-authentication, then we could look more into how to
> configure Karaf jaas so that it doesn't prompt for a login. I personally
> haven't been involved in that, so not sure how feasible/hard it is.
>
> ---
> _*Alternative Proposal 2*_
> We could make the default be unauthenticated (including disabling jaas
> in the default config files).
>
> Aled
>
>
> On 08/09/2016 22:05, John McCabe wrote:
> > By way of comparison, Jenkins deploys out of the box with no auth.
> >
> > On Thu, 8 Sep 2016 at 21:11 Svetoslav Neykov <
> > svetoslav.ney...@cloudsoftcorp.com> wrote:
> >
> >> Letsencrypt (or any other certification) is a no go on localhost or on
> >> remotes where you don't know the domain name used to access it.
> >> Browsers are moving slowly to a place where even plain http will trigger
> >> security warnings so self-signed won't be such a bad alternative at that
> >> point.
> >>
> >> +1 for removing unauthenticated localhost access
> >>
> >>>> Are you strongly against the status quo as well (given that the
> >> password may be "buried" when installing on a server)?
> >>> It has always been ugly but has struck me as the least ugly option.
> >> Here's an alternative which has a better user experience with the same
> >> level of security.
> >> When Brooklyn starts it sees that

Re: [PROPOSAL] Remove unauthenticated localhost login

[John McCabe]

-1 on removing it unless it can be reproduced in some form for the getting
started envs, the vagrant envs for example are local to the users system
and don't need to be secured as they are *not* intended for use in a
production capacity (perhaps worth adding a note pointing the user to the
section on securing a deploy (users/ssl etc)). The getting started ask on
the user should be absolutely minimal, even default passwords aren't great
UX in this context.

Alternatively I've seen flows where on a fresh install/first startup you
are prompted to create an admin account when first accessing the UI. I
would personally prefer that to default passwords (which is just as
insecure as no password, maybe even less so).

ps. hello ::)

On Thu, 8 Sep 2016 at 17:19 Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:

> >
> > Is there a way to pass metadata to rpm/deb?  That would be nice, we
> recommend running "yum install brooklyn -d admin.password=s3cr3t"
>
> as far as I understand that’s not possible.  I think there are workarounds
> but they go against the intent of RPM.
>
>
>
>
> 
> Gnu PGP key - http://is.gd/uI
>
>
> > On 8 Sep 2016, at 17:11, Alex Heneveld 
> wrote:
> >
> >
> > > Are you strongly against the status quo as well (given that the
> password may be "buried" when installing on a server)?
> >
> > It has always been ugly but has struck me as the least ugly option.
> >
> > Is there a way to pass metadata to rpm/deb?  That would be nice, we
> recommend running "yum install brooklyn -d admin.password=s3cr3t"
> >
> >
> > In general though I think this area of the product is good.
> >
> >
> > > HTTPS
> >
> > This has also been mentioned and while I would like it in an ideal
> world, the scare-the-daylights splash screen that browsers show if you have
> a self-signed cert is a compelling reason in my mind to adopt the same
> philosophy, start easy and document security, rather than start secure but
> hard-to-use.
> >
> >
> > --A
> >
> >
> >
> > On 08/09/2016 16:58, Aled Sage wrote:
> >> Hi Alex,
> >>
> >> Good points.
> >>
> >> Are you strongly against the status quo as well (given that the
> password may be "buried" when installing on a server)?
> >>
> >> ---
> >> It feels like your objections are mostly about the auto-generated
> password, rather than about whether we have unauthenticating localhost.
> >>
> >> Do you think we should change the behavior so that it sets up an
> initial default well-known credential of admin:password (which we log and
> document), and have localhost login require the same authentication?
> >>
> >> (I'd be hesitant about that, given the server may be publicly reachable
> and is opening an easily guessable password on a predictable port.)
> >>
> >> However, that would give consistency for all ways of launching
> Brooklyn. There are several use-cases to consider:
> >>
> >> * Vagrant (we already auto-populate brooklyn.properties with
> >>   admin:password, I believe).
> >> * Install on a server
> >> o using RPM/DEB
> >> o manually running karaf (with `./bin/start`)
> >> o manually running `./bin/brooklyn launch`
> >> * Install on localhost (using any of the three ways listed above)
> >>
> >> ---
> >> I was hoping to separate the work into two parts: making localhost and
> server behaviour consistent; and proper user/credential management.
> >>
> >> Longer term, options include:
> >>
> >> * Installing the rpm/deb doesn't start the service (giving the user a
> >>   chance to configure security first)
> >> * Force the user to change the initial password on first login, etc.
> >>
> >> Aled
> >>
> >>
> >> On 08/09/2016 16:09, Alex Heneveld wrote:
> >>>
> >>> Aled-
> >>>
> >>> I'm strongly against this.  Nearly all OSS software puts a priority of
> making it easy to get started, at the expense of pre-configured password
> (karaf's admin:admin) or no auth (most nosql datastores).  The good OSS
> software then describes clearly what's needed to make it secure.  I think
> we do a pretty good job of both.
> >>>
> >>> I'd welcome any install process tweak which encourages setting a
> password in an easy way (and this would help vagrant)  But I think it's
> unacceptable for the default to be a password buried in a log file ... or
> anything which makes it significantly harder to get started.
> >>>
> >>> (And do people really evaluate software on a shared server, in this
> day and age???)
> >>>
> >>> Best
> >>> Alex
> >>>
> >>>
> >>>
> >>> On 08/09/2016 15:42, Aled Sage wrote:
>  I'd expect a lot of folk evaluating Brooklyn for real use-cases to
> install Brooklyn on a server, rather than their laptop owned by their
> employer. Or for them to use Vagrant.
> 
>  For Vagrant, we can auto-populate it with an initial
> username:password in the brooklyn.properties file.
> 
>  And for Brooklyn on a server, I think we should taking security
> seriously so not allow unauthenticated access from any user 

[jira] [Closed] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

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

John McCabe closed BROOKLYN-276.


Closing as invalid.

fyi [~aledsage]

> TomcatServer entity does not install JRE if one is not present
> --
>
> Key: BROOKLYN-276
> URL: https://issues.apache.org/jira/browse/BROOKLYN-276
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Deploying a simple app to a location which does *not* have a JRE/JDK 
> installed results in the TomcatServer failing to start, the deployment 
> however proceeds with any errors.
> {code}
> location: byon1
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
> If I subsequently log into that machine and install Java I am them able to 
> invoke the *restart* effector on the app and it starts up as expected.
> (suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

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

John McCabe resolved BROOKLYN-276.
--
Resolution: Invalid

> TomcatServer entity does not install JRE if one is not present
> --
>
> Key: BROOKLYN-276
> URL: https://issues.apache.org/jira/browse/BROOKLYN-276
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Deploying a simple app to a location which does *not* have a JRE/JDK 
> installed results in the TomcatServer failing to start, the deployment 
> however proceeds with any errors.
> {code}
> location: byon1
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
> If I subsequently log into that machine and install Java I am them able to 
> invoke the *restart* effector on the app and it starts up as expected.
> (suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-276:
--

I've been unable to reproduce this, it's behaving as expected.

> TomcatServer entity does not install JRE if one is not present
> --
>
> Key: BROOKLYN-276
> URL: https://issues.apache.org/jira/browse/BROOKLYN-276
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Deploying a simple app to a location which does *not* have a JRE/JDK 
> installed results in the TomcatServer failing to start, the deployment 
> however proceeds with any errors.
> {code}
> location: byon1
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
> If I subsequently log into that machine and install Java I am them able to 
> invoke the *restart* effector on the app and it starts up as expected.
> (suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (BROOKLYN-275) Private Key Data description in the Add BYON Location Wizard is misleading

[John McCabe (JIRA)]

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

John McCabe closed BROOKLYN-275.

Resolution: Fixed

Fixed in https://github.com/apache/brooklyn-ui/pull/28
Thanks [~tbouron]

> Private Key Data description in the Add BYON Location Wizard is misleading
> --
>
> Key: BROOKLYN-275
> URL: https://issues.apache.org/jira/browse/BROOKLYN-275
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>
> Attempting to add a BYON location via the Catalog wizard you are prompted for 
> the following:
> {code}
> Private Key Data
> The contents of the private key file to use to connect to the machines (if 
> using key access, where the corresponding public key is in the 
> .authorized_keys file on the servers)
> {code}
> This implies that you must paste the *contents* of your private key file 
> however this field is currently maping to {{privateKeyFile}} which takes a 
> path to the key file on the Brooklyn node FS.
> This needs to be updated to push the contents of the textarea to 
> {{privateKeyData}}.
> *NOTE*: Also observed that if you paste a multi-line key it wasn't being 
> indented correctly, not sure if that was a result of populating the 
> {{privateKeyFile}} tag (suspect not tho...), we should handle multi-line key 
> data as if the user copy-pastes from their private key file thats what 
> they'll be pasting, also needs to handle the begin/end comments in a standard 
> private key file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-310) vagrant getting started won't work if docker beta installed on windows

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-310:
-
Description: 
If the user installs the current Docker beta on Windows (OSX remains 
unaffected) then it forces them to turn on Hyper-V which prevents Virtualbox 
from being used.

I suspect this will break the vagrant getting started env which has only been 
used with Virtualbox on Windows up to this point - will confirm.

It *should* be possible to switch Vagrant to use Hyper-V on Windows, unsure of 
the complexity/effort involved however.

  was:
If the user installs the current Docker beta on Windows then it forces them to 
turn on Hyper-V which prevents Virtualbox from being used.

I suspect this will break the vagrant getting started env which has only been 
used with Virtualbox on Windows up to this point - will confirm.

It *should* be possible to switch Vagrant to use Hyper-V on Windows, unsure of 
the complexity/effort involved however.


> vagrant getting started won't work if docker beta installed on windows
> --
>
> Key: BROOKLYN-310
> URL: https://issues.apache.org/jira/browse/BROOKLYN-310
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>  Labels: getting_started
>
> If the user installs the current Docker beta on Windows (OSX remains 
> unaffected) then it forces them to turn on Hyper-V which prevents Virtualbox 
> from being used.
> I suspect this will break the vagrant getting started env which has only been 
> used with Virtualbox on Windows up to this point - will confirm.
> It *should* be possible to switch Vagrant to use Hyper-V on Windows, unsure 
> of the complexity/effort involved however.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-310) vagrant getting started won't work if docker beta install on windows

[John McCabe (JIRA)]

John McCabe created BROOKLYN-310:


 Summary: vagrant getting started won't work if docker beta install 
on windows
 Key: BROOKLYN-310
 URL: https://issues.apache.org/jira/browse/BROOKLYN-310
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe


If the user installs the current Docker beta on Windows then it forces them to 
turn on Hyper-V which prevents Virtualbox from being used.

I suspect this will break the vagrant getting started env which has only been 
used with Virtualbox on Windows up to this point - will confirm.

It *should* be possible to switch Vagrant to use Hyper-V on Windows, unsure of 
the complexity/effort involved however.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-310) vagrant getting started won't work if docker beta installed on windows

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-310:
-
Summary: vagrant getting started won't work if docker beta installed on 
windows  (was: vagrant getting started won't work if docker beta install on 
windows)

> vagrant getting started won't work if docker beta installed on windows
> --
>
> Key: BROOKLYN-310
> URL: https://issues.apache.org/jira/browse/BROOKLYN-310
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>  Labels: getting_started
>
> If the user installs the current Docker beta on Windows then it forces them 
> to turn on Hyper-V which prevents Virtualbox from being used.
> I suspect this will break the vagrant getting started env which has only been 
> used with Virtualbox on Windows up to this point - will confirm.
> It *should* be possible to switch Vagrant to use Hyper-V on Windows, unsure 
> of the complexity/effort involved however.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-290) Broken link in brooklyn-client README.md

[John McCabe (JIRA)]

John McCabe created BROOKLYN-290:


 Summary: Broken link in brooklyn-client README.md
 Key: BROOKLYN-290
 URL: https://issues.apache.org/jira/browse/BROOKLYN-290
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Trivial


The README.md links to a 404'ing *Runtime README* file:
- https://github.com/apache/brooklyn-client/blob/master/README
Not clear what this should be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-289) Broken link in brooklyn-client README.md

[John McCabe (JIRA)]

John McCabe created BROOKLYN-289:


 Summary: Broken link in brooklyn-client README.md
 Key: BROOKLYN-289
 URL: https://issues.apache.org/jira/browse/BROOKLYN-289
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Trivial


The README.md links to a 404'ing *Runtime README* file:
- https://github.com/apache/brooklyn-client/blob/master/README
Not clear what this should be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-283) Integrate OSX brew packaging of brooklyn-cli into docs

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-283:
-
Issue Type: Improvement  (was: Bug)

> Integrate OSX brew packaging of brooklyn-cli into docs
> --
>
> Key: BROOKLYN-283
> URL: https://issues.apache.org/jira/browse/BROOKLYN-283
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 0.10.0
>    Reporter: John McCabe
>Priority: Minor
>  Labels: documentation, easyfix, newbie
>
> Need to integrate the brew packaging of `br` into the docs for OSX:
> {code}
> # brew install apache-brooklyn-cli
> # br login http://localhost:8081
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-283) Integrate OSX brew packaging of brooklyn-cli into docs

[John McCabe (JIRA)]

John McCabe created BROOKLYN-283:


 Summary: Integrate OSX brew packaging of brooklyn-cli into docs
 Key: BROOKLYN-283
 URL: https://issues.apache.org/jira/browse/BROOKLYN-283
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.10.0
Reporter: John McCabe
Priority: Minor


Need to integrate the brew packaging of `br` into the docs for OSX:
{code}
# brew install apache-brooklyn-cli
# br login http://localhost:8081
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Installing Apache Brooklyn CLI 0.9.0 on OSX with brew

[John McCabe]

This should help ease the migration to brew @rdowner - https://goo.gl/rg8wzH

On Tue, 24 May 2016 at 10:13 Richard Downer <rich...@apache.org> wrote:

> After a discussion with colleagues, it was established that they had
> hipster beards and used Homebrew. I don't have a suitably hipster beard so
> I can't use Homebrew - instead I use MacPorts, as appropriate for a
> 2000s-style stubble-beard owner. I did consider growing my beard out, but
> at my age, there's a significant risk that I'd be a greybeard and I'd have
> to compile everything by hand, starting with compiling Go using egcs.
>
> Pity really as I'd like to have a package-managed `br` app on my system.
> Maybe I should switch to Debian?
>
> Richard.
>
> On 24 May 2016 at 09:35, Thomas Bouron <thomas.bou...@cloudsoftcorp.com>
> wrote:
>
> > Hey John.
> >
> > Just installed the CLI via brew, it's awesome! Thank you very much for
> > this!
> >
> > Best.
> >
> > On Tue, 24 May 2016 at 00:11 Andrew Kennedy <
> > andrew.kenn...@cloudsoftcorp.com> wrote:
> >
> > > Awesome, just tested this on my laptop now. Thanks for doing this,
> John!
> > >
> > > Andrew.
> > >
> > > On Mon, 23 May 2016 at 23:35 John McCabe <j...@johnmccabe.net> wrote:
> > >
> > > > All,
> > > > The Apache Brooklyn CLI 0.9.0 (br) Homebrew [1] formula has just
> > merged,
> > > so
> > > > it's now available for install.
> > > >
> > > > # brew update
> > > > # brew install apache-brooklyn-cli
> > > > # br -version
> > > >
> > > > Heres what it looks like in under 30 seconds:
> > > >  - https://asciinema.org/a/0098jfnikgmsr2fwhargkmayz
> > > >
> > > > Enjoy !!
> > > > /John
> > > >
> > > > [1] - http://brew.sh/
> > > >
> > > --
> > >
> > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
> > >
> > --
> >
> > Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> > http://www.cloudsoftcorp.com/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>

Re: YAML blueprint: install package utility

[John McCabe]

Is there any way we could get rid of the initializers/type parts, rather
than:

- type: org.apache.brooklyn.entity.basic.VanillaSoftwareProcess
  brooklyn.initializers:
  - type: org.apache.brooklyn.initializer.stock.PackageInstaller
packages:
  yum: curl
  apt: curl-whatever=2.3.4

Something like:

- type: org.apache.brooklyn.entity.basic.VanillaSoftwareProcess
  packages:
yum: curl
apt: curl-whatever=2.3.4


On Tue, 24 May 2016 at 09:34 Duncan Grant 
wrote:

> Andrew,
>
> good point.  That's much neater.  Should be pretty straightforward to
> implement as well.
>
> Duncan
>
> On Mon, 23 May 2016 at 21:16 Andrew Kennedy <
> andrew.kenn...@cloudsoftcorp.com> wrote:
>
> > Duncan,
> >
> > I like the idea here, of having some extra object that does the package
> > installation, but what about a customizer or initializer instead? You
> could
> > have something like this:
> >
> > - type: org.apache.brooklyn.entity.basic.VanillaSoftwareProcess
> >   brooklyn.initializers:
> >   - type: org.apache.brooklyn.initializer.stock.PackageInstaller
> > packages:
> >   yum: curl
> >   apt: curl-whatever=2.3.4
> >
> > I initially thought of a JcloudsLocationCustomizer but that fails when we
> > use BYON locations, so I am thinking of something more like a generic
> > entity customizer that runs after the entity has been created, and the
> > location is available and SSHable. There are lots of other things these
> > initializers could do, like setting up users, configuring networking,
> > mounting volumes and so on. I don't think its a big stretch to add this
> > functionality here.
> >
> > Andrew.
> >
> > On Fri, 6 May 2016 at 14:40 Duncan Grant  >
> > wrote:
> >
> > > I agree that this is a problem that needs solved but I have misgivings
> > > about each of the proposed solutions.
> > >
> > > Firstly I think that "discovering" how to write brooklyn yaml can be
> > > difficult.  It can be difficult to find things in the documentation and
> > if
> > > you don't know to look for them in the first place then your only hope
> is
> > > coming across an example.
> > >
> > > So if we pre-install a set of bash scripts before running the install
> > > scripts I don't see any obvious way for someone using brooklyn to find
> > out
> > > about those scripts, and when the scripts change I imagine people won't
> > > notice the new functionality either.
> > > Another downside to using scripts is that it will become more difficult
> > to
> > > debug script failures.  At the moment I can copy the contents of stdin
> > and
> > > see the error associated.  If I had to step into scripts in other files
> > it
> > > could become much harder to find a failure.  In my opinion this ease of
> > > reproducibility and seeing the code I am running is one of the
> advantages
> > > of using bash over just using chef/puppet/salt/etc.
> > > If we could find a widely used, well tested bash library then some of
> > these
> > > issues might be mitigated but I've yet to find one.
> > >
> > > There is a similar issue with discovering the behaviour of the DSL
> > option.
> > > I think that the DSL only works because we keep it to a minimum and
> > really
> > > it only does one task - which is run-time configuring relationships
> > between
> > > entities.  If we extend it then we have replaced java with dsl and I
> > don't
> > > think that benefits anyone.  One advantage of the DSL option is that it
> > > will generate bash so it shouldn't make debugging any harder.
> > >
> > > The advantage of adding config options to the VanillaSoftwareProcess is
> > > that it adds to extra ways of discovering the behaviour - through the
> > > composer's autocomplete and in javadoc.  I assume that this would
> > generate
> > > extra tasks so we could again debug the bash used and it might make it
> > > easier as we might be able to see exactly which package failed to
> > install.
> > > However the big downside to this is that we are starting to make a sort
> > of
> > > god object which contains all brooklyn functionality in one object -
> i.e.
> > > VanilllaSoftwareProcess and I'm not sure that's where we want to go.
> > >
> > > After all that I don't really have a good answer.
> > >
> > > My not too good answer would be to make more use of the brooklyn child
> > > relationship so that a) at least the yaml could be composed from small
> > > pieces of code b) we could write a InstallPackage entity to simplify
> the
> > > yaml.
> > >
> > > This might look something like:
> > >
> > > - type: brooklyn.entity.basic.VanillaSoftwareProcess
> > >   install.command: curl somefile > somfile.txt
> > >   brooklyn.config:
> > > children.startable.mode: foreground_early
> > >   brooklyn.children:
> > >   - type: brooklyn.entity.basic.VanillaSoftwareProcess
> > > install.command: |
> > > which curl || \
> > > { sudo apt-get update && sudo apt-get install curl ; } || \

[jira] [Commented] (BROOKLYN-281) Enricher missing `brooklyn.config`: all config values ignored silently

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-281:
--

[~aled.sage] this looks related to BROOKLYN-279

> Enricher missing `brooklyn.config`: all config values ignored silently
> --
>
> Key: BROOKLYN-281
> URL: https://issues.apache.org/jira/browse/BROOKLYN-281
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: Aled Sage
>
> When attempting to use a {{Propagator}} enricher, we misconfigured the 
> blueprint using YAML like that below (this is a much simplified example).
> {noformat}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   id: app
>   brooklyn.enrichers:
>   - type: org.apache.brooklyn.enricher.stock.Propagator
> producer: $brooklyn:entity("my-machine")
> propagating:
> - $brooklyn:sensor("host.sshAddress")
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.machine.MachineEntity
> id: my-machine
> {noformat}
> Note the missing {{brooklyn.config}} inside the enricher. The blueprint 
> should actually have been:
> {noformat}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   id: app
>   brooklyn.enrichers:
>   - type: org.apache.brooklyn.enricher.stock.Propagator
> brooklyn.config:
>   producer: $brooklyn:entity("my-machine")
>   propagating:
>   - $brooklyn:sensor("host.sshAddress")
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.machine.MachineEntity
> id: my-machine
> {noformat}
> The first blueprint ignored the config values for the propagator (without any 
> helpful messages about it) and instead used the defaults. When combined with 
> https://issues.apache.org/jira/browse/BROOKLYN-278, then the defaults 
> resulted in a propagator being instantiated that caused an infinite loop!
> I'd have much preferred a sensible error message about the map values inside 
> the propagator not being supported, and suggesting that perhaps 
> {{brooklyn.config}} should be used.
> However, it's worth noting that with entities you can get away with missing 
> out the {{brooklyn.config}}. In that case, it treats all the map entries as 
> though they were inside a brooklyn.config. This allows for more concise 
> blueprints, but probably risks confusing blueprint authors who can't tell if 
> it's the same and who assume they can do the same in other situations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Installing Apache Brooklyn CLI 0.9.0 on OSX with brew

[John McCabe]

All,
The Apache Brooklyn CLI 0.9.0 (br) Homebrew [1] formula has just merged, so
it's now available for install.

# brew update
# brew install apache-brooklyn-cli
# br -version

Heres what it looks like in under 30 seconds:
 - https://asciinema.org/a/0098jfnikgmsr2fwhargkmayz

Enjoy !!
/John

[1] - http://brew.sh/

[jira] [Commented] (BROOKLYN-279) Catalog API lets you submit invalid yaml

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-279:
--

Changing issue title following feedback from [~m4rkmckenna] that it should be 
rejected via the API, the UI should also highlight where the resulting error is 
however. 

> Catalog API lets you submit invalid yaml
> 
>
> Key: BROOKLYN-279
> URL: https://issues.apache.org/jira/browse/BROOKLYN-279
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>
> Adding a catalog item that contains Parameters and invalid DSL is accepted 
> and added to the catalog. When you attempt to deploy the app via the template 
> wizard no parameters are displayed. The UI gives no other feedback that 
> theres been a problem.
> For example, a bp container the following invalid DSL ({{rootScope}} is not 
> valid):
> {code}
> docker.image.tag: $brooklyn:rootScope().config("wordpress.imageTag")
> {code}
> instead of
> {code}
> docker.image.tag: $brooklyn:scopeRoot().config("wordpress.imageTag")
> {code}
> the catalog is added without problem, but when you attempt to deploy the 
> parameters do not display



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (BROOKLYN-279) Catalog API lets you submit invalid yaml

[John McCabe (JIRA)]

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

John McCabe edited comment on BROOKLYN-279 at 5/23/16 5:05 PM:
---

Changing issue title following feedback from [~m4rkmckenna] that it should be 
rejected by the API, the UI should also highlight where the resulting error is 
however. 


was (Author: johnmccabe):
Changing issue title following feedback from [~m4rkmckenna] that it should be 
rejected via the API, the UI should also highlight where the resulting error is 
however. 

> Catalog API lets you submit invalid yaml
> 
>
> Key: BROOKLYN-279
> URL: https://issues.apache.org/jira/browse/BROOKLYN-279
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>
> Adding a catalog item that contains Parameters and invalid DSL is accepted 
> and added to the catalog. When you attempt to deploy the app via the template 
> wizard no parameters are displayed. The UI gives no other feedback that 
> theres been a problem.
> For example, a bp container the following invalid DSL ({{rootScope}} is not 
> valid):
> {code}
> docker.image.tag: $brooklyn:rootScope().config("wordpress.imageTag")
> {code}
> instead of
> {code}
> docker.image.tag: $brooklyn:scopeRoot().config("wordpress.imageTag")
> {code}
> the catalog is added without problem, but when you attempt to deploy the 
> parameters do not display



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-276:
--

assigning to myself so I remember to grab the env yml

> TomcatServer entity does not install JRE if one is not present
> --
>
> Key: BROOKLYN-276
> URL: https://issues.apache.org/jira/browse/BROOKLYN-276
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>
> Deploying a simple app to a location which does *not* have a JRE/JDK 
> installed results in the TomcatServer failing to start, the deployment 
> however proceeds with any errors.
> {code}
> location: byon1
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
> If I subsequently log into that machine and install Java I am them able to 
> invoke the *restart* effector on the app and it starts up as expected.
> (suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

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

John McCabe reassigned BROOKLYN-276:


Assignee: John McCabe

> TomcatServer entity does not install JRE if one is not present
> --
>
> Key: BROOKLYN-276
> URL: https://issues.apache.org/jira/browse/BROOKLYN-276
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Deploying a simple app to a location which does *not* have a JRE/JDK 
> installed results in the TomcatServer failing to start, the deployment 
> however proceeds with any errors.
> {code}
> location: byon1
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
> If I subsequently log into that machine and install Java I am them able to 
> invoke the *restart* effector on the app and it starts up as expected.
> (suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (BROOKLYN-280) br cli fails to login to brooklyn instances with self-signed SSL certs

[John McCabe (JIRA)]

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

John McCabe edited comment on BROOKLYN-280 at 5/23/16 4:04 PM:
---

I'll fix this, have a test client that works, will need to figure out the 
codegangsta lib (creating a {{BoolFlag}})


was (Author: johnmccabe):
I'll fix this, have a test client that works, will need to figure out the 
codegangsta lib (creating a `BoolFlag`)

> br cli fails to login to brooklyn instances with self-signed SSL certs
> --
>
> Key: BROOKLYN-280
> URL: https://issues.apache.org/jira/browse/BROOKLYN-280
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Attempt to log into Brooklyn with a cert generated following the instructions 
> on {{ops/brooklyn_properties}}, results in the following error:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: cannot validate 
> certificate for 10.10.10.100 because it doesn't contain any IP SANs
> {code}
> Adding the IP SAN (add {{-ext san=IP:10.10.10.100}} to the {{keytool}} 
> invocation on JDK 1.7+) then results in:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: certificate signed by 
> unknown authority
> {code}
> I suspect we may need to be tolerate of self-signed certs without a 
> trustchain, but do so via a flag that the user must set explicitly, for 
> example:
> {code}
> br login --trustall https://10.10.10.100 admin mypassword
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-280) br cli fails to login to brooklyn instances with self-signed SSL certs

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-280:
--

I'll fix this, have a test client that works, will need to figure out the 
codegangsta lib (creating a `BoolFlag`)

> br cli fails to login to brooklyn instances with self-signed SSL certs
> --
>
> Key: BROOKLYN-280
> URL: https://issues.apache.org/jira/browse/BROOKLYN-280
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Attempt to log into Brooklyn with a cert generated following the instructions 
> on {{ops/brooklyn_properties}}, results in the following error:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: cannot validate 
> certificate for 10.10.10.100 because it doesn't contain any IP SANs
> {code}
> Adding the IP SAN (add {{-ext san=IP:10.10.10.100}} to the {{keytool}} 
> invocation on JDK 1.7+) then results in:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: certificate signed by 
> unknown authority
> {code}
> I suspect we may need to be tolerate of self-signed certs without a 
> trustchain, but do so via a flag that the user must set explicitly, for 
> example:
> {code}
> br login --trustall https://10.10.10.100 admin mypassword
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (BROOKLYN-280) br cli fails to login to brooklyn instances with self-signed SSL certs

[John McCabe (JIRA)]

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

John McCabe reassigned BROOKLYN-280:


Assignee: John McCabe

> br cli fails to login to brooklyn instances with self-signed SSL certs
> --
>
> Key: BROOKLYN-280
> URL: https://issues.apache.org/jira/browse/BROOKLYN-280
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>    Assignee: John McCabe
>
> Attempt to log into Brooklyn with a cert generated following the instructions 
> on {{ops/brooklyn_properties}}, results in the following error:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: cannot validate 
> certificate for 10.10.10.100 because it doesn't contain any IP SANs
> {code}
> Adding the IP SAN (add {{-ext san=IP:10.10.10.100}} to the {{keytool}} 
> invocation on JDK 1.7+) then results in:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: certificate signed by 
> unknown authority
> {code}
> I suspect we may need to be tolerate of self-signed certs without a 
> trustchain, but do so via a flag that the user must set explicitly, for 
> example:
> {code}
> br login --trustall https://10.10.10.100 admin mypassword
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-280) br cli fails to login to brooklyn instances with self-signed SSL certs

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-280:
-
Description: 
Attempt to log into Brooklyn with a cert generated following the instructions 
on {{ops/brooklyn_properties}}, results in the following error:
{code}
# br login https://10.10.10.100:8443 admin mypassword
Get https://10.10.10.100:8443/v1/server/version: x509: cannot validate 
certificate for 10.10.10.100 because it doesn't contain any IP SANs
{code}
Adding the IP SAN (add {{-ext san=IP:10.10.10.100}} to the {{keytool}} 
invocation on JDK 1.7+) then results in:
{code}
# br login https://10.10.10.100:8443 admin mypassword
Get https://10.10.10.100:8443/v1/server/version: x509: certificate signed by 
unknown authority
{code}
I suspect we may need to be tolerate of self-signed certs without a trustchain, 
but do so via a flag that the user must set explicitly, for example:

{code}
br login --trustall https://10.10.10.100 admin mypassword
{code}

  was:
Attempt to log into Brooklyn with a cert generated following the instructions 
on {{ops/brooklyn_properties}}, results in the following error:
{code}
# br login https://10.10.10.100:8443 admin mypassword
Get https://10.10.10.100:8443/v1/server/version: x509: cannot validate 
certificate for 10.10.10.100 because it doesn't contain any IP SANs
{code}
We either need to update the {{br}} util to be more tolerant of such certs, or 
update the instructions in {{ops/brooklyn_properties}} to describe how to 
create certs containing the correct IP SAN for the secured server.

I'm torn on which option is best, I'd be inclined to do both, document the 
creation of a cert with a populated IP SAN *and* add a flag to {{br}} to 
tolerate servers without such a cert rather than accepting them silently (if 
thats possible with the golang crypto libs).


> br cli fails to login to brooklyn instances with self-signed SSL certs
> --
>
> Key: BROOKLYN-280
> URL: https://issues.apache.org/jira/browse/BROOKLYN-280
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>
> Attempt to log into Brooklyn with a cert generated following the instructions 
> on {{ops/brooklyn_properties}}, results in the following error:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: cannot validate 
> certificate for 10.10.10.100 because it doesn't contain any IP SANs
> {code}
> Adding the IP SAN (add {{-ext san=IP:10.10.10.100}} to the {{keytool}} 
> invocation on JDK 1.7+) then results in:
> {code}
> # br login https://10.10.10.100:8443 admin mypassword
> Get https://10.10.10.100:8443/v1/server/version: x509: certificate signed by 
> unknown authority
> {code}
> I suspect we may need to be tolerate of self-signed certs without a 
> trustchain, but do so via a flag that the user must set explicitly, for 
> example:
> {code}
> br login --trustall https://10.10.10.100 admin mypassword
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Naming of Brooklyn Client on OSX Homebrew

[John McCabe]

@all, have gone ahead with `apache-brooklyn-cli`, I'll update when its
merged and accessible.

On Mon, 23 May 2016 at 12:16 Thomas Bouron <thomas.bou...@cloudsoftcorp.com>
wrote:

> Hi John.
>
> As stated in Gitter, I +1 for `apache-brooklyn-cli` as the name of the brew
> package.
> Looking forward to use it!
>
> Best.
>
> On Mon, 23 May 2016 at 10:55 John McCabe <j...@johnmccabe.net> wrote:
>
> > Thanks Richard, will aim to proceed with ApacheBrooklynCli, so to flow on
> > OSX would be:
> >
> >   # brew install apache-brooklyn-cli
> >   # br login http://localhost:8081
> >   # etc..
> >
> > Will hold off committing the change for the moment to give others a
> chance
> > to comment.
> >
> > On Mon, 23 May 2016, 10:45 Richard Downer, <rich...@apache.org> wrote:
> >
> > > John,
> > >
> > > On 23 May 2016 at 10:34, John McCabe <j...@johnmccabe.net> wrote:
> > >
> > > > Naming of the package within Brew *only*, it does not impact the
> > > resulting
> > > > binary naming at all:
> > > >
> > > > # brew install apache-brooklyn-cli
> > > > # br login http://localhost:8081
> > >
> > >
> > > Excellent - my concerns were misplaced :-)
> > >
> > >
> > > > *Maintainers:*
> > > > Brew don't appear to have support for a maintainer tag, but adding a
> > > > maintainer in a comment is feasible.
> > > >
> > > > What maintainer address would you recommend?
> > > >
> > >
> > > No need to worry. If it's not common practice in the Brew world to
> name a
> > > maintainer (like it is in the Debian world, for example), then just
> > comply
> > > with their existing practices.
> > >
> > > I would prefer that at [1] you name the class `ApacheBrooklyn` instead
> of
> > > `Brooklyn` (but the naming of private variables inside the class is
> fine
> > as
> > > it is).
> > >
> > > Thanks for responding to my concerns! I have no other objections to
> this,
> > > so go ahead.
> > >
> > > Cheers
> > > Richard.
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/Homebrew/homebrew-core/pull/1326/files#diff-476062d25b84e180693641a30b797a5aR5
> > >
> >
> --
>
> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> http://www.cloudsoftcorp.com/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

[jira] [Commented] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-276:
--

[~svet] was actually a docker container, I've been putting together an example 
getting started environment using docker-compose for brooklyn and some sample 
byon nodes when I hit the problem when using a third-party ubuntu with ssh 
image.

I'll tidy it up tonight and make the yml available.

> TomcatServer entity does not install JRE if one is not present
> --
>
> Key: BROOKLYN-276
> URL: https://issues.apache.org/jira/browse/BROOKLYN-276
> Project: Brooklyn
>  Issue Type: Bug
>        Reporter: John McCabe
>
> Deploying a simple app to a location which does *not* have a JRE/JDK 
> installed results in the TomcatServer failing to start, the deployment 
> however proceeds with any errors.
> {code}
> location: byon1
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}
> If I subsequently log into that machine and install Java I am them able to 
> invoke the *restart* effector on the app and it starts up as expected.
> (suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Naming of Brooklyn Client on OSX Homebrew

[John McCabe]

@richard kicked it off myself at the weekend as I was installing br and
figured I'd take a look at whats involved in getting it added to brew.

re: metadata/attribution etc, what do you propose?

On Mon, 23 May 2016 at 10:08 Richard Downer <rich...@apache.org> wrote:

> Hi all,
>
> Catching up on this. As John mentioned I chipped in to the discussion on
> Gitter before I saw this thread.
>
> I'm "+1" on `apache-brooklyn-cli`, and -1 on *anything* that is not
> prefixed `apache-brooklyn-`.
>
> The reason for this is, with my PMC hat on, I am responsible for making
> sure that our trademarks are used correctly. If we fail to use our own
> trademarks correctly, we risk losing them. So the same goes for .debs and
> .rpms (I know in the last release the .rpm was correctly named which is
> good, but I haven't looked at the .deb build to check that).
>
> Another question. Who is running this? With all due respect to John, he is
> not (yet!) on the Brooklyn PMC so this effort is not officially part of the
> Brooklyn project. Now there's absolutely nothing wrong with that - we are
> open source, and what John is doing is 100% permitted by the license - but
> it may need to be clear in the metadata that this is John's work, not
> Apache's.
>
> Richard.
>
>
> On 23 May 2016 at 09:50, John McCabe <j...@johnmccabe.net> wrote:
>
> > Some feedback from @rdowner is that we should include the apache
> branding,
> > so current favourite is:
> >
> >   brew install apache-brooklyn-cli
> >
> > Note that by way of a comparison, Apache Spark is in brew as `brew
> install
> > apache-spark`, so I'm inclined to go with the suggestion above.
> >
> > On Mon, 23 May 2016 at 09:20 Geoff Macartney <
> > geoff.macart...@cloudsoftcorp.com> wrote:
> >
> > > "brooklyn-cli" also sounds good to me
> > >
> > > Geoff
> > >
> > > 
> > > Gnu PGP key - http://is.gd/uI
> > >
> > >
> > > > On 23 May 2016, at 08:59, John McCabe <j...@johnmccabe.net> wrote:
> > > >
> > > > I like that !
> > > >
> > > > On Mon, 23 May 2016 at 08:58 Thomas Bouron <
> > > thomas.bou...@cloudsoftcorp.com>
> > > > wrote:
> > > >
> > > >> Hey John.
> > > >>
> > > >> So if I'm understanding correctly this PR, this is to install the
> CLI
> > > via
> > > >> brew right? So why not using a simple brooklyn-cli?
> > > >>
> > > >> Best
> > > >>
> > > >> On Mon, 23 May 2016, 08:53 John McCabe, <j...@johnmccabe.net>
> wrote:
> > > >>
> > > >>> Hi All,
> > > >>>
> > > >>> I've currently got a pull request in against
> > > Homebrew/homebrew-core#1326
> > > >>> <https://github.com/Homebrew/homebrew-core/issues/1326> to add the
> > > >>> Brooklyn
> > > >>> CLI to brew.
> > > >>>
> > > >>> There's a reluctance however to add a `br` alias due to it being
> 'too
> > > >>> generic', one alternative is to just go with the repo name - for
> > > example:
> > > >>>
> > > >>>  brew install brooklyn-client
> > > >>>
> > > >>> This would still install the br cli.
> > > >>>
> > > >>> The current dist archive is `apache-brooklyn-client-cli` for
> example
> > > >>> (stripping the version out), I don't see a dedicated RPM/Deb for
> the
> > > >> client
> > > >>> but assume it would follow the same convention (* as an aside, is
> the
> > > >> -cli
> > > >>> really necessary, do we expect to distribute other clients?)
> > > >>>
> > > >>> Any suggestions/objections on the above alternative?
> > > >>>
> > > >>> /John
> > > >>>
> > > >>> ps. What is the status of getting linux packages into Debian/Fedora
> > > repos
> > > >>> etc? What package naming will be used.
> > > >>>
> > > >> --
> > > >>
> > > >> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> > > >> http://www.cloudsoftcorp.com/
> > > >> Github: https://github.com/tbouron
> > > >> Twitter: https://twitter.com/eltibouron
> > > >>
> > >
> > >
> >
>

Naming of Brooklyn Client on OSX Homebrew

[John McCabe]

Hi All,

I've currently got a pull request in against Homebrew/homebrew-core#1326
 to add the Brooklyn
CLI to brew.

There's a reluctance however to add a `br` alias due to it being 'too
generic', one alternative is to just go with the repo name - for example:

  brew install brooklyn-client

This would still install the br cli.

The current dist archive is `apache-brooklyn-client-cli` for example
(stripping the version out), I don't see a dedicated RPM/Deb for the client
but assume it would follow the same convention (* as an aside, is the -cli
really necessary, do we expect to distribute other clients?)

Any suggestions/objections on the above alternative?

/John

ps. What is the status of getting linux packages into Debian/Fedora repos
etc? What package naming will be used.

[jira] [Created] (BROOKLYN-276) TomcatServer entity does not install JRE if one is not present

[John McCabe (JIRA)]

John McCabe created BROOKLYN-276:


 Summary: TomcatServer entity does not install JRE if one is not 
present
 Key: BROOKLYN-276
 URL: https://issues.apache.org/jira/browse/BROOKLYN-276
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe


Deploying a simple app to a location which does *not* have a JRE/JDK installed 
results in the TomcatServer failing to start, the deployment however proceeds 
with any errors.

{code}
location: byon1
services:
- type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
  id: tomcat
  name: Tomcat
  war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
{code}

If I subsequently log into that machine and install Java I am them able to 
invoke the *restart* effector on the app and it starts up as expected.

(suspect this may impact all the Java entities)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-275) Private Key Data description in the Add BYON Location Wizard is misleading

[John McCabe (JIRA)]

John McCabe created BROOKLYN-275:


 Summary: Private Key Data description in the Add BYON Location 
Wizard is misleading
 Key: BROOKLYN-275
 URL: https://issues.apache.org/jira/browse/BROOKLYN-275
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe


Attempting to add a BYON location via the Catalog wizard you are prompted for 
the following:
{code}
Private Key Data
The contents of the private key file to use to connect to the machines (if 
using key access, where the corresponding public key is in the .authorized_keys 
file on the servers)
{code}
This implies that you must paste the *contents* of your private key file 
however this field is currently maping to {{privateKeyFile}} which takes a path 
to the key file on the Brooklyn node FS.
This needs to be updated to push the contents of the textarea to 
{{privateKeyData}}.

*NOTE*: Also observed that if you paste a multi-line key it wasn't being 
indented correctly, not sure if that was a result of populating the 
{{privateKeyFile}} tag (suspect not tho...), we should handle multi-line key 
data as if the user copy-pastes from their private key file thats what they'll 
be pasting, also needs to handle the begin/end comments in a standard private 
key file.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-274) App wizard fails for app templates containing locations

[John McCabe (JIRA)]

John McCabe created BROOKLYN-274:


 Summary: App wizard fails for app templates containing locations
 Key: BROOKLYN-274
 URL: https://issues.apache.org/jira/browse/BROOKLYN-274
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Minor


Attempting to deploy one of the 4 provided default app templates via the app 
wizard fails to enable the {{Next}} button, you instead have to switch to the 
app composer.

This presence of a skeleton location in the templates is causing this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-269) Sensitive external values exposed in debug logs when using external config supplier

[John McCabe (JIRA)]

John McCabe created BROOKLYN-269:


 Summary: Sensitive external values exposed in debug logs when 
using external config supplier
 Key: BROOKLYN-269
 URL: https://issues.apache.org/jira/browse/BROOKLYN-269
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.10.0
Reporter: John McCabe


Passwords etc are exposed in debug logs when using an external config supplied, 
in this case 
{{org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier}}

{code}
password: $brooklyn:external("my-credentials", "supersecretpassword")
{code}

{code}
2016-05-18 07:51:27,979 DEBUG o.a.b.c.b.s.d.BrooklynDslDeferredSupplier 
[brooklyn-execmanager-ajTGRUqW-212]: Resolved supersecretpassword from 
$brooklyn:external("my-credentials", "password")
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-200) Consider using other geo-DNS providers

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-200:
--

This is still an issue, I reached out to geoscaling.com support on the 3rd May 
and they are still working on upgrading the system - didn't give an ETA for 
resolution/replacement.

> Consider using other geo-DNS providers
> --
>
> Key: BROOKLYN-200
> URL: https://issues.apache.org/jira/browse/BROOKLYN-200
> Project: Brooklyn
>  Issue Type: Improvement
>Reporter: Sam Corbett
>
> Brooklyn supplies an entity for geo-DNS that uses a service provided by 
> geoscaling.com.  This entity is fundamentally broken because of problems with 
> geoscaling.com's SSL certificate.
> This has been noted in 
> [GeoscalingWebClientTest|https://github.com/sjcorbett/incubator-brooklyn/blob/02c5d33618373fc5ebe891eb485eca084391c540/software/webapp/src/test/java/org/apache/brooklyn/entity/dns/geoscaling/GeoscalingWebClientTest.java#L48-L106],
>  currently disabled. When connecting to the service the following exception 
> is thrown:
> {code}
> javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
> at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1098)
> at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:721)
> {code}
> The workaround is to import the SSL certificate for geoscaling.com into the 
> JDK's keystore, but this is unpleasant and hardly something we want to 
> recommend to users of Brooklyn.
> Further to this issue, geoscaling.com only uses the RC4 cipher. This is going 
> to be disabled by all major browsers at the beginning of 2016. We will be 
> recommending a service that people's browsers will refuse to sign in to.
> I've filed a support ticket stating the above with geoscaling.com. At the 
> same time we should consider whether we can use a different provider for this 
> entity.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-265) Slow connection to remote Brooklyn allows Deploy button to be clicked multiple times

[John McCabe (JIRA)]

John McCabe created BROOKLYN-265:


 Summary: Slow connection to remote Brooklyn allows Deploy button 
to be clicked multiple times
 Key: BROOKLYN-265
 URL: https://issues.apache.org/jira/browse/BROOKLYN-265
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Minor


I was connected via a slow network connection to a remote Brooklyn instance and 
when I first clicked deploy it seemed as though it hadn't registered so I 
quickly clicked the button again.

The second time I was redirected to the applications page where there were two 
instances of the application being deployed. Ideally this should not result in 
multiple apps being deployed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-262) No error thrown when adding app yaml to the catalog

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-262:
-
Summary: No error thrown when adding app yaml to the catalog  (was: No 
error thrown when adding app yaml to the catalog with app added to the catalog)

> No error thrown when adding app yaml to the catalog
> ---
>
> Key: BROOKLYN-262
> URL: https://issues.apache.org/jira/browse/BROOKLYN-262
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0, 0.10.0
>    Reporter: John McCabe
>Priority: Minor
>
> Adding application yaml to the catalog composer results in the app being 
> added to the catalog rather than an error thrown.
> For example, adding the following to the composer with {{catalog}} selected 
> rather than {{application}}:
> {code}
> location: localhost
> name: tomcat
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-262) No error thrown when adding app yaml to the catalog with app added to the catalog

[John McCabe (JIRA)]

John McCabe created BROOKLYN-262:


 Summary: No error thrown when adding app yaml to the catalog with 
app added to the catalog
 Key: BROOKLYN-262
 URL: https://issues.apache.org/jira/browse/BROOKLYN-262
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.9.0, 0.10.0
Reporter: John McCabe
Priority: Minor


Adding application yaml to the catalog composer results in the app being added 
to the catalog rather than an error thrown.

For example, adding the following to the composer with {{catalog}} selected 
rather than {{application}}:
{code}
location: localhost
name: tomcat
services:
- type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
  id: tomcat
  name: Tomcat
  war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-262) No error thrown when adding app yaml to the catalog

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-262:
--

fyi [~tbouron]/[~m4rkmckenna]

> No error thrown when adding app yaml to the catalog
> ---
>
> Key: BROOKLYN-262
> URL: https://issues.apache.org/jira/browse/BROOKLYN-262
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0, 0.10.0
>    Reporter: John McCabe
>Priority: Minor
>
> Adding application yaml to the catalog composer results in the app being 
> added to the catalog rather than an error thrown.
> For example, adding the following to the composer with {{catalog}} selected 
> rather than {{application}}:
> {code}
> location: localhost
> name: tomcat
> services:
> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
>   id: tomcat
>   name: Tomcat
>   war: http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-261) Unable to use previous catalog item in the same file if nested inside services

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-261:
--

Some pertinent additional comments:

[~svet]: {{PlanInterpreterGuessingType}} will try to parse the yaml itself to 
validate it but it only works for top-level catalog item references and it's 
doing it because the standard camp code path doesn't see the already parsed 
items because they are still not in the catalog
[~alex.heneveld]: so the right fix is to make sure we use some sort of 
temporary extra catalog with the new versions?
[~svet]: yes, the parser should use some kind of overlay catalog passed from 
the caller, not the global one
[~alex.heneveld]: the old behaviour skipped that deeper validation i guess? (so 
alternatively we could restore that...)

[~svet]: You can work around it by adding a top level BasicApplication entity 
(which is what happens behind the scenes any way). But agree we need to address 
the underlying problem.

> Unable to use previous catalog item in the same file if nested inside services
> --
>
> Key: BROOKLYN-261
> URL: https://issues.apache.org/jira/browse/BROOKLYN-261
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.10.0, 0.9.1
>    Reporter: John McCabe
>Priority: Minor
>
> Attempting to add a catalog with multiple items where an item defined in the 
> catalog is used by a later item nested inside {{services:}} currently fails:
> bq. Could not resolve item 'built-from-test-entity'; 2 errors including: 
> Transformer for Brooklyn OASIS CAMP interpreter gave an error creating this 
> plan: Unable to match plan item: 
> Service[name=,description=,serviceType=test-entity,characteristics=[],customAttributes={}]
> {code:title=Not Working|xml}
> brooklyn.catalog:
>   version: 0.0.1
>   items:
>   - id: test-entity
> name: Test Entity
> item:
>   services:
>   - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
>   - id: built-from-test-entity
> name: Built From Test Entity
> item:
>   services:
>   - type: test-entity
> {code}
> *Note* that {{test-entity}} above must not already exist in the catalog or 
> else the bom above would load.
> Altering the {{built-from-test-entity}} to not use nested services allows the 
> catalog bom to be added:
> {code}
>   - id: built-from-test-entity
> name: Built From Test Entity
> item:
>   type: test-entity
> {code}
> But this does not help for cases where the nesting is necessary, for example:
> {code}
>   - id: built-from-test-entity
> name: Built From Test Entity
> item:
>   services:
>   - type: test-entity
>   - type: another-entity
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-261) Unable to use previous catalog item in the same file if nested inside services

[John McCabe (JIRA)]

John McCabe created BROOKLYN-261:


 Summary: Unable to use previous catalog item in the same file if 
nested inside services
 Key: BROOKLYN-261
 URL: https://issues.apache.org/jira/browse/BROOKLYN-261
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.10.0, 0.9.1
Reporter: John McCabe
Priority: Minor


Attempting to add a catalog with multiple items where an item defined in the 
catalog is used by a later item nested inside {{services:}} currently fails:

bq. Could not resolve item 'built-from-test-entity'; 2 errors including: 
Transformer for Brooklyn OASIS CAMP interpreter gave an error creating this 
plan: Unable to match plan item: 
Service[name=,description=,serviceType=test-entity,characteristics=[],customAttributes={}]

{code:title=Not Working|xml}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: test-entity
name: Test Entity
item:
  services:
  - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess

  - id: built-from-test-entity
name: Built From Test Entity
item:
  services:
  - type: test-entity
{code}

*Note* that {{test-entity}} above must not already exist in the catalog or else 
the bom above would load.

Altering the {{built-from-test-entity}} to not use nested services allows the 
catalog bom to be added:
{code}
  - id: built-from-test-entity
name: Built From Test Entity
item:
  type: test-entity
{code}

But this does not help for cases where the nesting is necessary, for example:
{code}
  - id: built-from-test-entity
name: Built From Test Entity
item:
  services:
  - type: test-entity
  - type: another-entity
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-254) Setting the type in an effector parameter always returns java.lang.Object

[John McCabe (JIRA)]

John McCabe created BROOKLYN-254:


 Summary: Setting the type in an effector parameter always returns 
java.lang.Object
 Key: BROOKLYN-254
 URL: https://issues.apache.org/jira/browse/BROOKLYN-254
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Minor


Setting the type property in an effector parameter always results in a 
{{java.lang.Object}} being returned, for example:
{code}
parameters:
  LOGGING:
label: Enable logging
type: java.lang.Boolean
description: Control whether to enable/disable logging
defaultValue: true
{code}
Returns {{java.lang.Object}} in response to the 
{{applications//entities//effectors}} request:
{code}
  {
"name": "myEffector",
"returnType": "java.lang.String",
"parameters": [
  {
"name": "LOGGING",
"type": "java.lang.Object",
"description": "Control whether to enable/disable logging\n",
"defaultValue": true
  }
],
"description": "My Test Effector",
"links": {
  "self": 
"/v1/applications/HiAYKP2W/entities/cvgDGOLN/effectors/myEffector",
  "entity": "/v1/applications/HiAYKP2W/entities/cvgDGOLN",
  "application": "/v1/applications/HiAYKP2W"
}
  },
{code}
This results in the UI failing to render a checkbox in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-253) Effector APIs ParameterSummary should include label property

[John McCabe (JIRA)]

John McCabe created BROOKLYN-253:


 Summary: Effector APIs ParameterSummary should include label 
property
 Key: BROOKLYN-253
 URL: https://issues.apache.org/jira/browse/BROOKLYN-253
 Project: Brooklyn
  Issue Type: Improvement
Reporter: John McCabe
Priority: Minor


Currently if you add a parameter to an effector you can only set the {{name}} 
and {{description}}. The name is used as an environment variable in any command 
scripts and doesn't lend itself to presentation via the UI. 

It would be preferable to have a {{label}} parameter similar to that in the 
{{EntityConfigSummary}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-250:
--

Addressing in jsgui is messy as the location model is based on the /location/ 
api with {{name}} corresponding to {{id}} in yaml rather than the {{name}} 
parameter.

> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
> Attachments: catalog.png, dropdown.png
>
>
> Observed that the {{displayName}} field populated by the location wizard/yaml 
> doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> displays the string set in the {{name}} element.
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-250:
--

The {{config}} property in the {{CatalogLocationSummary}} isn't being populated 
so the jsgui doesn't have access to the {{displayName}} - the 
{{details-location.html}} template and {{location.js}} model look like the ui 
should render it if present.

> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
> Attachments: catalog.png, dropdown.png
>
>
> Observed that the {{displayName}} field populated by the location wizard/yaml 
> doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> displays the string set in the {{name}} element.
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-250:
-
Description: 
Observed that the {{displayName}} field populated by the location wizard/yaml 
doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
displays the string set in the {{name}} element.

If {{name}} isn't present it falls back to using the {{id}}

  was:
Observed that the {{displayName}} field populated by the location wizard/yaml 
doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
If {{name}} isn't present it falls back to using the {{id}}


> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
> Attachments: catalog.png, dropdown.png
>
>
> Observed that the {{displayName}} field populated by the location wizard/yaml 
> doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> displays the string set in the {{name}} element.
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-250:
-
Attachment: dropdown.png

> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
> Attachments: catalog.png, dropdown.png
>
>
> Observed that the {{displayName}} field populated by the location wizard 
> doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-250:
-
Description: 
Observed that the {{displayName}} field populated by the location wizard/yaml 
doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
If {{name}} isn't present it falls back to using the {{id}}

  was:
Observed that the {{displayName}} field populated by the location wizard (and 
yaml) doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
If {{name}} isn't present it falls back to using the {{id}}


> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
> Attachments: catalog.png, dropdown.png
>
>
> Observed that the {{displayName}} field populated by the location wizard/yaml 
> doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-250:
-
Description: 
Observed that the {{displayName}} field populated by the location wizard (and 
yaml) doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
If {{name}} isn't present it falls back to using the {{id}}

  was:
Observed that the {{displayName}} field populated by the location wizard 
doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
If {{name}} isn't present it falls back to using the {{id}}


> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
> Attachments: catalog.png, dropdown.png
>
>
> Observed that the {{displayName}} field populated by the location wizard (and 
> yaml) doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-250:
-
Description: 
Observed that the {{displayName}} field populated by the location wizard 
doesn't appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as {{locationid}} rather than {{locationname}} (in dropdown lists and 
the catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}
If {{name}} isn't present it falls back to using the {{id}}

  was:
Observed that the displayName field populated by the location wizard doesn't 
appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as locationid rather than locationname (in dropdown lists and the 
catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}


> displayName in location brooklyn.config not being used
> --
>
> Key: BROOKLYN-250
> URL: https://issues.apache.org/jira/browse/BROOKLYN-250
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Minor
>
> Observed that the {{displayName}} field populated by the location wizard 
> doesn't appear to be used? For example:
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> item:
>   type: localhost
>   brooklyn.config:
> displayName: locationname
> {code}
> displays as {{locationid}} rather than {{locationname}} (in dropdown lists 
> and the catalog page), whereas the following
> {code}
> brooklyn.catalog:
>   items:
>   - id: locationid
> itemType: location
> name: locationname
> item:
>   type: localhost
> {code}
> If {{name}} isn't present it falls back to using the {{id}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[John McCabe]

@andrea you need to bump your go to 1.6 and retry.

I have:
- spun up the vagrant box (had to inject the rc3 download url as its not on
the mirrors) without observing any issues
- checked port forwarding looks ok - binds to http://localhost:8081 on the
host
- checked byon location catalog loads without issue
- checked display name for inherited locations looks ok
- deployed tomcat app to byon location
- confirm issue observed by @neykov, and also refresh as suggested by
@tbouron
- raised BROOKLYN-250, noticed that when adding locations to the catalog
(yaml or wizard), the displayName isn't being used in dropdowns or on the
catalog page (it uses name if present and falls back to id)

On Thu, 7 Apr 2016 at 11:48 Andrea Turli 
wrote:

> Hi,
>
> Borrowing some ideas from Apache jclouds community [1] I'd like to propose
> to use the same workflow:
>
> Validating an Apache Brooklyn release involves verifying the following:
>
> - Verify that the checksums are valid.
> - Verify that the PGP signatures are valid.
> - Check that the expanded source archive matches contents of RC tag.
> - Verify that the expanded source archive builds and passes tests.
> - Check that LICENSE and NOTICE files are present and correct.
> - Make sure all files have license headers where appropriate.
> - Check that all dependencies have compatible licenses.
> - Verify that no compiled archives bundled in source archive.
>
> Some steps require a manual verification, and others are fully automated.
> The following scripts can be used:
>
> - Verify RAT, build, tests, checksums and signatures in one script
>
> Download the verification script:
>
> Unix: see the attachment
> If we accept the script we can then upload it to
> https://dist.apache.org/repos/dist/dev/brooklyn/verify_jclouds_rc.sh
>
> Run it and watch for failures:
>
> Unix:
>   chmod +x verify_brooklyn_rc.sh
>   ./verify_brooklyn_rc.sh 0.9.0-rc3
>
> Notice if you're running this on a Mac, you'll need brew and to do a brew
> install gpg first.
>
> By the way running the script I've got
>
> [INFO]
> [INFO]
> 
> [INFO] Building Brooklyn Client Command Line Interface 0.9.0
> [INFO]
> 
> [INFO]
> [INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @
> brooklyn-client-cli ---
> [INFO] Deleting
> /private/tmp/apache-brooklyn-0.9.0-rc3/apache-brooklyn-0.9.0-src/brooklyn-client
> (includes = [brooklyn*.log, brooklyn*.log.*, stacktrace.log, test-output,
> prodDb.*], excludes = [])
> [INFO]
> [INFO] --- maven-replacer-plugin:1.4.1:replace
> (fix-eclipse-dot-classpath-mangling) @ brooklyn-client-cli ---
> [INFO] Ignoring missing file
> [INFO] Replacement run on 0 file.
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.3:create (default) @
> brooklyn-client-cli ---
> [INFO] Executing: /bin/sh -c cd
> /private/tmp/apache-brooklyn-0.9.0-rc3/apache-brooklyn-0.9.0-src/brooklyn-client
> && git rev-parse --verify HEAD
> [INFO] Working directory:
> /private/tmp/apache-brooklyn-0.9.0-rc3/apache-brooklyn-0.9.0-src/brooklyn-client
> [INFO] Storing buildNumber: null at timestamp: 1460025523877
> [WARNING] Cannot get the branch information from the git repository:
> Detecting the current branch failed: fatal: Not a git repository (or any
> of the parent directories): .git
>
> [INFO] Executing: /bin/sh -c cd
> /private/tmp/apache-brooklyn-0.9.0-rc3/apache-brooklyn-0.9.0-src/brooklyn-client
> && git rev-parse --verify HEAD
> [INFO] Working directory:
> /private/tmp/apache-brooklyn-0.9.0-rc3/apache-brooklyn-0.9.0-src/brooklyn-client
> [INFO] Storing buildScmBranch: UNKNOWN_BRANCH
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (brooklyn-build-req) @
> brooklyn-client-cli ---
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.5:process (default) @
> brooklyn-client-cli ---
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (process-build-all) @
> brooklyn-client-cli ---
> [INFO] Executing tasks
>
> main:
>
> all:
>  [exec] Starting build.sh (brooklyn-client go build script)
>  [exec]
>  [exec] ERROR: Incompatible Go language version: go1.5.2
>  [exec]
>  [exec] Go version 1.6 or higher is required to build the
> brooklyn-client CLI.
>  [exec] See golang.org for more information, or run maven with
> '-Dno-go-client' to skip.
>  [exec]
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Brooklyn REST JavaScript Web GUI ... SUCCESS [
> 18.747 s]
> [INFO] Brooklyn Server Root ... SUCCESS [
>  0.188 s]
> [INFO] Brooklyn Parent Project  SUCCESS [
>  2.226 s]
> [INFO] Brooklyn Test Support Utilities  SUCCESS [
>  4.008 s]
> [INFO] Brooklyn Logback Includable Configuration .. SUCCESS [
>  0.861 s]
> [INFO] Brooklyn Common 

[jira] [Created] (BROOKLYN-250) displayName in location brooklyn.config not being used

[John McCabe (JIRA)]

John McCabe created BROOKLYN-250:


 Summary: displayName in location brooklyn.config not being used
 Key: BROOKLYN-250
 URL: https://issues.apache.org/jira/browse/BROOKLYN-250
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.9.0
Reporter: John McCabe
Priority: Minor


Observed that the displayName field populated by the location wizard doesn't 
appear to be used? For example:
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
item:
  type: localhost
  brooklyn.config:
displayName: locationname
{code}
displays as locationid rather than locationname (in dropdown lists and the 
catalog page), whereas the following
{code}
brooklyn.catalog:
  items:
  - id: locationid
itemType: location
name: locationname
item:
  type: localhost
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [CANCEL][VOTE] Release Apache Brooklyn 0.9.0 [rc2]

[John McCabe]

Likewise can https://github.com/apache/brooklyn-dist/pull/31 be considered
for inclusion.
/John
On Wed, 6 Apr 2016 at 17:29 Sam Corbett 
wrote:

> If I've not missed the cutoff I'd like
> https://github.com/apache/brooklyn-server/pull/99 to be included.
>
> On 6 April 2016 at 17:19, Richard Downer  wrote:
>
> > On 6 April 2016 at 17:17, Aled Sage  wrote:
> > > I believe that Richard is discussing which Geoff about which
> > brooklyn-client
> > > platform artifacts are required. Once that is agreed and sorted, then I
> > > think we are good to go.
> >
> > I've checked Geoff's PR and it's nice and simple: Mac 64bit, Windows
> > and Linux 32bit. The 32bit executables execute on 64bit machines so
> > there's no benefit to 64bit artifacts. To the best of my knowledge
> > there has never been a 32-bit Intel-based Mac, and even if there was,
> > it's obsolete.
> >
> > So it's ready to go IMO.
> >
>

[jira] [Commented] (BROOKLYN-248) Incorrect name in derived locations

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-248:
--

How would it be used for a real location use case? I'd have expected to see the 
name defined only at the {code} name: My name in items{code} level, also having 
the top level {code}itemType: location{code} sees odd in conjunction with the 
items (where it makes sense).

> Incorrect name in derived locations
> ---
>
> Key: BROOKLYN-248
> URL: https://issues.apache.org/jira/browse/BROOKLYN-248
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
> Environment: OSX
>Reporter: Duncan Godwin
>
> The following location displays "Test Location 1" for both "Test Location 1" 
> and "Test Location 2" when you use it to launch an application.
> See the screenshot here: 
> https://s3.amazonaws.com/drigodwin-misc/brooklyn-248-ss.png
> {code}
> brooklyn.catalog:
>   version: 0.2.0
>   items:
>   - id: test-location-1
> name: "Test Location 1"
> itemType: location
> item:
>   type: byon:(hosts="10.10.10.102")
>   brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
>   - id: test-location-2
> name: "Test Location 2"
> itemType: location
> item:
>   type: test-location-1
>   brooklyn.config:
> displayName: testingdisplayName2
> user: testinguser2
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BROOKLYN-246) Unable to add byon locations

[John McCabe (JIRA)]

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

John McCabe commented on BROOKLYN-246:
--

Likewise for the Vagrant location bom, it had been working in previous weeks.

> Unable to add byon locations
> 
>
> Key: BROOKLYN-246
> URL: https://issues.apache.org/jira/browse/BROOKLYN-246
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>    Reporter: John McCabe
>Priority: Blocker
>
> Running both the most recent 0.9.0-SNAPSHOT dist from maven and a freshly 
> build 0.10.0-SNAPSHOT from master I'm seeing the following behaviour.
> 1. Attempting to add a BYON location via jsgui is rejected with the following 
> error:
> {code}
> Could not resolve item 'testingid': Transformer for Brooklyn OASIS CAMP 
> interpreter gave an error creating this plan: No class or resolver found for 
> location type byon
> {code}
> 2. Trying the the generated JSON via the composer also fails:
> {code}
> brooklyn.catalog:
>   version: 0.0.1
>   items:
>   - id: testingid
> itemType: location
> item:
>   type: byon
>   brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
> hosts:
> - 10.10.10.102
> {code}
> 3. *BUT* this works:
> {code}
> brooklyn.catalog:
>   version: 0.0.1
>   items:
>   - id: testingid
> itemType: location
> item:
>   type: byon:(hosts="10.10.10.102")
>   brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [CANCEL][VOTE] Release Apache Brooklyn 0.9.0 [rc2]

[John McCabe]

Note that it also breaks the add location wizard in jsgui.

On Tue, 5 Apr 2016 at 10:26 Richard Downer <rich...@apache.org> wrote:

> After discussing with John, I agree that BROOKLYN-246 is a blocker.
> The catalog file that the Brooklyn Vagrant distributable uses is using
> the broken format, so it won't work - and we really don't want our
> simplest-possible-get-started to require manual modifications before
> it'll work. It also breaks the documented way of using BYON[1] so we
> are at high risk of breaking user's working configurations.
>
> Therefore due to this critical bug, I am cancelling the vote.
>
> Richard.
>
> [1]https://brooklyn.apache.org/v/latest/ops/locations/index.html#byon
>
> On 4 April 2016 at 18:11, John McCabe <j...@johnmccabe.net> wrote:
> > @all, I hit an issue with location handling while following up on @svets
> > comments - https://issues.apache.org/jira/browse/BROOKLYN-246
> >
> > Looks like a blocker.
> >
> > On Mon, 4 Apr 2016 at 14:35 John McCabe <j...@johnmccabe.net> wrote:
> >
> >> @svet, latest isn't required, 1.8+ should suffice.
> >>
> >> On Mon, 4 Apr 2016 at 12:53 Svetoslav Neykov <
> >> svetoslav.ney...@cloudsoftcorp.com> wrote:
> >>
> >>> +1 binding
> >>>
> >>> * Tested the .zip & .tar.gz dists
> >>> * Tested CLI
> >>> * Tried a simple blueprint
> >>> * Tested the vagrant artifact - "vagrant up" *fails* because it's
> looking
> >>> at the release url
> >>>
> https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.9.0/apache-brooklyn-0.9.0-bin.tar.gz
> >>> <
> >>>
> https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.9.0/apache-brooklyn-0.9.0-bin.tar.gz
> >.
> >>> Once released should work.
> >>>Unrelated, but do we require the absolute latest vagrant version on
> >>> purpose? Can we relax this version requirement?
> >>>
> >>> Svet.
> >>>
> >>>
> >>> > On 4.04.2016 г., at 13:14, Sam Corbett <
> sam.corb...@cloudsoftcorp.com>
> >>> wrote:
> >>> >
> >>> > +1 binding
> >>> >
> >>> > I have:
> >>> > * Verified release signatures
> >>> > * Built from the source archive
> >>> > * Generated a project from the archetype
> >>> > * Verified all subsequent archetype instructions were correct
> >>> > * Verified a simple application deployed to AWS.
> >>> > * Given the CLI a work out.
> >>> >
> >>> >
> >>> > On 01/04/2016 16:58, Richard Downer wrote:
> >>> >> This is to call for a vote for the release of Apache Brooklyn 0.9.0
> >>> [rc2].
> >>> >>
> >>> >> This release comprises of a source code distribution, and a
> >>> >> corresponding binary distribution, RPM packages, Vagrant environment
> >>> >> package, 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.9.0-rc2
> >>> >>
> >>> >> The artifact SHA-256 checksums are as follows:
> >>> >> 426ca93aad28ac8281b2015fc0ea419cd6db19c3ed87ffd11910a6baf2e9e3ab
> >>> >> *apache-brooklyn-0.9.0-rc2-1.noarch.rpm
> >>> >> b2a65642fb86198b9fd9992ef3464025d9b41c453c4dd5366699d569a65709c6
> >>> >> *apache-brooklyn-0.9.0-rc2-bin.tar.gz
> >>> >> 999fd6f1d21417278ffe153fc1f0346d44235dfbbd39f200815f61cea82edbe5
> >>> >> *apache-brooklyn-0.9.0-rc2-bin.zip
> >>> >> 00e0a76775775957e92498d0b5ea3e13f844155eda3251a8ead05cf4b4a4455b
> >>> >> *apache-brooklyn-0.9.0-rc2-src.tar.gz
> >>> >> c7a9a286993b1d520ae6a32e25c0dd3bef7227290d59347256bd96480b70a02b
> >>> >> *apache-brooklyn-0.9.0-rc2-src.zip
> >>> >> 907267c5d2e7c1622e11f2bc57b6afe12ddf2136d82bad63661e43570aaa78fa
> >>> >> *apache-brooklyn-0.9.0-rc2-vagrant.tar.gz
> >>> >> 0ae8384426d6b7197ca3d194c1e8032b85c5bb80671157c274487220d3ba65e9
> >>> >> *apache-brooklyn-0.9.0-rc2-vagrant.zip
> >>> >>
> >>> >> The Nexus staging repositories for the Maven artifacts

[jira] [Updated] (BROOKLYN-246) Unable to add byon locations

[John McCabe (JIRA)]

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

John McCabe updated BROOKLYN-246:
-
Description: 
Running both the most recent 0.9.0-SNAPSHOT dist from maven and a freshly build 
0.10.0-SNAPSHOT from master I'm seeing the following behaviour.

1. Attempting to add a BYON location via jsgui is rejected with the following 
error:
{code}
Could not resolve item 'testingid': Transformer for Brooklyn OASIS CAMP 
interpreter gave an error creating this plan: No class or resolver found for 
location type byon
{code}

2. Trying the the generated JSON via the composer also fails:
{code}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: testingid
itemType: location
item:
  type: byon
  brooklyn.config:
displayName: testingdisplayName
user: testinguser
password: testingpassword
privateKeyFile: testingprivateKeyFile
privateKeyPassphrase: testingprivateKeyPassphrase
hosts:
- 10.10.10.102
{code}

3. *BUT* this works:
{code}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: testingid
itemType: location
item:
  type: byon:(hosts="10.10.10.102")
  brooklyn.config:
displayName: testingdisplayName
user: testinguser
password: testingpassword
privateKeyFile: testingprivateKeyFile
privateKeyPassphrase: testingprivateKeyPassphrase
{code}

  was:
Running both the most recent 0.9.0-SNAPSHOT dist from maven and a freshly build 
0.10.0-SNAPSHOT from master I'm seeing the following behaviour.

1. Attempting to add a BYON location via jsgui is rejected with the following 
error:
{code}
Could not resolve item 'john': Transformer for Brooklyn OASIS CAMP interpreter 
gave an error creating this plan: No class or resolver found for location type 
byon
{code}

2. Trying the the generated JSON via the composer also fails:
{code}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: testingid
itemType: location
item:
  type: byon
  brooklyn.config:
displayName: testingdisplayName
user: testinguser
password: testingpassword
privateKeyFile: testingprivateKeyFile
privateKeyPassphrase: testingprivateKeyPassphrase
hosts:
- 10.10.10.102
{code}

3. *BUT* this works:
{code}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: testingid
itemType: location
item:
  type: byon:(hosts="10.10.10.102")
  brooklyn.config:
displayName: testingdisplayName
user: testinguser
password: testingpassword
privateKeyFile: testingprivateKeyFile
privateKeyPassphrase: testingprivateKeyPassphrase
{code}


> Unable to add byon locations
> 
>
> Key: BROOKLYN-246
> URL: https://issues.apache.org/jira/browse/BROOKLYN-246
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: John McCabe
>Priority: Blocker
>
> Running both the most recent 0.9.0-SNAPSHOT dist from maven and a freshly 
> build 0.10.0-SNAPSHOT from master I'm seeing the following behaviour.
> 1. Attempting to add a BYON location via jsgui is rejected with the following 
> error:
> {code}
> Could not resolve item 'testingid': Transformer for Brooklyn OASIS CAMP 
> interpreter gave an error creating this plan: No class or resolver found for 
> location type byon
> {code}
> 2. Trying the the generated JSON via the composer also fails:
> {code}
> brooklyn.catalog:
>   version: 0.0.1
>   items:
>   - id: testingid
> itemType: location
> item:
>   type: byon
>   brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
> hosts:
> - 10.10.10.102
> {code}
> 3. *BUT* this works:
> {code}
> brooklyn.catalog:
>   version: 0.0.1
>   items:
>   - id: testingid
> itemType: location
> item:
>   type: byon:(hosts="10.10.10.102")
>   brooklyn.config:
> displayName: testingdisplayName
> user: testinguser
> password: testingpassword
> privateKeyFile: testingprivateKeyFile
> privateKeyPassphrase: testingprivateKeyPassphrase
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (BROOKLYN-246) Unable to add byon locations

[John McCabe (JIRA)]

John McCabe created BROOKLYN-246:


 Summary: Unable to add byon locations
 Key: BROOKLYN-246
 URL: https://issues.apache.org/jira/browse/BROOKLYN-246
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.9.0
Reporter: John McCabe
Priority: Blocker


Running both the most recent 0.9.0-SNAPSHOT dist from maven and a freshly build 
0.10.0-SNAPSHOT from master I'm seeing the following behaviour.

1. Attempting to add a BYON location via jsgui is rejected with the following 
error:
{code}
Could not resolve item 'john': Transformer for Brooklyn OASIS CAMP interpreter 
gave an error creating this plan: No class or resolver found for location type 
byon
{code}

2. Trying the the generated JSON via the composer also fails:
{code}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: testingid
itemType: location
item:
  type: byon
  brooklyn.config:
displayName: testingdisplayName
user: testinguser
password: testingpassword
privateKeyFile: testingprivateKeyFile
privateKeyPassphrase: testingprivateKeyPassphrase
hosts:
- 10.10.10.102
{code}

3. *BUT* this works:
{code}
brooklyn.catalog:
  version: 0.0.1
  items:
  - id: testingid
itemType: location
item:
  type: byon:(hosts="10.10.10.102")
  brooklyn.config:
displayName: testingdisplayName
user: testinguser
password: testingpassword
privateKeyFile: testingprivateKeyFile
privateKeyPassphrase: testingprivateKeyPassphrase
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: vagrant version requirements

[John McCabe]

We could just go with basic statement suggesting a current Vagrant version
rather than 1.8.1/1.8.x explicitly (its semantics at this point). I do
prefer being explicit however - it's a far worse user experience to install
and discover it doesn't work on your particular version.

> Vagrant seems to be the install-and-forget kind of software which you
don't really upgrade.
Bad svet !! :)

As for the OS version, I'm inclined to wait until Xenial is release (real
soon now) and switch to that.

On Mon, 4 Apr 2016 at 16:11 Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

> > where do you draw the line in terms of supporting old versions
>
> Do we really need to draw it anywhere, could just drop the version
> requirement :). Don't think the Vagrantfile relies on anything recently
> introduced?
> I used a 1.7.x version not too long ago for example.
> My point is that this breaks the user's experience if he has to upgrade
> Vagrant install for no good reason. Vagrant seems to be the
> install-and-forget kind of software which you don't really upgrade.
>
> No strong opinion which versions to require exactly, just wanted to bring
> it up as a possible pain point.
> Another thing I suggest is to base it on the latest LTS release, having a
> bigger chance for it to be already downloaded.
>
> Svet.
>
>
> > On 4.04.2016 г., at 17:57, John McCabe <j...@johnmccabe.net> wrote:
> >
> > Hi Svet,
> > I agree the 1.8.1 is too specific, 1.8.x is actually sufficient. I reckon
> > dropping to verified major version with a suggestion that the user update
> > to the current version.
> >
> > As for 1.7.x I don't think we want to encourage/support the use of
> obsolete
> > versions - 1.7.0 is from December 2014. The tarball release remains
> > available as a fallback in those cases (where do you draw the line in
> terms
> > of supporting old versions).
> >
> > wdyt?
> > /John
> >
> > On Mon, 4 Apr 2016 at 14:41 Svetoslav Neykov <
> > svetoslav.ney...@cloudsoftcorp.com> wrote:
> >
> >> // Changed subject from Re: [VOTE] Release Apache Brooklyn 0.9.0 [rc2]
> >>
> >> Current requirement is >=1.8.1, see [1]. I had 1.8.0 installed - that's
> >> how I noticed. But I assume 1.7.x would be widely installed as well?
> >>
> >> [1]
> >>
> https://github.com/apache/brooklyn-dist/blame/master/vagrant/src/main/vagrant/Vagrantfile#L23
> >>
> >>
> >>> On 4.04.2016 г., at 16:35, John McCabe <j...@johnmccabe.net> wrote:
> >>>
> >>> @svet, latest isn't required, 1.8+ should suffice.
> >>>
> >>> On Mon, 4 Apr 2016 at 12:53 Svetoslav Neykov <
> >>> svetoslav.ney...@cloudsoftcorp.com> wrote:
> >>>
> >>>> +1 binding
> >>>>
> >>>> * Tested the .zip & .tar.gz dists
> >>>> * Tested CLI
> >>>> * Tried a simple blueprint
> >>>> * Tested the vagrant artifact - "vagrant up" *fails* because it's
> >> looking
> >>>> at the release url
> >>>>
> >>
> https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.9.0/apache-brooklyn-0.9.0-bin.tar.gz
> >>>> <
> >>>>
> >>
> https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.9.0/apache-brooklyn-0.9.0-bin.tar.gz
> >>> .
> >>>> Once released should work.
> >>>>  Unrelated, but do we require the absolute latest vagrant version on
> >>>> purpose? Can we relax this version requirement?
> >>>>
> >>>> Svet.
> >>>>
> >>>>
> >>>>> On 4.04.2016 г., at 13:14, Sam Corbett <
> sam.corb...@cloudsoftcorp.com>
> >>>> wrote:
> >>>>>
> >>>>> +1 binding
> >>>>>
> >>>>> I have:
> >>>>> * Verified release signatures
> >>>>> * Built from the source archive
> >>>>> * Generated a project from the archetype
> >>>>> * Verified all subsequent archetype instructions were correct
> >>>>> * Verified a simple application deployed to AWS.
> >>>>> * Given the CLI a work out.
> >>>>>
> >>>>>
> >>>>> On 01/04/2016 16:58, Richard Downer wrote:
> >>>>>> This is to call for a vote for the release of Apache Brooklyn 0.9.0
> >>>> [rc2].
> >>>>>>
> >>>>>> This relea

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

[John McCabe]

@svet, latest isn't required, 1.8+ should suffice.

On Mon, 4 Apr 2016 at 12:53 Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

> +1 binding
>
> * Tested the .zip & .tar.gz dists
> * Tested CLI
> * Tried a simple blueprint
> * Tested the vagrant artifact - "vagrant up" *fails* because it's looking
> at the release url
> https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.9.0/apache-brooklyn-0.9.0-bin.tar.gz
> <
> https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.9.0/apache-brooklyn-0.9.0-bin.tar.gz>.
> Once released should work.
>Unrelated, but do we require the absolute latest vagrant version on
> purpose? Can we relax this version requirement?
>
> Svet.
>
>
> > On 4.04.2016 г., at 13:14, Sam Corbett 
> wrote:
> >
> > +1 binding
> >
> > I have:
> > * Verified release signatures
> > * Built from the source archive
> > * Generated a project from the archetype
> > * Verified all subsequent archetype instructions were correct
> > * Verified a simple application deployed to AWS.
> > * Given the CLI a work out.
> >
> >
> > On 01/04/2016 16:58, Richard Downer wrote:
> >> This is to call for a vote for the release of Apache Brooklyn 0.9.0
> [rc2].
> >>
> >> This release comprises of a source code distribution, and a
> >> corresponding binary distribution, RPM packages, Vagrant environment
> >> package, 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.9.0-rc2
> >>
> >> The artifact SHA-256 checksums are as follows:
> >> 426ca93aad28ac8281b2015fc0ea419cd6db19c3ed87ffd11910a6baf2e9e3ab
> >> *apache-brooklyn-0.9.0-rc2-1.noarch.rpm
> >> b2a65642fb86198b9fd9992ef3464025d9b41c453c4dd5366699d569a65709c6
> >> *apache-brooklyn-0.9.0-rc2-bin.tar.gz
> >> 999fd6f1d21417278ffe153fc1f0346d44235dfbbd39f200815f61cea82edbe5
> >> *apache-brooklyn-0.9.0-rc2-bin.zip
> >> 00e0a76775775957e92498d0b5ea3e13f844155eda3251a8ead05cf4b4a4455b
> >> *apache-brooklyn-0.9.0-rc2-src.tar.gz
> >> c7a9a286993b1d520ae6a32e25c0dd3bef7227290d59347256bd96480b70a02b
> >> *apache-brooklyn-0.9.0-rc2-src.zip
> >> 907267c5d2e7c1622e11f2bc57b6afe12ddf2136d82bad63661e43570aaa78fa
> >> *apache-brooklyn-0.9.0-rc2-vagrant.tar.gz
> >> 0ae8384426d6b7197ca3d194c1e8032b85c5bb80671157c274487220d3ba65e9
> >> *apache-brooklyn-0.9.0-rc2-vagrant.zip
> >>
> >> The Nexus staging repositories for the Maven artifacts are located at:
> >>
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1016
> >>
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1017
> >>
> >> 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: acc8ff1930d243d2a5fae1ad2f1a1ef17ca4a19c
> >> brooklyn-client: 64573c8e1b8630f59b23356520282c91cc46a8a1
> >> brooklyn-dist: 0b8b81df458fa4323939582d9f0dda10b2f6eaee
> >> brooklyn-docs: 12430d193e1891b87a677d6b45a3b17861c83518
> >> brooklyn-library: 2565e6eb2868468ec2528df74fe85efdb887b6d2
> >> brooklyn-server: d031cea080613645219ba982c93264943798d4fc
> >> brooklyn-ui: 307382128951bb237bc351ac22136745e5d50475
> >> All of the above have been tagged as "apache-brooklyn-0.9.0-rc2".
> >>
> >>
> >> Please download the artifacts, test, and vote on releasing this
> >> package as Apache Brooklyn 0.9.0.
> >>
> >> The vote will be open for at least 72 hours.
> >> [ ] +1 Release this package as Apache Brooklyn 0.9.0 (please describe
> >> the tests you have performed)
> >> [ ] +0 no opinion
> >> [ ] -1 Do not release this package (please describe why not)
> >>
> >> Thanks
> >> Richard.
> >
>
>

Re: [VOTE] Release Apache Brooklyn 0.9.0 [rc1]

[John McCabe]

+1

On Thu, 31 Mar 2016 at 14:59 Duncan Godwin 
wrote:

> +1
>
> On 31 March 2016 at 14:49, Thomas Bouron 
> wrote:
>
> > +1!
> >
> > On Thu, 31 Mar 2016 at 14:17 Aleksandr Vasilev <
> > aleksandr.vasi...@cloudsoftcorp.com> wrote:
> >
> > > +1
> > >
> > > Best Regards,
> > >
> > > Aleksandr Vasilev
> > > DevOps Engineer | Cloudsoft Corporation
> > >
> > > On 31 March 2016 at 16:16, Richard Downer  wrote:
> > >
> > > > This is to call for a vote for the release of Apache Brooklyn 0.9.0
> > > [rc1].
> > > >
> > > > This release comprises of a source code distribution, and a
> > corresponding
> > > > binary distribution, RPM packages, Vagrant environment package, 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.9.0-rc1
> > > >
> > > > The artifact SHA-256 checksums are as follows:
> > > > c03938c4c7a060e8e50f435170e5033277f09c84a54d4abcf0d949c807de9363
> > > > *apache-brooklyn-0.9.0-rc1-1.noarch.rpm
> > > > 777663bbc4cf2d4228ea5dfdfd3e17b5aeaefc3a72ef51d6560fdffe27fc0f46
> > > > *apache-brooklyn-0.9.0-rc1-bin.tar.gz
> > > > 4dcaa31e68fed04217aa2b976675cd9b92db0d8f24735c033081ecd3128985d0
> > > > *apache-brooklyn-0.9.0-rc1-bin.zip
> > > > ef697bfe7d1f4b83964a008a2f92ee92282a1f6160904d3e7b51e571b0002422
> > > > *apache-brooklyn-0.9.0-rc1-src.tar.gz
> > > > 149eef62981f154c1bff7a0f41ddbbbc6f0b40c21997391f9a273db156a405ce
> > > > *apache-brooklyn-0.9.0-rc1-src.zip
> > > > 1b39a3c2da645a05026882c106d321e8f34fd19d8d3864baab88952538315d30
> > > > *apache-brooklyn-0.9.0-rc1-vagrant.tar.gz
> > > > cae31212f1293e557c4039138f95769d2c58de7478cbc3b5bf8a9d5c03dfd7a2
> > > > *apache-brooklyn-0.9.0-rc1-vagrant.zip
> > > >
> > > > The Nexus staging repositories for the Maven artifacts are located
> at:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1014
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1015
> > > >
> > > > 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: acc8ff1930d243d2a5fae1ad2f1a1ef17ca4a19c
> > > > brooklyn-client: 64573c8e1b8630f59b23356520282c91cc46a8a1
> > > > brooklyn-dist: 0b8b81df458fa4323939582d9f0dda10b2f6eaee
> > > > brooklyn-docs: 12430d193e1891b87a677d6b45a3b17861c83518
> > > > brooklyn-library: 76c0c720edfcd9ad4f7bd70352ece6f08fb5aaad
> > > > brooklyn-server: 1ccdef868ae798add88f51e269df87c01bd8544f
> > > > brooklyn-ui: 307382128951bb237bc351ac22136745e5d50475
> > > > All of the above have been tagged as "apache-brooklyn-0.9.0-rc1".
> > > >
> > > >
> > > > Please vote on releasing this package as Apache Brooklyn 0.9.0.
> > > >
> > > > The vote will be open for at least 72 hours.
> > > > [ ] +1 Release this package as Apache Brooklyn 0.9.0
> > > > [ ] +0 no opinion
> > > > [ ] -1 Do not release this package because ...
> > > >
> > > >
> > > > Thanks,
> > > > Richard.
> > > >
> > >
> > --
> > Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> > http://www.cloudsoftcorp.com/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>

Re: CLI packaging problem

[John McCabe]

And a reminder that https://github.com/apache/brooklyn-client/pull/11 will
need to be merged to ensure Jenkins builds the current code in the repo
rather than the cached copy in godeps/_workspace

On Thu, 24 Mar 2016 at 18:47 Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:

>
> The brooklyn-client Apache build adds the CLI binaries in a zip file to
> the Apache Jenkins.
>
> E.g. See links at end of
> https://builds.apache.org/view/Brooklyn/job/brooklyn-client-master/9/console
>
> …
> Uploaded:
> https://repository.apache.org/content/repositories/snapshots/org/apache/brooklyn/brooklyn-client-cli/0.9.0-SNAPSHOT/brooklyn-client-cli-0.9.0-20160321.101320-2-bin.zip
> <
> https://repository.apache.org/content/repositories/snapshots/org/apache/brooklyn/brooklyn-client-cli/0.9.0-SNAPSHOT/brooklyn-client-cli-0.9.0-20160321.101320-2-bin.zip
> >
>
>
>
> All you would need to do would be to add that to the same location as the
> main Brooklyn zip.
>
> As discussed with Duncan, for convenience it would be good to unpack the
> zip file before uploading it so users could just get the right binary
> without having to download the zip.  I’d just put up the Windows, Mac and
> Linux builds.
>
>
>
>
> 
> Gnu PGP key - http://is.gd/uI
>
>
> > On 24 Mar 2016, at 18:32, Aled Sage <aled.s...@gmail.com> wrote:
> >
> > +1
> >
> > We won't have the brooklyn-client RPM in time for a 0.9.0 release, but
> we should definitely work on that afterwards.
> >
> > ---
> > We can add a download link for the CLI to
> http://brooklyn.apache.org/download/index.html, once there is an official
> apache release of the CLI.
> >
> > I believe the release manager copies the final artifacts to the right
> place in apache, giving us the nice download links. We can do the same for
> the CLI, as long as we have an appropriate artifact to put there from the
> 0.9.0 release process.
> >
> > Aled
> >
> >
> > On 24/03/2016 18:12, John McCabe wrote:
> >> +1 Geoff
> >> Having a CLI download alongside the brooklyn release as well makes
> sense,
> >> like the web ui the user should be able to run the client from their
> local
> >> machine to connect to a remote brooklyn instance (which is supported and
> >> imho preferable since it keeps you off the server), bundling it only in
> the
> >> release means the user has to either copy br from the node brooklyn is
> >> running on or download a full brooklyn release only to get at the cli
> tool
> >> which seems unnecessary.
> >> I'd be inclined to package it (rpm, brew etc) separately as well -
> >> installing the brooklyn rpm would pull in the client as a dep (will
> need to
> >> be in a repo to make this painless). For a client install you could use
> >> brew/port on OSX, possibly Chocolatey on Windows.
> >>
> >> On Thu, 24 Mar 2016 at 17:56 Geoff Macartney <
> >> geoff.macart...@cloudsoftcorp.com> wrote:
> >>
> >>> I suggest adding the CLI artifacts to the release alongside the
> brooklyn
> >>> zip.  At the same time as the brooklyn zip is copied to the release
> >>> location, get the CLI artifact out of the Maven repository, for good
> >>> measure unpack it, and upload the individual builds of the CLI tool to
> the
> >>> same location.  Then update docs to explain how to download it too.
> >>>
> >>> Remember the vagrant approach is really there as a Getting Started
> track,
> >>> it’s not the typical path for using Brooklyn in anger.
> >>>
> >>>
> >>> 
> >>> Gnu PGP key - http://is.gd/uI
> >>>
> >>>
> >>>> On 24 Mar 2016, at 17:51, Duncan Godwin <
> duncan.god...@cloudsoftcorp.com>
> >>> wrote:
> >>>> Hi All,
> >>>>
> >>>> I've found a problem with the way the CLI is distributed for Brooklyn.
> >>> It's
> >>>> included in the release files which means when an initial user uses
> the
> >>>> vagrant getting started guide, the CLI is inside the vagrant box, not
> on
> >>>> the users machine. As there's no download link to the CLI anywhere it
> >>> means
> >>>> the flow of the documentation no longer works.
> >>>>
> >>>> The solutions to this could be:
> >>>>
> >>>> * Add additional downloads for each of the CLI versions somewhere
> >>>> * Extract the correct CLI from the vagrant box to the users machine in
> >>> the
> >>>> instructions
> >>>> * Download the CLI bundle and extract and install the correct one
> >>>>
> >>>> What are everyone's thoughts?
> >>>>
> >>>> Many thanks
> >>>>
> >>>> Duncan
> >>>
> >
>
>

Re: Brooklyn Daemon Solution

[John McCabe]

[bumping so aleks can see the thread]

On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
andrew.kenn...@cloudsoftcorp.com> wrote:

> Or what about running a Brooklyn Docker image as a systemd service!
>
> - http://container-solutions.com/running-docker-containers-with-systemd/
> - https://github.com/ibuildthecloud/systemd-docker
>
> Andrew.
>
> On Thu, 28 Jan 2016 at 16:34 Alex Heneveld <
> alex.henev...@cloudsoftcorp.com>
> wrote:
>
> >
> > Hi Aleksandr-
> >
> > What's the advantage of a native daemon over just wrapping it as a linux
> > service script ?
> >
> > Best
> > Alex
> >
> >
> > On 28/01/2016 11:32, Aleksandr Vasilev wrote:
> > > Hello everyone!
> > >
> > > I spent last few days looking at the solution to run Brooklyn process
> as
> > a
> > > daemon and found two options:
> > > 1. Run daemon via Apache Commons Daemon (jsvc)
> > > 2. Write a custom daemon in C
> > >
> > > Both solutions has its own pros and cons, so let's look at what I think
> > > they are:
> > >
> > > JSVC:
> > > Pros:
> > > - Ready to use solution. Running a daemon via jsvc is very similar to
> > > running java application from the command line with similar arguments
> > > passed.
> > > - Builds as usual in Maven
> > >
> > > Cons:
> > > - Still requires you to write daemon code, which in my opinion kills
> the
> > > out-of-the-box usability
> > > - Has tons of bugs, including: not been able to find classes in
> > classpath,
> > > not been able to run by non-root users, not been able to run on several
> > > *nix systems (Mac OS, BSD)
> > > - The codebase hasn't changed since 2013 and seems abandoned
> > > - SVN repo often isn't accessible for some reason, right now the
> > webserver
> > > returns 503 error code:
> > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/
> > >
> > > Custom Daemon (written in C):
> > > Pros:
> > > - Cross-platform, runs on any *nix system supported by Brooklyn
> > > - Very little code to maintain
> > > - Independent from third-party solutions, requires only gcc to build
> > > - Easy to make LSB-compliant init scripts to control the daemon
> > >
> > > Cons:
> > > - Requires some overhead to build C code in Maven
> > >
> > > Having all these options considered, I propose writing daemon for
> Apache
> > > Brooklyn in C language and use gcc compiler to build it. It will
> require
> > > introducing some changes to Maven build process, but there are plenty
> of
> > > solutions for doing this, such as Maven NAR plugin, which is actively
> > > maintained:
> > > https://github.com/maven-nar/nar-maven-plugin
> > >
> > > Best Regards,
> > > Aleksandr Vasilev
> > > DevOps Engineer | Cloudsoft Corporation
> > >
> >
> > --
>
> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
>

Re: move to new repos THIS WEEKEND ?

[John McCabe]

Looks good, checked out, built and deployed a test app without any observed
issues.

Will there a cut off on getting PRs merged today or tomorrow?

On Thu, 28 Jan 2016 at 10:09 Alex Heneveld 
wrote:

>
> Brooklyners-
>
> TL;DR: *switch to new repos at the weekend, incubator commits cut-off
> proposed for Sat 10am UK*
>
> The new project structure seems to be working well and I think it's time
> to move to the new repos apache/brooklyn and apache/brooklyn-*, and then
> retire the incubator project.
>
> I've built on Richard's separation scripts, with the current version at
> https://github.com/ahgittin/brooklyn-repo-split, and it also seems to be
> working very well.  You can inspect the resulting projects at these URL's:
>
>  https://github.com/ahgittin/brooklyn
>  https://github.com/ahgittin/brooklyn-dist
>  https://github.com/ahgittin/brooklyn-docs
>  https://github.com/ahgittin/brooklyn-library
>  https://github.com/ahgittin/brooklyn-server
>  https://github.com/ahgittin/brooklyn-ui
>
> You can try them for yourself e.g. using:
>
>  for x in brooklyn{,-{dist,docs,library,server,ui}} ; do
>  git clone g...@github.com:ahgittin/$x.git
>  done
>  cd brooklyn/
>  mvn clean install
>
> I have done a lot of checking that these are all healthy -- see below --
> but I'd value some others also casting their eyes over the projects.  If
> there are other checks I should do when I run them again please let me
> know.
>
> If this looks good I propose we wait until the weekend to cut over. If
> there is no objection we would STOP committing to the incubator project
> at Saturday 10am UK, and I will re-run the scripts, test, and push to
> apache/ repos instead of ahgittin.
>
> Meanwhile I have some notes on migrating incubator PR's and branches to
> the new repos and on using subprojects which I will complete and circulate.
>
> Best
> Alex
>
>
> CHECKS I'VE DONE
>
> A) The command:
>
>  git log --oneline --follow `find . -name AbstractEntity.java`
>
> gives the same output modulo commit ID's and excluding the additional
> directory promotion commit in the new repo, 415 commits total
>
> B) `find .` gives the same output, modulo items in the root and the
> .git/ dirs (actual command: `find -E . \! -regex '.*/\.git(/.*)?' \!
> -regex '\./[[:alnum:]\.]+'`)
>
> C) Both builds work and the built artifacts are identical except for
> MANIFEST.MF (Implementation-SHA-1 and Bnd-LastModified) and
> pom.properties (timestamp)
>
> D) Size of project is the same and history is substantially smaller:
>
> incubator:
>
> 262M./.git
>   44K./brooklyn
> 652K./brooklyn-dist
>   16M./brooklyn-docs
> 9.6M./brooklyn-library
>   19M./brooklyn-server
> 5.1M./brooklyn-ui
> 312M.
> of which 262M is */.git, 50M current
>
> new:
>
> 180K./brooklyn/.git
> 224K./brooklyn
> 812K./brooklyn-dist/.git
> 1.4M./brooklyn-dist
>   20M./brooklyn-docs/.git
>   36M./brooklyn-docs
>   15M./brooklyn-library/.git
>   24M./brooklyn-library
>   36M./brooklyn-server/.git
>   55M./brooklyn-server
> 7.6M./brooklyn-ui/.git
>   13M./brooklyn-ui
> 129M.
> of which 79M is */.git, 50M current
>
> The size improvement comes of course from big WAR artifacts in ancient
> history which aren't being copied across.
>
> The remaining size is mostly accounted for by:
> * screenshots in docs
> * some big JS in library/sandbox history and in ui (a bit of a shame as
> when we move to bower/grunt these deps won't be part of the repo, but a
> few megs isn't really that much)
> * lots of files in server and its history (none esp big, nearly all needed)
>
> END
>
>

Re: Incubator re-org

[John McCabe]

Hi All -
We've raised pull request 1119 [1] which implements the restructuring of
the incubator-brooklyn project in preparation for the split into multiple
repositories.

You can checkout the PR locally and build as normal,
Regards,
John

## Snippet from the PR [1]
This pull applies the pre-repository-split restructuring script
1-rearrange-incubator.sh from rdowner/brooklyn-repo-split#5 [2], and
updates maven/tests accordingly.

Once applied the project will be structured in preparation for the split
into multiple git repositories (brooklyn-server, brooklyn-ui,
brooklyn-library, brooklyn-dist, brooklyn).

A verbose commit history is maintained for reference with each commit
prefixed by the impacted submodule, ie [SERVER], [LIBRARY] etc. (Note the
work-in-progress repo was originally located here [3].)

The project can be built as normal, with a brooklyn pom in the root of the
repository.

You may also build each submodule in turn, brooklyn-ui, brooklyn-server,
brooklyn-library and finally brooklyn-dist. The brooklyn subdirectory will
eventually become the split repo base project,.

Feedback is greatly welcomed.

[1] https://github.com/apache/incubator-brooklyn/pull/1119
[2] https://github.com/rdowner/brooklyn-repo-split/pull/5
[3] https://github.com/johnmccabe/PRESPLIT-incubator-brooklyn

On Sat, 19 Dec 2015 at 12:43 Alex Heneveld 
wrote:

> Hi All-
>
> John has been doing fantastic work at [1] for post-restructure tweaks so
> that everything builds nicely.  It is close to the point where we can
> merge it.
>
> This can be done following the normal PR process but because it is a
> major reorg I wanted to (a) flag it and (b) do it when it's a quiet time
> (like tomorrow maybe?).  We've discussed this already so it shouldn't
> come as a surprise, but things to be aware of.
>
> Once this is merged:
>
> 1) Existing branches and PR's may have to be rebased or merged
> 2) Your IDE may have to be completely reset
>
> On (1) git actually does a remarkable job of tracking things across
> moves, so I expect conflicts will mainly be:
>
> * where you have added or deleted files
> * where you have changed something which has changed (especially the poms)
>
> If you have a PR or WIP which does these it will be a bit easier to
> merge them first so please let us know.  In particular there is UI,
> OSGi, and Salt work in progress I think we were hoping to merge. But I
> don't want to hold up the migration for too long.
>
> FYI it will be a little bit more tedious to migrate these changes across
> to the new repo structure (ie apache/brooklyn{,-*}) but git-patch
> assuming we keep the same filesystem structure using git modules should
> work pretty well once you have rebased on the reorged incubator project.
>
> Best
> Alex
>
> [1]
> https://github.com/johnmccabe/PRESPLIT-incubator-brooklyn/commits/reorg
>

Re: Repository splitting script

[John McCabe]

I've got server/library/ui/dist building but with quite a few
caveats/problems.

1. multiple dependencies on brooklyn-software-base (CAMP/REST
Server/Launcher etc) - I suspect this belongs in the brooklyn-server repo
rather than brooklyn-libraries (I'd added it back into my test repo [1]

2. qa module heavily dependant on brooklyn-software-* from the
brooklyn-library repo - move to the  brooklyn-library repo or introduce a
new repo? (I'd disabled it in [1])

3. tests in brooklyn-camp module depending on brooklyn-software-* from
brooklyn-libraries repos  (EnrichersSlightlySimplerYamlTest,
EntitiesYamlIntegrationTest, JavaWebAppsIntegrationTest,
MapReferenceYamlTest, ObjectsYamlTest) - refactor (?) or move (I just
commented these out for the moment)

4. unable to build brooklyn-server with -Dmaven.test.skip=true as there
were dependencies on generated test jars (didn't dig into this, commented
out problem tests - see #3)

5. tests in brooklyn-ui depend on  brooklyn-rest-server,
brooklyn-test-support, brooklyn-api, brooklyn-core etc (built
with -Dmaven.test.skip=true for the moment)

6. both brooklyn-launcher and karaf apache-brooklyn (Distro) currently
depends on brooklyn-jsgui war from brooklyn-ui repo for build, both will
build without it present but launching brooklyn throws
'java.io.IOException: brooklyn.war not found on classpath', supplying
'--startupContinueOnWebErrors' allows start to proceed but the REST API
isn't accessible. What is the desire here, to start without a UI by default
- ie just the REST API? Start the UI automatically if detected on the
classpath or require the user to explicitly request a UI be started?

7. do we want to create equivalents to brooklyn-all/brooklyn-parent for
each repo (brooklyn-server-all, brooklyn-library-all etc)

8. pulling it all together... any suggestions/ideas on the proposed
brooklyn repo?

I've used the build_wip branch on the following repos (generated using [2])
to investigate (I set the version to 0.9.1-SNAPSHOT to avoid clashing with
the current 0.9.0-SNAPSHOT artifacts):

- https://github.com/johnmccabe/TEMP-brooklyn-server/commits/build_wip
- https://github.com/johnmccabe/TEMP-brooklyn-library/commits/build_wip
- https://github.com/johnmccabe/TEMP-brooklyn-ui/commits/build_wip
- https://github.com/johnmccabe/TEMP-brooklyn-dist/commits/build_wip

You can currently build a dist in the following order (TODO the poms need
some serious tidying):

*TEMP-brooklyn-ui*
mvn clean install -Dmaven.test.skip=true

*TEMP-brooklyn-server*
mvn clean install

*TEMP-brooklyn-library*
mvn clean install

*TEMP-brooklyn-dist*
cd usage/all
mvn clean install
cd ../../usage/dist
mvn clean install


[1] https://github.com/johnmccabe/TEMP-brooklyn-server/commits/build_wip
[2]

On Wed, Dec 9, 2015 at 10:48 PM, Alex Heneveld <
alex.henev...@cloudsoftcorp.com> wrote:

> i think leave it `brooklyn/software/winrm` in the old hierarchy, and in the
> new hierarchy `brooklyn-server/software/winrm` alongside
> `brooklyn/software/base`
>
> `locations/*` is intended for implementations of `Location`
>
> --a
>
>
> On 9 December 2015 at 22:36, John McCabe <j...@johnmccabe.net> wrote:
>
> > Does locations/winrm sound reasonable? (rather than reverting back to
> > /core)
> >
> > On Wed, Dec 9, 2015 at 5:19 PM, Aled Sage <aled.s...@gmail.com> wrote:
> >
> > > +1
> > >
> > > Let's move winrm to brooklyn-server.
> > >
> > >
> > >
> > > On 09/12/2015 16:56, Hadrian Zbarcea wrote:
> > >
> > >> That should be (or at least become) a soft dependency, not a hard one.
> > >> That aside, the winrm piece probably belongs in server.
> > >>
> > >> Hadrian
> > >>
> > >> On 12/09/2015 11:27 AM, John McCabe wrote:
> > >>
> > >>> Alex, all, (fyi Hadrian/Ciprian),
> > >>>
> > >>>
> > >>> * fix pom files on result of `rearrange-incubator.sh` script so it
> > builds
> > >>>>
> > >>>>> (make this a diff / git cherry-pick we can just apply once all PRs
> > are
> > >>>>>> merged?)
> > >>>>>>
> > >>>>>> John also said to me that he would take a look at this problem. He
> > was
> > >>>>> temporarily prevented from doing so by a bug in the split script
> > which
> > >>>>> broke TEMP-brooklyn-server, but that dodgy repo should now be
> fixed.
> > >>>>>
> > >>>>> John - any update?
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>> Just after having a chat with Richard about this, and am in the
> > >>> process of
> > >