+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 is transparent to a
user, ie they don't need to know anything about OSGi.
And with persistence and the ability to define locations in the UI, it's
nice that configuration (ie brooklyn.properties) becomes so much simpler.
--A
On 24/03/2016 09:48, Svetoslav Neykov wrote:
Hi all,
There's lots of effort going into Brooklyn to make it run in a Karaf container.
As part of the changes we need to figure out how to support the existing CLI
arguments and brooklyn.properties in the new environment.
Here's a suggestion of how this might look, open to discussion.
Command line arguments. Revise current set of command line arguments. Some of
them are no longer needed, others don’t make sense in a Karaf environment.
Define and support a subset of them. Arguments passed at the command line will
be added to the brooklyn configuration files, making the values permanent, even
for subsequent restarts. It ends up being just another means for editing the
configuration.
brooklyn.properties. Integrate with Karaf by:
* using OSGI configuration admin service to store Brooklyn properties;
* populating the service from brooklyn.properties as well as the usual .cfg
files;
Don't support properties which are now handled by different subsystems in Karaf.
* webconsole (jetty) can be fully configured in Karaf without Brooklyn
interfering.;
* authentication - Karaf already provides the means to configure
authentication providers (through JAAS) and configure them;
* defining locations - the preferred way of defining a location is through
the catalog, which can then be shared through HA. The only exception is for
persistence locations which need to be available before persistence is enabled
- for advanced cases allow the user to pass a catalog.bom with the
persistence location and reference it in the configuration.Potentially marking
the catalog item as NOT_PERSISTABLE to avoid handling duplicates. For example
by adding the following config to brooklyn.properties:
brooklyn.persistence.location.specs=catalog.bom
brooklyn.persistence.location.named_in_catalog=my_persistence_loc #from
catalog.bom above;
- UI to do the same. When no persistence location is defined prompt the
user create one (either webconsole or karaf mechanism to add one)
With the above brooklyn.properties will tend to be minimalistic (or not needed
at all). Could consider splitting it additionally, for example options which
can be included in the HA persistence and thus shared, and local properties.
Here’s a document which tracks existing CLI arguments and brooklyn.properties
entries with a suggestion how it should be handled in the Karaf world.
https://docs.google.com/spreadsheets/d/19Tx-LLmqvboLJSQVAcyrbM9FJTaDWFJGMJuFnT_gNgY/edit#gid=0
<https://docs.google.com/spreadsheets/d/19Tx-LLmqvboLJSQVAcyrbM9FJTaDWFJGMJuFnT_gNgY/edit#gid=0>
Svet.
