brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Corbett <>
Subject Re: Persisting catalogues
Date Thu, 04 Sep 2014 09:41:47 GMT
The majority of the blueprint-writers that I know of are not the people 
that are maintaining the server running Brooklyn. They are people who 
will register a new version of a blueprint via the API, probably using 
another UI.

(I believe) the recommended way to add/modify/remove blueprints at 
runtime is to use the REST API. Of course it's impossible to do this 
when the server is not running, so we load from catalog.xml etc., and 
thus already have two different ways of doing things depending on 
whether Brooklyn is running or not.

For lib/dropins .. I'm not clear what we recommend it for. In general 
when I have wanted to add something to Brooklyn's catalogue I have added 
entries to ~/.brooklyn/catalog.xml, not put jars on the classpath 
directly. Is the Official Recommendation to use lib/dropins or catalog.xml?

We could go for a merge strategy when restarting a server, with 
persisted-version-wins, but it is going to be confusing when you run 
Brooklyn, delete something loaded from catalog.xml, restart Brooklyn and 
find the thing you deleted present again.  I guess we could record 
modifications, but that would make the persisted catalogue's structure a 
bit different from everything else we persist.


P.S. For long-lived Brooklyns and managing changes to entities, Svet did 
a lot of work on versioning in #92 
<>. It is all based 
around YAML/OSGi blueprints.

On 03/09/2014 18:05, Richard Downer wrote:
> Hi Sam,
> On 3 September 2014 17:28, Sam Corbett <> wrote:
>> I'm coming to
>> interpret catalog.xml and as files that bootstrap the
>> server. Any interaction with them should be discouraged once the server has
>> started, else everything gets confusing in a persisted and/or multi-server
>> deployment. If a user wants to add a new item to the catalogue they should
>> post its blueprint to the server.
> -1 to the concept that there are two different ways to do things,
> depending on if Brooklyn is already running or not.
> If a Brooklyn installation is going to be long-lived, then it is going
> to need to deal with changes to the entities that are installed in it
> - new things dropped into lib/dropins and so on. I'm not happy with
> the asymmetry of changes like this are done one way before booting,
> and a different way after booting:
> - Brooklyn not running? Just drop it into lib/dropins and it'll
> automatically appear in the catalog!
> - Brooklyn already running? Ah. You'll also need to use curl to POST
> some data to the REST API. Either that, or you shut down your entire
> infrastructure and delete your persisted state and start again.
> I'm afraid that I don't see this proposal as making Brooklyn easier to
> use, and more suited for long-term production use.
> Richard.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message