+1 from me too - new features have stabilized, including workflow and
kubernetes updates so this makes sense
On Mon, 15 Jan 2024 at 20:38, Geoff Macartney
wrote:
> Hi Juan,
>
> +1 from me. A new release is long overdue.
>
> Cheers
> Geoff
>
>
>
> On Mon, 15 Jan 2024, 12:31 Juan Cabrerizo,
s it make if the
> attributeWhenReady is in a pre-apply workflow or not? Why doesn't the same
> problem occur as you've described?
>
> Geoff
>
>
>
> On Mon, 1 May 2023 at 09:21, Alex Heneveld wrote:
>
> > Hi folks,
> >
> > I've got a question about the best way
Hi folks,
I've got a question about the best way to do some "start-only" DI using the
downstream Brooklyn-Terraform project, and I wondered what people's
thoughts are on the best way to do something.
The situation is that we have a mid-tier TF and a data-tier TF, and as you
might expect we need
it's normal: it's a change in Jetty. I remember I
> made changes about that. Let me find commits/Jira related to that.
>
> At first glance, I don't see any new changes required in Karaf (for
> 4.4.3), but I will do a pass anyway.
>
> Regards
> JB
>
> On Tue, Dec 20, 2022 at
ight now preparing 4.4.3 and 4.3.9 releases. Not sure I will have
> time to include any change related to these points, but I will try.
> Else, I will move forward pretty fast new releases just after.
>
> Regards
> JB
>
> On Mon, Dec 19, 2022 at 2:20 PM Alex Heneveld wrote:
>
Hi JB, Team,
I'm upgrading various OSGi deps in Apache Brooklyn and have hit three
curious issues:
(1) bin/client disconnects immediately after authentication if no command
specified; this is after enabling the karaf user in etc/users/properties,
`bin/client bundle:list` works, but `bin/client`
Best
Alex
[1]
https://docs.google.com/document/d/1u02Bi6sS8Fkf1s7UzRRMnvLhA477bqcyxGa0nJesqkI/edit#heading=h.63aibdplmze
On Fri, 18 Nov 2022 at 13:44, Alex Heneveld wrote:
> Hi team,
>
> I've got most of the proposed "lock" implementation completed, as
> discussed in
nk I've got a better way to handle those, and a tweak to error
handling. It's described in this section:
https://docs.google.com/document/d/1u02Bi6sS8Fkf1s7UzRRMnvLhA477bqcyxGa0nJesqkI/edit#heading=h.63aibdplmze
There are two questions towards the end that I'd especially value input on.
Thanks
A
As a member of the Apache Brooklyn PMC I'd be pleased to see jclouds
sustained a bit longer.
Increasingly in AB people are using custom containers (eg AWS CLI),
terraform, helm, and other tools to drive creation, but for well-behaved
VMs without much thought jclouds is usually simpler than any of
Hi team,
Workflow is in a pretty good state -- nearly done mostly as per
proposal, with nearly all step types, retries, docs [1], and integrated
into the activities view in the inspector. My feeling is that it radically
transforms how easy it is to write sensors and effectors.
Thanks to
together will be pretty powerful.
> >
> > Will try to get a look at the latest PR if I can.
> >
> > Cheers
> > Geoff
> >
> >
> > On Mon, 19 Sept 2022 at 17:31, Alex Heneveld wrote:
> > >
> > > Geoff- Thanks. Comments ad
e longhand:
- type: retryable-gcloud-dataproc-with-bucket-and-sensor
input:
bucket: my-bucket
sensor_name: my-spark-output
Best
Alex
On Sat, 17 Sept 2022 at 21:13, Geoff Macartney wrote:
> Hi Alex,
>
> Belatedly reviewed the PR. It's looking good! And surprisingly s
58
[2]
https://docs.google.com/document/d/1u02Bi6sS8Fkf1s7UzRRMnvLhA477bqcyxGa0nJesqkI/edit#heading=h.gbadaqa2yql6
On Wed, 7 Sept 2022 at 09:58, Alex Heneveld wrote:
> Hi Peter,
>
> Yes - thanks for the extra details. I did take your suggestion to be a
> procedural DSL not YAML, per
00 p.m. over 11.00.
>
> Cheers
> Geoff
>
> On Thu, 1 Sept 2022 at 12:41, Alex Heneveld wrote:
> >
> > Thanks for the excellent feedback Geoff and yes there are some very cool
> and exciting things added recently -- containers, conditions, and terraform
> and kubernet
> the contents, which would then be injected into the class framing code
> > before compilation.
> >
> > These are just ideas. I'm not familiar enough with Brooklyn in its
> current
> > implementation to be able to create realistic pseudocode.
> >
> >
Thanks for the excellent feedback Geoff and yes there are some very cool
and exciting things added recently -- containers, conditions, and terraform
and kubernetes support, all of which make writing complex blueprints much
easier.
I'd love to host a session to showcase these.
How does Wed 7 Sept
infrastructure projects, small errors can have disastrous consequences,
> so
> >> as little as a missing or extra tab could result in destroying a data
> >> resource or bringing down a complex system. The other, more
> philosophical
> >> comment has to do with the clumsines
Hi folks,
I'd like Apache Brooklyn to allow more sophisticated workflow to be written
in YAML.
As many of you know, we have a powerful task framework in java, but only a
very limited subset is currently exposed via YAML. I think we could
generalize this without a mammoth effort, and get a very
Hi Devs,
I've implemented this in https://github.com/apache/brooklyn-server/pull/1326
. For documentation, see:
https://github.com/apache/brooklyn-docs/pull/358/files
This should make working with dynamic groups and multigroups much nicer!
Best
Alex
On Fri, 17 Jun 2022 at 14:52, Alex
Hi devs,
We are seeing more use of predicates and specs in blueprints. These are
powerful features and not too hard to express in blueprints using the
`$brooklyn:object` and `$brooklyn:entitySpec` DSL constructs, but I'm
thinking it's worth what I think will be a fairly small level of effort to
[
https://issues.apache.org/jira/browse/BROOKLYN-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld deleted BROOKLYN-631:
---
> Vapespring
> --
>
> Key: BROOKLYN-631
>
Deleted -- I had the power, under "More"
--A
On 19/04/2021 12:04, Duncan Grant wrote:
I'm probably logging into jira using the wrong creds but I don't seem to be
able to delete this. Can someone please delete it.
-- Forwarded message -
From: Vape Spring (Jira)
Date: Sat,
[
https://issues.apache.org/jira/browse/BROOKLYN-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld closed BROOKLYN-631.
--
Resolution: Invalid
Bloody spam
> Vapespring
> --
>
> K
Hi Iuliana,
This would be an awesome addition. The use of beans is really powerful
and this lets us do even more with them.
I'd like us to support *both* the `["user"]` and the `.users` syntax.
The former could allow accessing other DSL values (if you use a DSL
expression rather than a
.
What do you think?
Geoff
[1] https://www.aqute.biz/2017/04/24/aggregate-state.html
On Mon, 23 Nov 2020 at 11:12, Alex Heneveld wrote:
Hi Brooklyn devs,
Regarding the recent addition to allow custom Bundle Resolver OSGi
services [1], we've discovered a bothersome issue with load order at
runti
rmed features set.
Regards
JB
Le 23 nov. 2020 à 12:44, Alex Heneveld a écrit :
hi Karaf devs-
i have a question about start-level behaviour in karaf/felix. the osgi spec says that start-levels
should increase 1 by 1 during startup [1]. this doesn't seem to be happening in a clean
will be deployed before the second
one.
So, in your case, I would use a well formed features set.
Regards
JB
Le 23 nov. 2020 à 12:44, Alex Heneveld a écrit :
hi Karaf devs-
i have a question about start-level behaviour in karaf/felix. the osgi spec says that start-levels
should increa
hi Karaf devs-
i have a question about start-level behaviour in karaf/felix. the osgi
spec says that start-levels should increase 1 by 1 during startup [1].
this doesn't seem to be happening in a clean karaf-based environment.
what we observe is that startlevel jumps directly to the
Hi Brooklyn devs,
Regarding the recent addition to allow custom Bundle Resolver OSGi
services [1], we've discovered a bothersome issue with load order at
runtime. It is non-deterministic whether a custom resolver bundle loads
before or after the initial catalog.bom and persisted state. If
of
Brooklyn meta-data, namely a location (`location: my-local-docker`)
and application name.
Could you maybe sketch out what the requests would look like to add a
Dockerfile to the catalog, and to deploy it to a Docker instance?
What about, say, a K8s deployment descriptor, again to add it to
Hi Brooklyners,
Since the Catalog was overhauled many years ago with the TypeRegistry
approach, we have had support in the back-end for custom types and for
custom plan formats. The former is useful e.g. if you want to add a new
type to be used as a config key or initializer. The latter
Thanks Geoff, and Jclouds team, and Markus for the contribution.
FWIW regretfully I'd rather jclouds *didn't* do this. Personally I
don't see benefits to Apache Brooklyn and I *do* see it increasing our
dependency hell -- as ugly as shading is, it spares us that problem.
Given that it
Hi team-
I've taken a deeper look at the license/notice issues raised by Justin
and I think have resolved them in PR [1] (and various PRs it
references). A summary is below. Justin, thank you for spotting these
bugs.
If anyone has comments please reply here or on the issue [1].
Good find. I agree this sounds like a blocker. (Easy to fix fortunately!
IMT guessing log message format changed with the karaf bump? We should grep
on the Brooklyn started message instead of a karaf message!)
Best
Alex
On Thu, 6 Feb 2020, 14:26 Iuliana Cosmina, <
Geoff / team-
> the sensor in question is defined as
>
> static.value: $brooklyn:config("my.app.port")
>
> not sure why it is reported as static.value:
>
!!org.apache.brooklyn.camp.brooklyn.spi.dsl.methods.DslComponent$DslConfigSupplier
> in the error logs.
Good spot! It seems like it is
+1
On 17/01/2020 16:03, Duncan Grant wrote:
+1
On Fri, 17 Jan 2020 at 16:03, Paul Campbell
wrote:
+1 :)
On Fri, 17 Jan 2020 at 16:02, Martin Harris wrote:
+1
M
On Fri, Jan 17, 2020 at 4:00 PM Aled Sage wrote:
Hi all,
I believe we are (finally!) ready to produce Apache Brooklyn
Hi Peter,
It needs to be the JAR not the class. Either the dropins folder or 'br
catalog add' is fine. You can confirm the former in the karaf bin/client
bundle:list or the latter in the Brooklyn catalog UI view.
It may be that the reference in OSGi needs to be to
'your.bundle:package.Clazz'.
Juan-
This looks really good to me.
If you don't use OAuth, no change, and `br` works as it always has.
If you do need OAuth, you define the process to get the header (maybe
another script, say br-my-oauth), which can then use`br` to persist the
header for subsequent usage by `br`. You'll
request, I have a couple of
questions.
I think you're missing a link to the PR (ref[1]).
When I try the latest Brooklyn snapshot it basic auth is not enabled. How
would I re-enable it? Or do we now need to write a basicauth security
provider?
Regards
Duncan
On Wed, 16 Jan 2019 at 11:20, Alex
[
https://issues.apache.org/jira/browse/BROOKLYN-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld closed BROOKLYN-606.
--
Resolution: Invalid
> ATG Stores (client) impression & MUV usage is in
[
https://issues.apache.org/jira/browse/BROOKLYN-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746533#comment-16746533
]
Alex Heneveld commented on BROOKLYN-606:
Thanks, you guys are in the wrong Jira
[
https://issues.apache.org/jira/browse/BROOKLYN-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746512#comment-16746512
]
Alex Heneveld commented on BROOKLYN-606:
Is this spam or just mis-reported? cc [~infrastruct
Hi All-
We've had quite a few requests to support OAuth, and I'm pleased to say
we can now support it via plugins.
Folks are still working on sample plugins for Google and/or GitHub, but
enough is there already for people to write their own to integrate with
their choice of OAuth servers.
It should have a mvn profile like rpm and the go cli IMO. The README in the
master project describes these.
Best
Alex
On Fri, 14 Dec 2018, 22:51 Geoff Macartney We added this in https://github.com/apache/brooklyn-dist/pull/118, but I
> do
> dislike having to have Docker to build Brooklyn. IMHO
As per thread below: my `git pull` just failed, but this command in the
root brooklyn dir worked seamlessly for me:
*for x in .git/{config,modules/*/config} ; do sed -i.bk
s/git-wip-us/gitbox/g $x ; done**
*
(I use submodules; slight tweaks should take care of it for other
Hi Sylvain-
My 2p ... I like all of these ideas, been thinking the same myself, with
one exception.
I like the green "+" button as it gives an alternative way to add
something. But could be talked out of it if others think it's too
confusing having these multiple ways.
The rest of it,
+1
I've implemented this for the server side at
https://github.com/apache/brooklyn-server/pull/999 .
One minor tweak to Aled's proposal, I think we should output a
structured YAML rather than the toString, so clients don't have to do
complex parsing. IE instead of sending the string
hi Nino
in that case you're probably better to create a new yaml-based entity to
launch karaf.
brooklyn supports windows, it's just that a lot of the blueprints that
come pre-bundled are
limited to certain environments.
what are you looking to do?
best
Alex
On 14/09/2018 10:38, nino
+1
We might want to make an effort to get these merged (but I don't think
it's critical):
* https://github.com/apache/brooklyn-server/pulls
#982 - better type coercion
#971 - location DSL
There are a few others in library, docs, and dist, which we should take
care of as
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.
T
McKenna
Aled Sage
Richard Downer
Geoff Macartney
Alex Heneveld
Best,
Alex
On 26/07/2018 10:32, Alex Heneveld 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
Hi Incubator PMC,
With 72h elapsed and no -1's I understand this to have passed. This
thread is now closed.2
I will update the forn [3] and we will continue the process in the
Brooklyn PMC.
Best
Alex
On 23/07/2018 09:56, Alex Heneveld wrote:
Hi Incubator PMC,
// cc dev@brooklyn
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
Hi Incubator PMC,
// cc dev@brooklyn
The top-level Apache Brooklyn project has been donated code for a new
UI, being referred to as "brooklyn-ui-angular".
This is the formal request for IP clearance to be checked as per [1].
The donated code can be found at [2] (*), along with links to the
://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling
On 28/05/2018 12:46, Alex Heneveld wrote:
Dear Brooklyners,
Our users at Fujitsu, UShareSoft, and Cloudsoft have generously
sponsored the contribution of a new UI for Apache Brooklyn. This is
based on the previously
o clarify whether we should do the same for all
our repos (I assume so). I intend to raise PRs to do this if so.
Geoff
On Wed, 20 Jun 2018 at 13:47 Alex Heneveld
wrote:
Hi Brooklyn devs-
In prepping the new UI contribution I've been working on the LICENSE
file generation. It is rather exten
Hi Brooklyn devs-
In prepping the new UI contribution I've been working on the LICENSE
file generation. It is rather extensive because by using Angular we
pull in hundreds of JS deps for the binary, most of them under MIT
license which as I understand it means copyright information must be
Dear Brooklyners,
Our users at Fujitsu, UShareSoft, and Cloudsoft have generously
sponsored the contribution of a new UI for Apache Brooklyn. This is
based on the previously-proprietary Cloudsoft AMP UI, for those of you
familiar with that.
The proposed newly contributed UI has all the
[
https://issues.apache.org/jira/browse/BROOKLYN-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16469692#comment-16469692
]
Alex Heneveld commented on BROOKLYN-582:
Your analysis is correct. This is due to
https
go for it. is there a yaml entity in the community we can point people
to as part of the deprecation?
wherever possible i'd like to replace the system-specific java entities
like jboss with yaml equivalents in the community (ie outside apache
brooklyn).
--a
On 09/03/2018 10:28, Thomas
Alex Heneveld created BROOKLYN-579:
--
Summary: DNS lookups cached for too long
Key: BROOKLYN-579
URL: https://issues.apache.org/jira/browse/BROOKLYN-579
Project: Brooklyn
Issue Type: Bug
Richard,
What values does it need? Would it make sense to put it into
BasicMachineMetadata and adjust JcloudsLocation.getMachineMetadata to
add it for everything?
The other option if you want to opt-in at an initializer is for it to do
`location.getConfig(CALLER_CONTEXT)` -- there isn't
sounds reasonable
On 20/11/2017 15:08, Duncan Godwin wrote:
Hi All,
Brooklyn Vagrant has not been working since the release of 0.12.0 due to an
error in one of the URLs, this was noted in the email thread [1]. I propose
we remove vagrant from the 0.12.0 docs and website branch. Once we do a
Good catches Svet.
The user in quotes is an easy fix, following Ivana's #754 returning
correct json. One line fix at [1].
The CLI needs a lot more error checking. That's the downside of Go!
Geoff fwiw I suggest it be one issue with many things to track.
The eu-west-2 failure is indeed
Hi All-
I've noticed in a few blueprints using VanillaSoftwareProcess there is a
pattern like this:
```install.command:
$brooklyn:formatString:
- |
V1=%s
V2=%s
some_command ${V1} ${V2}
- $brooklyn:config("v1")
- $brooklyn:config("v2")
```
This is handy and has its uses
[
https://issues.apache.org/jira/browse/BROOKLYN-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245532#comment-16245532
]
Alex Heneveld commented on BROOKLYN-552:
almost certain this has been working. why does
[
https://issues.apache.org/jira/browse/BROOKLYN-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245528#comment-16245528
]
Alex Heneveld commented on BROOKLYN-551:
[~drigodwin] debug exceptions aren't necessarily
[
https://issues.apache.org/jira/browse/BROOKLYN-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245527#comment-16245527
]
Alex Heneveld commented on BROOKLYN-551:
[~drigodwin] debug exceptions aren't necessarily
a v2 API though.
Best.
On Mon, 6 Nov 2017 at 15:17 Alex Heneveld <
alex.henev...@cloudsoftcorp.com
wrote:
Hi All-
Until recently our REST API returned full records in most cases,
including often lots of empty lists and maps and sometimes nulls --
such
as `constraints: []` on all config key
Hi All-
Until recently our REST API returned full records in most cases,
including often lots of empty lists and maps and sometimes nulls -- such
as `constraints: []` on all config keys.
The widespread preference in REST / JSON community seems to be to omit
these unless there is a very
t it's a correct
one :-)
On 1 November 2017 at 12:26, Alex Heneveld <alex.henev...@cloudsoftcorp.com>
wrote:
I think it's wrong to split user guide and other parts of the web site.
I don't see a good reason for it apart from us liking more bifurcations
along technology lines (and these a
he best technology for each.
RE PRs ... splitting the site / docs makes the most sense as we deal with
making prs across Brooklyn's numerous repositories
Mark
On 27 October 2017 at 09:01, Alex Heneveld <alex.heneveld@cloudsoftcorp.
com>
wrote:
Sorry - I really don't like website being hid
s but easy to fix, whereas
the alternative means that it Brooklyn **will be broken on
restart/rebind** which is a clear no-go from my point of view.
Best
On Fri, 27 Oct 2017 at 09:12 Alex Heneveld
<alex.henev...@cloudsoftcorp.com
<mailto:alex.henev...@cloudsoftcorp.com>> wrote:
alog add ...` then deprecation warnings will only be
> visible via the Brooklyn log (rather than being returned to the
user of
> `br` or via the REST api).
>
> But that's a separate topic!
>
> Aled
>
>
> On 26/10/2017 12:58, Alex Heneveld w
Sorry - I really don't like website being hidden on a branch.
Why?
* It's non-obvious and one more thing to remember (or forget, or explain)
* Primary reason for branching (in my view) is lifecycle, and here the
two have very similar versioning and release lifecycles: master for both
will be
Absolutely.
Question is whether we should deprecate or make it a breaking change.
Deprecating feels right, though I think it would mean we can't actually
remove until 2.0 ?
Best
Alex
On 26/10/2017 12:06, Aled Sage wrote:
Hi all,
I propose we make it mandatory to specify the bundle id
Hi All-
With the move towards bundles, people have been experimenting with
project structure, and there seem to be two schools:
(1) use maven, include a `pom.xml` in root, and put the `catalog.bom`
and blueprints into either `src/main/resources/` or a custom resources
directory eg
it for debug purpose, I would move it to the `test` folder rather
than deprecating it.
Best.
On Tue, 10 Oct 2017 at 12:24 Alex Heneveld <alex.henev...@cloudsoftcorp.com>
wrote:
+1 for removing classic mode in the dist and in the docs
NOT for removing the Main class itself however, I don't
+1 for removing classic mode in the dist and in the docs
NOT for removing the Main class itself however, I don't think -- this is
my standard way to run Brooklyn from the IDE and I don't have a karaf
replacement that supports debug mode in the same way, and also note most
of our unit tests
Thomas-
Had a deeper look -- gitbook has moved things forward a lot. Sounds like
it will let us throw away a lot of our home-grown docs-building and
toc-building code and have good search. Look forward to seeing how it
shapes up with styling and guide-v-website integration.
Best
Alex
On
+1
good point Thomas, if someone wants to reset they should point at a new
persistence location,
because other persisted state will go haywire otherwise.
adding might be useful on upgrades but that's a separate topic and am
thinking that should be
done via the default catalog.bom (have been
[
https://issues.apache.org/jira/browse/BROOKLYN-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176335#comment-16176335
]
Alex Heneveld commented on BROOKLYN-539:
Correct, there is no need to persist types that come
te:
1) like the `/catalog` name and agree with Aled about its power to
communicate the idea
2 & 3) run `/v1` and `/v2` in parallel, with the latter being
experimental
and iterative until a 1.0 release
4) no preference
Robert
On 20 September 2017 at 15:45, Alex Heneveld <
alex.henev...@clouds
Good catches Thomas -- suggest we cancel and do a new RC.
The build-from-source problem I suspect is simply down to network setup
/ firewall on your box. But it would be good to force use of localhost
for those tests or mark them integration so that it doesn't bite others
or ideally be
uick launch" list and would get rid of the
> "template" versus "application" versus "entity" distinction in the REST api
> (anywhere you can use an entity, you can use an app; anywhere you need an
> app then a non-app entity will be auto-wrapped in a ba
th the CLI
but if anyone would like that speak up. I have updated UI to _show_ the
containing bundle ([2], also needs review!).
Best
Alex
[1] https://github.com/apache/brooklyn-server/pull/810
[2] https://github.com/apache/brooklyn-ui/pull/48
On 07/09/2017 14:58, Alex Heneveld w
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
org.apache.brooklyn.entity.stock.BasicApplication
id: myAppCampPlanId
```
Deploy this app:
```
services:
- type: app-with-camp-plan-id
```
The resulting app instance will have config `camp.plan.id` with value
`myAppCampPlanId`.
On 27/07/2017 00:40, Alex Heneveld wrote:
The core `id` i
future.
> I'd favour deferring that until there is a need to support it (e.g. we
> could add it at the same time as adding support for a pluggable id
> generator, if we ever do that).
>
> Aled
>
>
>
> On 26/07/2017 15:42, Alex Heneveld wrote:
>
>> 2 feels compelling
t;>>
>> It
>>
>>> would
>>> need to work long term, not just cached for a short time, and it would
>>>
>> need
>>
>>> to work
>>> across e.g. HA failover, so it wouldn't be just a matter of caching it on
>>
Aled-
Should this be applicable to all POST/DELETE calls? Imagine an
`X-caller-request-uid` and a filter which caches them server side for a
short period of time, blocking duplicates.
Solves an overlapping set of problems. Your way deals with a
"deploy-if-not-present" much later in time.
--A
[
https://issues.apache.org/jira/browse/BROOKLYN-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld resolved BROOKLYN-343.
Resolution: Fixed
Assignee: Alex Heneveld
Fix Version/s: 0.12.0
Fixed
the cluster.first.entity sensor of a DynamicCluster.
I've uploaded my code to https://github.com/rdowner/brooklyn-consul - can
you spot anything odd there?
Thanks
Richard.
On 17 July 2017 at 10:58, Alex Heneveld <alex.henev...@cloudsoftcorp.com>
wrote:
Hi Richard-
What you're doing looks fine.
Hi Richard-
What you're doing looks fine. Maybe something is wrong with the
"consul.serverReference" value, or there is a bug around special
treatment of parameters. The blueprint below shows what I think you're
doing, several ways, and all work, both in bash and in the config view
(IE
good idea. however the application's ID is not meant to be
user-supplied. maybe this could be called `deploymentId` and set
(compare against) a config key called `deploymentId` ?
--a
On 07/07/2017 16:33, Duncan Grant wrote:
I'd like to propose adding an appId parameter to the deploy
Hi folks-
The versioning changes discussed are merged [1]. Bundles seem to be
working very well and with the OSGi mapping sorted out and OSGi coming
to the fore I've been working on changing BOM YAML upload to be
installed as a bundle. The idea here is that if a user uploads a
catalog
- is it part of this plan to move bundle storage into the persistence
location so that HA Brooklyn nodes can find all bundles?
- if a catalog.bom (symbolic name xyz) includes brooklyn.libraries and
specifies a remote URL (which gets downloaded), what happens if we
delete
the bundle xyz -
-rc3-20170619`)?
Would we let users use (non bi-di mappable) 1.0-SNAPSHOT without any
warnings or deprecation?
Aled
On 22/06/2017 10:28, Svetoslav Neykov wrote:
Makes sense.
On 22.06.2017 г., at 12:27, Alex Heneveld
<alex.henev...@cloudsoftcorp.com> wrote:
inline
On 22/06/2017 10
safely be
ignored.)
--a
Svet.
On 20.06.2017 г., at 14:23, Alex Heneveld <alex.henev...@cloudsoftcorp.com>
wrote:
I've drafted the documentation for how this could be explained to users. This
may be easier to grok than the email:
https://github.com/apache/brooklyn-docs/pull/198
oklyn definitions must be contained in OSGI
bundles,
even if we will wrap them for you. This seems to impose an additional
requirement
on blueprint authors (learn OSGI) that we don't really want to impose?
As an aside, I'm assuming that your proposal would rely on Brooklyn moving
exclusively to the Karaf
1 - 100 of 227 matches
Mail list logo
