The ability to switch between json and yaml (so we only use the
json-isomorphic subset) is nice for working with models eg is js in the
browser, and feels less intimidating to new people. I'd like anywhere we
use !! to be optional. (if it were a more widely used part of yaml I might
think different
in JSON support to
convert objects in memory to markup, without needing to pull in any
external libraries.
Svet.
On 29.07.2016 г., at 9:54, Alex Heneveld <
alex.henev...@cloudsoftcorp.com> wrote:
The ability to switch between json and yaml (so we only use the
json-isomorphic subset) is nic
You could add an isSet enricher then wait on it. I prefer customisation in
enrichers rather than extending the dsl.
What is the use case? Everywhere I've seen whenReady is the most natural.
Best
Alex
On 5 Aug 2016 17:07, "Aled Sage" wrote:
> Hi all,
>
> Motivated by Andrew's recent PR [1] and
ld fix it in a backwards compatible way:
* introduce "attributeWhenTruthy", alias to "attributeWhenReady"
* introduce "attributeWhenPresent" with a notNull && notEmpty check
* deprecate "attributeWhenReady"
Svet.
On 7.08.2016 г., at 15:03, Alex He
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
th
vice (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,
i lean towards this:
brooklyn-client/
cli/
**/*.go
java/
src/main/java/**/*.java
or
brooklyn-client/
cli/
**/*.go
bindings/
java/
src/main/java/**/*.java
but I could live with this:
br
ent` to `brooklyn-client-cli` could be
distracting.
Andrea
On 9 September 2016 at 11:54, Alex Heneveld
wrote:
i lean towards this:
brooklyn-client/
cli/
**/*.go
java/
src/main/java/**/*.java
or
brooklyn-client/
cli/
**/*.go
I think what you really want is to define a preInstall step which does
the following:
- run the bash and output the key
- publish a sensor from the output of the bash
(Instead of the polling sensor.)
I'm working on something which should let you do that nicely.
Another thing which you
Grrr... This is one of the most irritating things about FreeMarker.
It's described here:
http://freemarker.org/docs/ref_builtins_number.html#ref_builtin_c
Probably `?c` should be a default in our case, but there doesn't seem to
be a possibility for that. We could set a specific locale in
I had the same thought. It didn't. :(
--A
On 28/09/2016 16:40, Svetoslav Neykov wrote:
Locale.ROOT might work - worth a try.
Svet.
On 28.09.2016 г., at 18:30, Alex Heneveld
wrote:
Grrr... This is one of the most irritating things about FreeMarker. It's
described h
Hi devs,
I've been spiking a new approach to our YAML modelling for java objects.
The root problem I want to solve is to that it's tedious, inconsistent,
and poorly documented how YAML should map on to the Java items. Every
new place we want to do this we use ad hoc code. This is an obstacle
Hi Graham-
There might be some mismatches if you're using the Apache Brooklyn
dist. To keep the classpaths separate (as A4C uses Spring) what we've
been doing is building and running brooklyn-tosca as OSGi that gets
installed in to Brooklyn running as OSGi (from
/brooklyn-dist/karaf/apache
There have been a lot of improvements to jclouds since their 1.9.2
release. Unless there are big issues with using 2.0.0 that would get my
vote.
Best
Alex
On 16/11/2016 07:26, Andrea Turli wrote:
+1
Svet,
FYI I'm working on #409 and #415 now that jclouds 2.0 is official released.
Andre
s an
older version of swift that is not compatible with this, so I believe
does not work with openstack-swift [1]. Upgrading to 2.0.0 would
therefore break SoftLayer's object store as a persistence endpoint.
Aled
[1] https://issues.apache.org/jira/browse/BROOKLYN-359
On 16/11/2016 15
ounds risky.
let's bump to jclouds 2 early in the 0.11.0-snapshot cycle and try to
release it once it's been more tested, as aled says.
--a
On 16/11/2016 09:50, Alex Heneveld wrote:
i find swift too slow as a persistence endpoint in any case; it
doesn't seem to be designed
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...
Hi Aled -
There are a few more things that I think need to be considered here.
Also, combining your proposals.
Firstly -- throughout Brooklyn we use the long-name syntax as an
internal / formal name of a key to prevent ambiguity, and a short "flag
name" to make it easy for a user to write.
t-form;
is it for multiple sensible names; is it for supporting camel-case
versus dot or underscore forms; etc).
Unfortunately our aliases are massively over used in Brooklyn (in my
opinion), in an ad hoc manner. Most (if not all) should be deprecated.
Aled
On 22/11/2016 22:31, Alex Henevel
What about a more modest proposal allowing `[#]` in DSL, to take the #th
item in any list or set?
So you could say `entity("cluster").children()[0]` or
`entity("cluster").attributeWhenReady("members")[0]` to get a member.
(Continuing: it depends on semantics of `members` whether it guarantees a
This litter is irritating. On the other hand we don't want application
stops to wait an arbitrarily long time for sec groups to become deletable.
I'd love to switch to a model where location instances become entities.
Security groups could also become part of that, and managed explicitly in
the r
the CLI has felt a little bit slow at times. i had chalked it up to bad
networking and it hasn't been a big issue. but if there are some easy
optimisations which would noticeable improve user experience -- which
andrea's timing data makes me think might be possible -- that would be nice!
--a
O
Hi All-
I'm with Svet: as much as we might like to deprecate things, I think we
mustn't without a clear path that allows users to move away from anything
we've deprecated.
In the case of blueprint *authors* (who might have used @SetFromFlag) we
need to consider blueprint *consumers* who may be u
Hi Sam,
How does this relate to the strategy suggested in the Networking Proposal
[1] ?
TL;DR I agree with the intention but think some tweaks to the mechanism
would make for even better clarify and consistency going forwarD
The proposal [1] suggests several things. One is a format for network
> - expose a way of indicating that public or private addresses should be
> preferred and default it to private, per the portion of the proposal I
> mentioned.
> - choose a reachable endpoint for management
> - set `host.address` and `host.name` on an entity to this endpoint
> (removing
Agree this is not a blocker. GETs work fine so people can see the API docs
and interact with most. In fact I think this regression is tiny: the
swagger page didn't support setting content-type and that's needed for most
of the POSTs, so they wouldn't work even with the CSRF token.
Best
Alex
O
Hi Brooklyners-
In the code we currently have two routes for users to install new
blueprints:
(1) upload a catalog YAML file to /v1/catalog
(2) install a bundle with catalog.bom in the root
The feature (2) is disabled by default, but I'd like to move towards
enabling it. This will make it easi
Hi Devs,
-0 ? -1 ?
The "bin" build when run locally on a fresh system (no brooklyn.properties)
requires that a username/password is supplied. It doesn't do any
authentication of the local credentials but gives a 401 if not supplied.
Specifically:
$ curl -v http://localhost:8081/ 2>&1 | grep "<
now whether we can just get some code
> from
> >>> git history and plug it in or things have changed considerably,
> assuming
> >>> JAAS under the hood.
> >>>
> >>> Svet.
> >>>
> >>> [1] https://github.com/apac
svet, all,
lots of good points.
the idea of "lifecycle phases" in our software process entities has
grown to be something of a monster, in my opinion. they started as a
small set of conventions but they've grown to the point where it's the
primary hook for yaml and people are wanting "pre.p
cks, but still need
>> visibility into the executing blocks.
>>
>> PS - as a near-term option if needed we could extend SoftwareProcess
>>> LATCH to do something special if the config/sensor it is given is a
>>> "Semaphore" type
>>>
>> What
Svet-
On 11/01/2017 15:55, Svetoslav Neykov wrote:
PS - as a near-term option if needed we could extend SoftwareProcess LATCH to do
something special if the config/sensor it is given is a "Semaphore" type
What do you think the behaviour should be here - releasing the semaphore after
the corr
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
report on how that does.
---
I'm also interested in whether two runs of all.sh will give identical
git sha1 commit ids for each new repo.
Assuming it does, that is a great way to prove the providence of the
new repos if we are every legally asked in the future (i.e. it is
entirely determi
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 d
smooth from here ... famous last words.
Please let me know how they work for you -- or if you object to a Saturday
migration for any reason!
Best
Alex
On 28 January 2016 at 12:23, Alex Heneveld
wrote:
>
> Thanks Aled.
>
> > branches="0.4.0 0.5.0 0.6.0 0.7.0-incubating 0.8.0
January 2016 at 18:17, Alex Heneveld
wrote:
> I've fixed the problems Aled observed with the `all.sh` script and the
> problem with previous branches.
>
> I've also added PR's which:
> * set up submodules: https://github.com/ahgittin/brooklyn/pull/5
> * a
tainers-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
hub's "hub" tool -- early stages but promising.)
Best
Alex
On 28/01/2016 22:12, Richard Downer wrote:
+1. In about a week I'll be drafting the last of our three initial
monthly reports to the board; I'd love to say that we have shed our
"incubating" repository
[2] https://github.com/apache/brooklyn
On 31/01/2016 12:37, Alex Heneveld wrote:
Hi All-
Thanks for the feedback. I have everything set to push to the new
repos; but we are blocked on an access issue to the new git repos
(permissions). You can see the latest in the "ahgittin" repo
esome! - quick question, I was checking but I can’t remember if you sent
instructions for bringing pull requests from incubator over to the new repos,
did you?
Geoff
Gnu PGP key - http://is.gd/uI
On 1 Feb 2016, at 20:12, Alex Heneveld wrote:
All-
I'm delighted
Gnu PGP key - http://is.gd/uI
On 1 Feb 2016, at 21:54, Alex Heneveld wrote:
Geoff,
I did. Bringing pull requests across (without history I'm afraid) is described
at the bottom here:
https://github.com/apache/brooklyn-docs/blob/master/guide/dev/code/submodules.m
Hi All-
So far so good with the new repos...
We now need to get Jenkins set up. There are a couple options now, due
to the submodules, especially when it comes to pull requests.
We could keep the same pattern as we currently have -- 1 below --
although I'm not sure whether multi-project / s
s such
as module support which fits in our use case.
IMHO, we should take the second option. It will require some extra
manual work, but at the end it will look more accurate and descriptive.
Regards,
Yavor
On 02/02/2016 11:00 AM, Alex Heneveld wrote:
Hi All-
So far so good with the new rep
+1 binding
Alex
On 18/02/2016 18:14, Svetoslav Neykov wrote:
+1 binding
Svet.
On 18.02.2016 г., at 18:09, Duncan Johnston Watt
wrote:
+1
Duncan Johnston-Watt
CEO | Cloudsoft Corporation
Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.c
I've had a look at many of these.
Possibly now fixed:
> AssemblyTest.checkBrooklynCoreFeature (
https://issues.apache.org/jira/browse/BROOKLYN-216)
have added an @Filter longer timeout, may fix it, we'll see
> ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp (
https://issues.apache.org
g/jira/browse/BROOKLYN-206)
> CassandraDatacenterTest.testPopulatesInitialSeeds (
https://issues.apache.org/jira/browse/BROOKLYN-205)
these look like the same problem. added comments on the first. i think
we'll need debug logs if this occurs again (i can't see what's going on!)
END
On 24 February
> This is to announce that the Brooklyn Client Command Line Interface
tool has been
> added to the Apache Brooklyn "brooklyn-client" repository [1].
This is excellent! Great work Robert, Geoff, and David.
I've already switched to using the CLI for many things, from deploying
to looking up d
Thomas is nearly done with a fantastic wizard to define locations, and
there are several PR's to be merged after that is in, and then I think
let's do a release!
--A
On 18/03/2016 09:37, Geoff Macartney wrote:
+1
Gnu PGP key - http://is.gd/uI
On 15 Mar 2016, a
+1 this plan sounds excellent Svet.
I think the focus on catalog.bom files will make it a lot easier to
package and share blueprints -- whether as bundles, zips, plain text
files, or a git url. I really like that we can use the power of OSGi
for isolation and dependency resolution but this i
John
Good write up. This needs to be in brooklyn-docs!
Best
Alex
On 25 Mar 2016 21:08, "John McCabe" wrote:
> Hi David,
> I've been using freemarker templates for this, and it works quite well, for
> example:
>
> brooklyn.config:
> templates.install:
> "https://some.ser
Richard/All-
Is the Easter bunny bringing us a release?
The SoftLayer same-vlan PR is now in. I think that was the last one.
There are a lot of OSGi PR's but I think it would be best to merge these
post-090. Does anyone object to branching an 09x from which we can do a
release and bumping
and you can try them
out!
I'll then kick off a release, probably tomorrow.
Richard.
On 28 March 2016 at 16:08, Alex Heneveld
wrote:
Richard/All-
Is the Easter bunny bringing us a release?
The SoftLayer same-vlan PR is now in. I think that was the last one.
There are a lot of OSGi PR&#x
Branch 0.9.0 is created, with master now bumped to 0.10.0-SNAPSHOT.
Richard, your instructions were great!
I will look at merging the OSGi work into master.
Best
Alex
On 29/03/2016 13:20, Alex Heneveld wrote:
Richard-
Nice. Will hang fire on that.
--A
On 29/03/2016 10:50, Richard
Hi Richard
This has now been resolved:
https://github.com/apache/brooklyn-server/pull/96
I've backported it -- and the improvement in #97 as suggested by
@aledsage -- to the 0.9.0 branch.
Fancy another RC?!
Best
Alex
On 01/04/2016 15:26, Richard Downer wrote:
The vote for rc1 is can
Yes. Good spot. Merged and backported.
--A
On 01/04/2016 15:31, Richard Downer wrote:
Aled also recommended
https://github.com/apache/brooklyn-library/pull/29 to be merged too.
WDYT?
Richard.
On 1 April 2016 at 15:29, Alex Heneveld wrote:
Hi Richard
This has now been resolved
Thanks. Great job.
--A
On 05/05/2016 11:52, Richard Downer wrote:
All,
Below is a draft for our next board report, which needs to be submitted by
Wednesday 11th May. If you have any comments please let me know; otherwise
I'll go for passive consensus.
---
## Description:
- Apache Brookl
Mike, All-
Rather than move the YAML into Java how about working towards being able
to import YAML fragments?
In the simplest case this could be something like
brooklyn.enrichers:
- $brooklyn:import(cluster-list-member-addresses-enrichers.yaml)
- ... # another enricher
Where you
#53 can be skipped i think --- remaining list:
#52 [bostko]
#54 [tbouron]
#55 [tbouron]
#56 [neykov]
--a
On 13/05/2016 12:07, Svetoslav Neykov wrote:
Same for #56 [neykov]
Svet.
On 13.05.2016 г., at 14:06, Svetoslav Neykov
wrote:
#44 [neykov]
#49 [neykov]
Both apply to master only.
sorry, remaining ones should be:
#52 [bostko]
#54 [tbouron]
#55 [tbouron]
On 13 May 2016 at 13:17, Alex Heneveld
wrote:
>
> #53 can be skipped i think --- remaining list:
>
> #52 [bostko]
> #54 [tbouron]
> #55 [tbouron]
> #56 [neykov]
>
> --a
>
>
>
>
ot sure, do the test entities have been introduced in 0.9.0?
On Fri, 13 May 2016, 12:17 Alex Heneveld,
wrote:
sorry, remaining ones should be:
#52 [bostko]
#54 [tbouron]
#55 [tbouron]
On 13 May 2016 at 13:17, Alex Heneveld
wrote:
#53 can be skipped i think --- remaining list:
#52 [bostk
two difficulties i see:
1) how do i clear inherited map values on a MERGEd config?
2) how do we specify that "templateOptions" in a
"provisioningProperties" is to be merged?
(followed by conclusion -- outlining an alternative but overall unsure)
*1) how do i clear inherited map values on a
unfamiliar with the underlying implementation) would expect. Until one
explains about how this maps to the jclouds TemplateOptions class, there
is little logic for what is a top-level key-value and what goes inside
templateOptions. So I think a user would want them both merged.
Aled
O
Geoff-
> There are a handful of similar methods - pre/post install, pre/post
configure etc.
> In general I'd imagine you'd want to have the default behaviour be to
fail if any returned non-zero.
+1
Best
Alex
On 31 May 2016 at 06:19, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:
Hi All-
As more and more clouds offer private networking and multiple networks,
it's time for us to do more to support this in blueprints. Some of us
have collected some thoughts and put together a proposal, aimed mainly
at giving clarity and better control when multiple networks are present
+1
On 07/06/2016 11:37, Aled Sage wrote:
Hi all,
I suggest we rename the entity SimpleShellCommandTest [1] to
TestSshCommand. This would make it more consistent with the naming of
things like ShellFeed [2] and SshFeed [3]: "shell" means executing a
command on the local brooklyn server, where
I like this direction but I think we should stage as follows:
NOW - agree short-term preferred syntax for catalog items (but nothing
deprecated, not major change)
SOON - define new improved and more powerful syntax, similar to
preferred -- but allowing arbitrary types, interfaces, mixins
M
Plus we've redone the website and regularly run a link checker -- OP let us
know if you've any lingering reservations (apart from the clunky mailing
lists which I'm fond of -- kinda makes me wish we had a gopher site!)
On 27 January 2017 at 16:35, Andrea Turli (JIRA) wrote:
>
> [ https://is
Hi All-
In [1], @tbouron and I add an "includeBackground" query parameter to the
`/activities//children` endpoint. This is useful as you can see
which tasks were "submitted by" the given task, even if they aren't
explicit sub-tasks. Typically these are less interesting eg message
deliv
Svet-
Why not just encourage people to use "publicAddress" and/or make sure
the hostname is set sensibly ?
Feels like any heuristic we use (whether hostname, most public
locally-known IP or externally reported address) will be imperfect.
Local hostname feels like the best strategy which is
> makes it sound like we do
>
> I think resolving the hostname from other machines rearly works in
> practice. Only in Amazon? If it did work, then agree it's the best approach.
> That's the reason why I think we should use addresses only (maybe hostname
> just in Amazon)
An `EntityInitializer` for this purpose is a nice alternative pattern --
better than the child entity I suggested at #155 -- until we have sequence
effector YAML. Is there anything `$brooklyn:effector` gives us that an
initializer wouldn't do in a cleaner way?
Best
Alex
On 1 March 2017 at 11:54
Hi Mahammad,
Both Apache Brooklyn and jclouds follow the usual Java convention for
specifying proxy behaviour. See:
https://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html
Let us know how you get on. Note you'll need to proxy all TCP
connections, http(s) and for s
+1
Minor comments:
> 2. For a "MethodEffector", the effector invocation goes through
> `GroovyJavaMethods.invokeMethodOnMetaClass`. This calls into groovy
> code to find the method that matches the given arguments.
Reflections.findMethodMaybe and invokeMethodWithArgs might be drop-in
repl
e in there. If not present
are
they really needed?
* (G) Bundles installed via this mechanism are not persisted
currently &
(I) We persist the individual catalog items as YAML, so we end up
with
two
records
Suggest marking the catalog items coming from bundles as
non-persistable. Th
or an effector of your own entity? i.e. you
have
an effector on entity A that does some stuff when invoked, including
invoking an effector on entity B? (And maybe using the result when
calculating its own result instead of storing it in a sensor).
Is that something we'd want to support?Is
I think you can say
$brooklyn:entity(config("entity")).attributeWhenReady("sensor") - is that
good enough (and notify this in the docs)?
On 16 Mar 2017 15:03, "Aled Sage (JIRA)" wrote:
[ https://issues.apache.org/jira/browse/BROOKLYN-454?page=
com.atlassian.jira.plugin.system.issuetabpanel
I'm of the opinion that templates *shouldn't* access externals
directly. Templates should be tied to an entity and so only rely on the
config of that entity. You can then set a config key in YAML to have
the external value and use that from the templates.
In theory, this makes the blueprin
Hi All-
I've been working with a few others on how we can simplify the process
writing new versions of blueprints and applying them to existing
deployments.
* Imagine being able to do *cat blueprint.bom | * **br catalog add
--upgrade --restart* to have deployments pick up a new version of a
(Seems the mailing list has stripped my PDF. Attaching again in case
that works but you'll probably have to use the link.)
On 29/03/2017 14:44, Alex Heneveld wrote:
Hi All-
I've been working with a few others on how we can simplify the process
writing new versions of blue
Hi folks-
I've been hearing two categories of feedback from people who've spent
time on our website: "I don't get it" and "Sounds complicated".
I think the time is right for us to fix this. We can give a clear,
gentle experience, and we can tone down the academic ideas in favour of
real
17:08 Thomas Bouron
wrote:
Hi all.
Massive +1 Alex. I also think we can hugely improve the website from a
UI/UX perspective. Valentin also raises a good point about the SEO which is
far from being optimised.
I would happily help on that.
Best.
On Thu, 13 Apr 2017 at 15:32 Alex Hen
e true way" approach, i.e. always requiring the `symbolicName`
> > and
> > >> `version` when uploading ZIP/JAR (that includes Svet in his previous
> > >> email).
> > >>
> > >> One thing not explicitly settled is the format of bom for those
(https://asciinema.org/a/46498).
On Tue, 18 Apr 2017 at 08:21 Thomas Bouron <
thomas.bou...@cloudsoftcorp.com>
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
+1 to copyResources being protected not private
+1 to adding `templates.customize` and `files.customize` a la
`{templates,files}.runtime` (but before `customize.command`)
Graham if you're able to do either or both in a PR I'll see it's added
as quickly as possible. If not we'll pick this u
Hi Mark-
I'd like to keep backwards compatibility. We don't know where this
might be used.
Also the catalog item ID isn't sufficient I don't think. Returning just
the catalog item ID means you lose any custom configuration on the
location in the blueprint (ie on top of the catalog item ID)
It has to be a judgment call. I tend to agree this is a blocker.
Best
Alex
On 27 Apr 2017 15:14, "Geoff Macartney"
wrote:
> What are our guidelines on what constitutes a release blocker, or, if we
> don't have any specific guidelines other than gut feeling, should we create
> some?
>
> My own s
Hi Brooklyners-
As many of you know, my YOML PR #363 [1] has been open for a while. This
sets up a foundation for giving better documentation and feedback and
hugely simplifying how we do our parsing. However it's a very big PR.
I'm eager to have people spend some time using it and ideally
ed
On 02/05/2017 15:50, Duncan Johnston Watt wrote:
Hi Alex
This is probably covered already but I guess there needs to be an impact
assessment (by submitter?) before something is waved through by default.
Best
Duncan
On 2 May 2017 at 06:52, Alex Heneveld
wrote:
Hi Brooklyners-
The "customize-files" feature falls into the "but this one would be
useful" category --
https://github.com/apache/brooklyn-server/pull/662
To me the interest from Graham Ashby is a good justification though
still contentious :). I respect the Release Manager's call.
Best
Alex
On 03/
+1 (binding)
Thanks all for taking this seriously. Just to recap (and apologies for
doing this in a VOTE thread but I'll keep it brief) my aim is to
increase the priority with which we review things, not to downplay the
importance of reviews, though where something has to give I'd rather it
Hi Ivana-
You're correct. Could you insert the words "at least" into the sensor
description [1] ?
Best
Alex
[1]
https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/org/apache/brooklyn/entity/group/DynamicCluster.java#L201
On 09/05/2017 10:03, Ivana Yovcheva wrote:
Definitely!
On 10/05/2017 14:30, Aled Sage wrote:
Hi all,
I suggest we delete the java/groovy examples in
brooklyn-library/examples [1] (but not "webapps" in that dir, which is
used to build WAR files used in demos apps).
These do not follow the new (*) recommended way of writing blueprint
Hi All-
TL;DR - I am proposing that we encourage versions in Brooklyn of the
form "1.1.0" or "1.2-qualifier" such as "1.2-SNAPSHOT", silently mapping
when needed to OSGi as "1.1.0" or "1.2.0.qualifier" / "1.2.0.SNAPSHOT"
Further to my last mail -- we have a bit of discord between various
v
Hi All-
With bundles now being neatly supported for add and remove, I think it
makes sense to use make the "bundle" a first-class concept in managing a
brooklyn catalog (type registry).
The basic idea is that users will work with ZIPs (or directories if
using the br CLI), where a "catalog.b
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/files#diff-21dacc664dfe4d0a156d65d768a0f0e2R28
Best
Alex
On 19/06/2017 17:39, Alex Heneveld wrote:
Hi All-
TL;DR -
top-level in catalog.bom. That makes the dependency tree simpler (it's
just among bundles, delegated to OSGi), and I'm pretty sure there's no
use case for the complexity.
Best
Alex
On 20/06/2017 11:17, Richard Downer wrote:
Alex,
On 19 June 2017 at 17:39, Alex Heneveld
wrot
7;m less
sure we
want to advertise that all Brooklyn 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 prop
which can safely be
ignored.)
--a
Svet.
On 20.06.2017 г., at 14:23, Alex Heneveld
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
n the docs link
include `1.10-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
wrote:
inline
On 22/06/2017 10:10, S
1 - 100 of 284 matches
Mail list logo
