Hi all,
For adding new blueprints to the catalog, we propose using YAML like
that below posted to the REST api:
brooklyn.catalog:
- id: brooklyn.entity.nosql.mongodb.MongoDBReplicaSet
- name: MongoDB Replica Set
- description: Launches a MongoDB Replica Set, a cross-platform
document-oriented NoSql database.
- icon_url: classpath://brooklyn/mongodb/mongodb.jpg
- version: 0.6.0
- bundles:
- url:
http://search.maven.org/remotecontent?filepath=io/brooklyn/brooklyn-software-nosql/0.6.0/brooklyn-software-nosql-0.6.0.jar
services:
- type: brooklyn.entity.nosql.mongodb.MongoDBReplicaSet
brooklyn.config:
cluster.initial.size: 3
This example shows registering a MongoDB blueprint, where the code is in
the OSGi bundle at the given URL, with the given blueprint version number.
If one launches this app from the catalog, it will launch the given
"services" (i.e. the given MongoDBReplicaSet entity).
Note that the yaml here is very similar to the existing yaml. The only
new piece is brooklyn.catalog which gives the metadata for the catalog
entry.
By posting this to the REST api for adding to catalog, it registers the
blueprint rather than deploying a new instance of the app.
---
Perhaps the most controversial piece is the how to interpret the service
type.
This type could potentially refer to something in the catalog, or to a
java class, or to a yaml file.
To be explicit, we could support prepending these with "catalog:" or
"java:" or "yaml:".
To make the common case simple, we could try interpreting it in that
order until a lookup succeeds - if the prefix is missing, see if it's in
the catalog, then see if it's a class, then see if it's a url to a file.
To avoid recursive references like in the above (where the service type
is a class, but the the catalog name matches) then we could treat that
as a special case - if the type refers to its own catalog entry then
don't treat it as a "catalog:...".
(In general I dislike rules like that, preferring it to be explicit and
the rules to be simple; but I don't want to force everyone to prepend
"java:" in lots of places.)
Thoughts and comments please?
Aled
On 30/06/2014 15:15, Aled Sage wrote:
Thanks Sam,
I've also created a jira issue (feature) for this work: issue
https://issues.apache.org/jira/browse/BROOKLYN-13
Aled
On 30/06/2014 13:44, Sam Corbett wrote:
Hi all,
A plan for these improvements has been drawn together and is visible
at:
https://docs.google.com/a/cloudsoftcorp.com/document/d/1GV_J3eyOZ63wJDu0y4SQO_jbJF3p0gWTNMvB1Q4FFDA/edit
All comments welcome!
Sam
On 18/06/2014 11:58, Sam Corbett wrote:
To follow up the proposal document I've written a small example to
demonstrate the important changes to the catalogue and to seek
feedback on a smaller part of the work:
<catalog>
<name>OSGi catalogue</name>
<template name="Entity" version="2.3"
type="com.example.entity.EntityInterface">
<description>An entity</description>
<iconUrl>http://...</iconUrl>
<context>
<bundle>
<url>file://path/to/osgi/bundle.jar</url>
</bundle>
</context>
</template>
<template name="Application" version="1.0.1"
type="com.example.blueprints.MyApplication">
<description>An application</description>
<context>
<bundle>
<url>file://path/to/osgi/bundle.jar</url>
</bundle>
<bundle>
<name>com.example.Bundle</name>
<version>4.5</version>
<repositories>
<repository>classpath://...jar</repository>
<repository>http://...jar</repository>
</repositories>
</bundle>
</context>
</template>
</catalog>
Questions:
* Is the current <classpath> element deprecated or just discouraged?
* Can the application refer to the entity directly?
Brooklyn loads this catalogue at start and persists it along with
app+entity+other data.
Later on I want to update the application to a YAML blueprint that
defines version 2.0.0. I POST something like this to the REST API:
<template name="Application" version="2.0.0"
type="http://www.example.com/application.v2.yaml";>
<description>An application v2</description>
<context>
<bundle>
<url>file://path/to/osgi/bundle.jar</url>
</bundle>
<bundle>
<url>http://another/osgi/bundle.jar</url>
</bundle>
</context>
</template>
Question: How does the YAML file get to Brooklyn?
Any comments?
Sam
On 17/06/2014 11:18, Sam Corbett wrote:
Hi all,
There have been a number of requests for improvements to Brooklyn's
catalogue. At the moment it is not possible to add entries to the
catalogue, you cannot refer to YAML blueprints and it is overly
hard to manage several versions of an application.
Alex Heneveld (@ahgittin) has put together a proposal for how we
can change this that is visible at:
https://docs.google.com/document/d/1wWySDhfn5LBHfsNfj0cW0e2lSo-6T9_Ox3mHbKX1Hm8
The proposed features are:
1) Register new blueprints to the catalog with code isolation,
including at runtime
2) Allow references to these registered blueprints respecting their
classpaths
3) Allow catalog changes to be persisted and shared among HA servers
4) Support versioning of items in the catalog
5) Allow managing the catalog via the GUI
Brooklyn would use an embedded OSGi container (Apache Felix) as the
foundation of the catalogue.
Comments and feedback would be welcomed.
Sam
