s://twitter.com/duncanjw>
> > > Mob: +44 777 190 2653 <07771%20902653> <+44%207771%20902653>
> <+44%207771%20902653>
> > > LinkedIn: https://linkedin.com/in/duncanjohnstonwatt
> > >
> > >
> >
> >
> > --
> > Duncan Johnston-Watt
> > CEO, Blockchain Technology Partners <http://blockchaintp.com/>
> >
> > Twitter: @duncanjw <https://twitter.com/duncanjw>
> > Mob: +44 777 190 2653 <07771%20902653> <+44%207771%20902653>
> <+44%207771%20902653>
> > LinkedIn: https://linkedin.com/in/duncanjohnstonwatt
> >
>
--
Andrew Kennedy ; Hyperledger Sawtooth / Apache Brooklyn ; @grkvlt ;
Cloudsoft Corporation Limited
Please vote to approve this contribution.
>
> This is a lazy consensus majority vote, open for at least 72 hours.
>
> Thanks
> Richard Downer
> PMC Chair, Apache Brooklyn
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
+1 Binding
This is a really useful addition to Brooklyn. It will allow users to target
what are now the de facto standards for microservices and cloud native
applications.
Andrew.
On Wed, 31 May 2017 at 11:56 Andrew Kennedy <
andrew.kenn...@cloudsoftcorp.com> wrote:
> All,
&g
: No opinion
[ ] -1 : Reject contribution because...
The vote is open for 72 hours and will close at 11h00 UTC/12h00 BST on
Saturday 03 June 2017 and the results will be announced on this list.
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
art...@cloudsoftcorp.com> wrote:
> Thanks for the reminder Andrew, that is a good point. I wonder if things
> would work any better with XStream 1.4.10 (the latest)?
>
> On Fri, 26 May 2017 at 16:20 Andrew Kennedy <
> andrew.kenn...@cloudsoftcorp.com> wrote:
>
> > I belie
> https://lists.apache.org/thread.html/1f7068d90480bfd20795d35e733033a150bd4cf1c4d8ff65d269@%3Cdev.brooklyn.apache.org%3E
> [2] https://github.com/apache/brooklyn-server/pull/684
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
ences have been updated in [1].
>
> Richard is the next step a vote by the community to see if this is actually
> wanted within brooklyn?
>
> Cheers
> Mark
>
> [1] https://github.com/cloudsoft/brooklyn-container-service/
>
> On 20 May 2017 at 18:35, Andrew Kenne
- I am both, so the process can be summarised as "I will take
> care
> > of it" :-)
> >
> > We and Cloudsoft have done this twice before (once for the Brooklyn CLI,
> > and once for the CAMP Server), so I don't expect any problems. Cloudsoft
> > will need to complete a legal Software Grant Agreement, so I'll need
> > assistance from Cloudsoft management, but it shouldn't be too onerous.
> >
> > Richard.
> >
> > [1]https://incubator.apache.org/ip-clearance/ip-clearance-template.html
> >
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
/location/localhost/LocalhostMachineProvisioningLocation.java
Hopefully this will give you some ideas.
Andrew.
On Fri, 19 May 2017 at 15:17 Andrew Kennedy <
andrew.kenn...@cloudsoftcorp.com> wrote:
> Hi Graham.
>
> You could certainly create a BYON location that referenced the ins
gt; > imageId: Lobby/e3b40a4f-4e82-41b3-857c-68799c4a9009
> > hardwareId: Lobby/m1.small
> > keyPair: openstack-gsa-gen
> > keyPairName: openstack-gsa-gen
> > loginUser: cloudusr
> > loginUser.privateKeyFile: /home/cloudusr/.ssh/openstack-gsa-gen.pem
> >
> > jclouds.openstack-nova.cacert: /opt/brooklyn/ca-1/hdc.pem
> > jclouds.openstack-nova.openIptables: true
> > jclouds.openstack-nova.selinux.disabled: true
> > jclouds.openstack-nova.auto-create-floating-ips: true
> > jclouds.openstack-nova.auto-generate-keypairs: false
> >
> >
>
>
>
>
> --
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
l need
> > > assistance from Cloudsoft management, but it shouldn't be too onerous.
> > >
> > > Richard.
> > >
> > > [1]
> https://incubator.apache.org/ip-clearance/ip-clearance-template.html
> > >
> >
>
>
>
> --
>
> Duncan Johnston-Watt
>
> Founder & Chief Executive Officer
>
> Phone: +44 777 190 2653 <07771%20902653> | Skype: duncan_johnstonwatt
>
> Twitter: @duncanjw <https://twitter.com/duncanjw> | LinkedIn:
> https://linkedin.com/in/duncanjohnstonwatt
>
> [image: Cloudsoft Logo.jpg] <https://cloudsoft.io/>
>
> Stay up to date with everything Cloudsoft:
>
> [image: Twitter_Logo_White_On_Blue.png] <https://twitter.com/cloudsoft>
> [image:
> YouTube-social-icon_red_48px.png]
> <https://www.youtube.com/channel/UCpbLhvXrYWz8B_osUX6rn0Q>
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
roposing the correct name.
>>
>> This could be achieved by providing "close names". If the name
>> matches another config key, then that would be used. Otherwise, if
>> the name matches a "close name" of a config key, then it would show
>> the validation warning. Note that it is a warning rather than an
>> error because of the rules for config inheritance: it could be that
>> the config key will be inherited by children that will understand the
>> given name.
>>
>> We could have a "strict" mode that treated such warnings as errors
>> (sounds like a topic for a different email thread!).
>>
>> We could do some similar automatic checks for close matches, e.g. to
>> warn if "installCommand" is used instead of "install.command".
>>
>> To me, it feels like "hints" is stage two - i.e. lower priority than
>> agreeing each config key should have a single definitive name, and
>> deprecating the other names.
>>
>>
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
er ways,
> >>> without knowing their ids (particularly when those entities are nested
> >>> inside a blueprint that someone else wrote).
> >>>
> >>> For example, we could retrieve the main.uri of the first and second
> >>> members of a c
[
https://issues.apache.org/jira/browse/BROOKLYN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510072#comment-15510072
]
Andrew Kennedy commented on BROOKLYN-349:
-
See https://github.com/apache/brooklyn-server/pull
-child) hierarchy.
All tests are passing with this change, so I think it is safe to merge, but
would like to know if anyone thinks it will break their blueprints before I
do so.
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
quot;true"), 10m)
> >>
> >> I think I'm ok with leaving the default as groovy-truth semantics, as
> long
> >> as we make the documentation clearer for that.
> >>
> >> However, this proposal might well be hard to implement. It would likely
> >> require significant change to how we parse the $brooklyn expressions
> (if my
> >> recollection of this code is correct).
> >>
> >> _*Proposal: option 2*_
> >>
> >> An alternative suggested by Svet in a comment on [1]:
> >>
> >> Should we fix attributeWhenReady instead? It's confusing to have it
> >> wait indefinitely on false.
> >> Having another attribute, very similar to attributeWhenReady
> >> complicates things even further.
> >>
> >> Suggest renaming attributeWhenRedy to attributeWhenTruth and
> >> changing attributeWhenReady to wait on notNull && notEmpty.
> >>
> >> That sounds like a good idea - it feels much more explicit, and is very
> >> simple to implement.
> >>
> >> However, it would break backwards compatibility (e.g. for those using
> >> `attributeWhenReady("service.isUp")`.
> >>
> >> If we think the semantics are wrong, then we should definitely change it
> >> while we're still on version 0.x rather than ignoring it.
> >>
> >> Aled
> >>
> >> [1] https://github.com/apache/brooklyn-server/pull/282
> >> [2] https://github.com/apache/brooklyn-server/blob/rel/apache-
> >> brooklyn-0.9.0/core/src/main/java/org/apache/brooklyn/core/
> >> sensor/DependentConfiguration.java#L669
> >>
> >>
>
> --
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
gt; [4] https://gist.github.com/tbouron/67527796726e10689d8d3c34784cd7ec
>
> --
>
> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> http://www.cloudsoftcorp.com/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
this is the best way, as it does fill up the UI with
more parameters, but at least they are all visible and in a sensible order.
Perhaps we could add some further properties to SpecParameter that can be
used as display hints?
Andrew.
On Tue, 26 Jul 2016 at 20:42 Andrew Kennedy <
andrew.k
feedback and ideas for further changes and improvements that can be
implemented in a future PR. If nobody objects, i would like to merge this
in a few days?
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
:41 Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:
> I think that looks like a good approach, +1 from me.
>
> Will have a think at the feed stop problem.
>
> Cheers
> Geoff
>
>
>
> Gnu PGP key - http://is.gd/TTTTuI
>
>
uite small.
The PR containing the change is here:
- https://github.com/apache/brooklyn-server/pull/204
I'd appreciate any comments on whether this is a useful change, as well as
a review of the pull request...
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
n:
> >>
> >> - type: org.apache.brooklyn.entity.basic.VanillaSoftwareProcess
> >>brooklyn.initializers:
> >>- type: org.apache.brooklyn.initializer.stock.PackageInstaller
> >> packages:
> >> yum: curl
> >>
he best way to approach this is still needed.
I am very interested to know what people think about this proposal, and which
parts should be worked on further.
_Andrew Kennedy; <mailto:and...@cloudsoft.io>; 30 May 2016_
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
ossible. Instead the
> >>>> sub-type needs to use pre.install.command and/or
> >>>> post.install.command. But that leads to the same problem if a
> >>>> super-type also has a value defined for that key.
> >>>>
> >>>> Svet suggested we could perhaps introduce something like
> >>>> $brooklyn:super().
> >>>>
> >>>> Unless we can generalise that approach to also solve the merging of
> >>>> `shell.env` etc, then I suggest we defer the `install.command`
> >>>> use-case. That can be proposed and discussed in a different thread.
> >>>>
> >>>> However, if we can solve these problems with clever explicit use of
> >>>> $brooklyn:super(), then that could provide an elegant solution to
> >>>> all of these problems!
> >>>>
> >>>>
> >>>> _*Inheritance from parent entities*_
> >>>>
> >>>> Things are made yet more complicated by the fact we inherit config
> >>>> from parent entities, in the entity hierarchy.
> >>>>
> >>>> We propose that this behaviour is also configurable for the config
> >>>> key, but that the defaults stay as they are. The existing logic is
> >>>> applied to find the config value that applies to the given entity.
> >>>> That value is then merged with its super-type, as appropriate.
> >>>>
> >>>> For example, in the blueprint below... machine1 would get ENV1 and
> >>>> ENV2 (i.e. the ENV1 definition overrides the ENV_IN_APP
> >>>> definition). However, machine2 would get ENV1 and ENV_IN_APP (i.e.
> >>>> it inherits ENV_IN_APP from the parent, and this is meged with the
> >>>> super-type).
> >>>>
> >>>> services:
> >>>> - type: org.apache.brooklyn.entity.stock.BasicApplication
> >>>> brooklyn.config:
> >>>>shell.env:
> >>>> ENV_IN_APP: myEnvInApp
> >>>> brooklyn.children:
> >>>> - type: machine-with-env
> >>>>id: machine1
> >>>>brooklyn.config:
> >>>> shell.env:
> >>>>ENV2: myEnv2
> >>>> - type: machine-with-env
> >>>>id: machine2
> >>>>
> >>>> The reasoning behind this is to figure out the inheritance/override
> >>>> rules incrementally. We leave the parent-inheritance as-is, and
> >>>> just focus on the sub-typing inheritance.
> >>>>
> >>>> Note that there is already a ConfigInheritance defined on ConfigKey
> >>>> for controlling this kind of inheritance from the parent. The legal
> >>>> values for ConfigInheritance are currently just ALWAYS and NONE.
> >>>>
> >>>>
> >>>> _*IMPLEMENTATION*_
> >>>>
> >>>> Clearly we do not want to implement this piecemeal. We'll add a way
> >>>> to declare that a config key should be merged with that value from
> >>>> the super-type.
> >>>>
> >>>> We'll change the Java ConfigKey code to be:
> >>>>
> >>>> public interface ConfigKey {
> >>>> /**
> >>>> * @since 0.10.0
> >>>> */
> >>>> @Nullable ConfigInheritance getParentInheritance();
> >>>>
> >>>> /**
> >>>> * @since 0.10.0
> >>>> */
> >>>> @Nullable ConfigInheritance getTypeInheritance();
> >>>>
> >>>> /**
> >>>> * @deprecated since 0.10.0; instead use {@link
> >>>> #getParentInheritance()}
> >>>> */
> >>>> @Nullable ConfigInheritance getInheritance();
> >>>> }
> >>>>
> >>>> We'll add to ConfigInheritance support for MERGE. We'll change the
> >>>> name "ALWAYS" to OVERRIDE (deprecating the old value).
> >>>>
> >>>> We'll change EntityConfigMap.getConfig to handle this new merge
> >>>> behaviour. And same for locations, policies and enrichers.
> >>>>
> >>>> Aled
> >>>>
> >>>>
> >>
> >
> >
>
> --
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
t;
> # 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
tion can get
> > annoying.
> > > > >
> > > > > I've been hesitant about us going down the road of
> > > `brooklyn-commands.sh`
> > > > > for achieving portable blueprints. It feels like we are increasing
> > the
> > > > > overlap
ss, so further suggestions welcome...
Cheers,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
o apt-get install curl ; } || \
> { sudo yum update && sudo yum install curl ; } || \
> { echo WARNING: cannot install curl && exit 1 ; }
> ```
> I’m not entirely sure this feature fits well on the DSL.
>
> Alternatively, we could add a conf
t; >>
> >> I've created a 0.9.x branch (at version 0.9.1-SNAPSHOT) for fixes that
> >> we'd want in a 0.9.1 release. I don't think there is anything serious
> >> enough to warrant diong a 0.9.1 release quite yet though.
> >>
> >> Aled
> >>
> >>
>
> --
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
nch (for if we subsequently produce a 0.9.1).
>
> Aled
>
> [1] https://github.com/apache/brooklyn-server/pull/53
> [2] https://github.com/apache/brooklyn-server/pull/113
>
>
> On 12/04/2016 14:04, Andrew Kennedy wrote:
> > Oops.
> >
> > I was testing Clocker
st once they are available from the Apache mirrors.
>
> Richard.
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
.
On Sat, 2 Apr 2016 at 08:54 Richard Downer <rich...@apache.org> wrote:
> Hi Andrew,
>
> You're right - failure to follow my own instructions. I've now pushed the
> tags.
>
> Thanks
> Richard.
>
> On 2 April 2016 at 01:00, Andrew Kennedy
> <andrew.kenn...@clou
ich makes me think that it
should be merged into core Brooklyn?
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
ocation interface to make explicit
> > its responsibilities for register/unregister - this will give it an
> > opportunity to register the location so it can be used by other apps.
> >
> >
> > _*Longer term*_
> > Much longer term, we could have a new implementation of ServerPool
> > that deals better with the cleanup. For example, instead of returning
> > a direct reference to the machine, it could create a single Docker
> > container with sshd running, and return that. On release, it would
> > delete the docker container.
> >
> >
>
> --
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
s
> and our new distributable artifacts and I think I'm just about ready
> to push the "release candidate" button, if we think that the project
> is in a releasable state?
>
> Richard.
>
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
ng StackOverflow answer:
-
http://stackoverflow.com/questions/25277878/make-rpm-maven-plugin-work-on-mac-osmavericks
I couldn't see anything covering this on the list, but apologies if this is
already common knowledge ;)
Cheers,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
bility issues when running Brooklyn.
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
examples on
the Karaf site that I can just follow?
2. Where can I find more documentation on running Brooklyn inside Karaf? I
couldn't see anything in the brooklyn-server/karaf module that explained
things?
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
t; >
> > 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
ronments. There
could perhaps be a default blacklist of key name fragments that will be
used to filter the list, as well as a configurable list of exclusion
wildcards?
Do people think this would be a useful addition to Brooklyn? I have started
on an implementation, but would like some feedback before I move forward.
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
ronments. There
could perhaps be a default blacklist of key name fragments that will be
used to filter the list, as well as a configurable list of exclusion
wildcards?
Do people think this would be a useful addition to Brooklyn? I have started
on an implementation, but would like some feedback before I move forward.
Thanks,
Andrew.
--
Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
41 matches
Mail list logo
