[
https://issues.apache.org/jira/browse/BROOKLYN-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16157842#comment-16157842
]
ASF GitHub Bot commented on BROOKLYN-526:
-
Github user ahgittin commented on the
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/791
@geomacy @aledsage I hadn't realized this either; javadocs and online
searches suggest the `fd.sync()` may be needed.
i'm curious whether this really is the issue -- at least on Mac
Hi team-
As mentioned earlier, I've been working on adding bundle support to the
REST API, so we can add/remove/query bundles. And related to this, and
the type registry, is the ability to add arbitrary types but until now
there was no way to query those, so there are endpoints for types/ an
Hi Duncan.
I agree, a new version of Brooklyn would be great. I particularly support
the change of making Karaf the default distribution.
I'm actually working on various improvements of the RPM and DEB packages,
and make them use Karaf as well. I should push a PR for this next week.
Regarding the
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/810
---
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-server/pull/810
REST API for bundles, types, and subtypes
also tweaks to other classes to make them more usable, eg VersionedName
comparables and bundle removal giving an OsgiBundleInstallationResult
Hi All,
It's probably about time for a Brooklyn 0.12.0 release. There have been
significant developments since 0.11.0 which warrant a new release. Before
we produce this however I propose we make the following changes:
- Make Karaf the default distribution with the current `classic` launch
method
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-ui/pull/48
Show containing bundle
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ahgittin/brooklyn-ui show-containing-bundle
Alternatively you can r
Github user asfgit closed the pull request at:
https://github.com/apache/brooklyn-server/pull/799
---
Github user geomacy commented on the issue:
https://github.com/apache/brooklyn-server/pull/791
@aledsage finally got round to checking this against the integration tests.
It doesn't seem to have caused any significant problems - with a run of the
tests against current `master`
+1 to this, with Thomas's suggestion of a list instead of map and
Geoff's suggestion of doing it on adjuncts. would be nice to have an
adjunct api which lets clients treat policies, enrichers, and feeds the
same.
i can see this being useful for policies to record selected highlights
of the
Hi Graeme.
Sounds very useful to me. Would be great to have this info properly
formatted in the CLI and UI.
As for the structure, I would suggest to avoid spaces in map keys as best
practice, so having either:
[{
...
"highlights": {
"lastConfirmation": {
"name": "Last Confirmation
Just a few thoughts -
It seems extremely ad-hoc. Why for policies and nothing else? What would
the "schema" of these "highlights" be? ("Highlights" is very vague; is
"usage metadata" a better term, given the sort of data you propose to
include in it?)
Is adding the data into the `policies` endpo
Hello,
I'd like to make a change to the REST API for policies. As this is a REST
API change I figured it would be best to flag it on the mailing list first
in case anyone has any objections.
It would be useful when consuming this API to be able to find out more
information about the policy. Speci
Github user tbouron commented on the issue:
https://github.com/apache/brooklyn-server/pull/777
@ahgittin NP, I don't contest the why, I'm sure there was a good reason
(confirmed by the above explanation) I was just surprised that this wasn't
flagged before for downstream project or bl
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/777
@rdowner Release notes updated now in
https://github.com/apache/brooklyn-docs/pull/208 . ML discussion triggered by
@tbouron (TY) and you are completely correct, that should have been done
GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-docs/pull/208
update release notes for 0.12, adding a few things i'm aware of
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ahgittin/brooklyn-docs r
Thanks Thomas, and Richard. More details:
This removed the boolean `cluster.first` set on group members -- code
that was marked in the code for removal (and which was ambiguous and
buggy eg if an entity is in two groups, and which caused deadlocks when
using dynamic group membership).
It d
Hi Brooklyner.
Just a quick heads-up for those who are using `DynamicCluster` and more
specifically, `cluster.first.entity` sensor on cluster members.
There was a change introduced by this PR[1] that removes the sensor from
cluster members. This breaking change was merged to fix a potential
deadl
Github user rdowner commented on the issue:
https://github.com/apache/brooklyn-server/pull/777
@ahgittin this appears to go against our published deprecation policy and
is known to break some blueprints.
Your PR comments are making references to previous discussions, but it's
Github user drigodwin commented on the issue:
https://github.com/apache/brooklyn-server/pull/805
This PR swaps the mechanism Brooklyn is using to destroy a node to one
which is less tested within Brooklyn. The problem it addresses has been fixed
upstream in jclouds so assuming we can
Github user asfgit closed the pull request at:
https://github.com/apache/brooklyn-docs/pull/207
---
22 matches
Mail list logo
