+1 to everything so far.
I'd also tempted to ask for Alex's REST API changes for bundle management
merged:
https://lists.apache.org/thread.html/0dd24780fc8491b6c735a7cedeba8c
5fb332c21f208c1cfa7259f012@%3Cdev.brooklyn.apache.org%3E
These seem like an important part of the "easy bundle management f
Hi all
I just pushed a PR for the RPM/DEB packages[1]. It's mostly done but still
have issue with DEB and upstart.
I'll try to fix it as quickly as I can.
Best.
[1] https://github.com/apache/brooklyn-dist/pull/104
On Fri, 8 Sep 2017 at 12:19 Thomas Bouron
wrote:
> I think it would be confusi
GitHub user tbouron opened a pull request:
https://github.com/apache/brooklyn-dist/pull/104
WIP - Improve RPM/DEB packages
The aim of this PR is to:
1. use Karaf launcher
2. improve the package to to handle properly installations and upgrades
This is spirit, this doe
GitHub user drigodwin opened a pull request:
https://github.com/apache/brooklyn-docs/pull/210
[WIP] Update to Karaf as default
Change the docs to specify Karaf as the default distribution
* Change install instructions
* Change paths
* Change brooklyn.properties -> brookly
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/791
very interesting link @geomacy - the stronger guarantee of `fcntl()`
probably what the activemq jni code does.
i think this PR is good and your fix here for the problem caused by th
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/812
note the two other PRs in downstream projects listed above
---
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-docs/pull/209
examples all updated, ready to merge after
https://github.com/apache/brooklyn-server/pull/812
---
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-library/pull/124
use external config provider for demo passwords
follow-on from https://github.com/apache/brooklyn-server/pull/812
You can merge this pull request into a Git repository by running:
$
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/812
OTOH someone using a live deployment might want to use one of the test
blueprints. The docs describe how to change the password:
https://github.com/apache/brooklyn-docs/pull/209/f
Github user duncangrant commented on the issue:
https://github.com/apache/brooklyn-server/pull/812
Should we make it easier to disable the provider? That way a "live"
deployment of amp would prevent it's use. So if a developer forgets to update
their yaml to use a real provider it w
Hi All-
I've had a couple exchanges where people are put off by passwords shown
in plain text in our demos. It's all well and good explaining it's for
demo but if we say "of course you should use an external provider" then
our examples do also.
In order not to require additional setup of t
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-docs/pull/209
[WIP] explain and use the `brooklyn-demo-sample` external provider
so far just explains it, need to use it
You can merge this pull request into a Git repository by running:
$ git pull h
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-server/pull/812
use external config in examples
some of our tests and examples used plain-text passwords, and this has
caused some alarm when people have seen them. we can say "you can use external
but
Github user asfgit closed the pull request at:
https://github.com/apache/brooklyn-server/pull/811
---
I think it would be confusing for a user to have 2 sets of RPM/DEB
packages: one for classic launcher and one for Karaf launcher.
I'm in favour of having only one set that uses exclusively the Karaf
launcher (also, that mirrors what we had up until now, i.e. only one
RPM/DEB set that was using the
Geoff, agree we should be adding it to adjunct, that'll be looked at as
part of a stage 2 (Alex is going to pick this up). Not sure about the
term "usage
metadata" things like triggers wouldn't be usage info, and if we extend
this to adjuncts I imagine people writing enricher highlights might want
Following on from that, I have made a PR to make the karaf release the
primary one and release the old one as `classic`
https://github.com/apache/brooklyn-dist/pull/103
Thanks for your input Thomas. I think that we should only release one set
of RPM and deb packages and make those the karaf versi
GitHub user drigodwin opened a pull request:
https://github.com/apache/brooklyn-dist/pull/103
Make karaf release the primary one
As discussed on the mailing list this PR moves to making the karaf release
the primary artifact.
You can merge this pull request into a Git repository by
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/811
note:
* 32285720a098eef1769c202cadd12390d4ef1a7c fixed this for SshML but missed
this
* https://github.com/apache/brooklyn-server/pull/536 backported a fix
including WinRM to 0
Github user geomacy commented on the issue:
https://github.com/apache/brooklyn-server/pull/791
You're right @ahgittin, the `sync` should be done before the `close`; I
have added another commit to do this.
I agree I'm not sure that the problem was caused by a failure to commit
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-server/pull/811
fix npe that can occur with WinRM when no subnet IP
do a better job of returning public IP but above all don't NPE
You can merge this pull request into a Git repository by running:
$
21 matches
Mail list logo
