brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Corbett <>
Subject Re: Persisting catalogues
Date Wed, 03 Sep 2014 16:28:36 GMT
Hi Richard,

Is trying to merge catalogues preferable? It strikes me as a recipe for 
conflicts. Do we require that the user make the same change to all 
servers in a HA deployment? Would the server baulk at discrepancies? 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.

With regard to automatically populating the catalogue, does it not 
happen already? I'd thought it was intended at least. I made a change to 
location resolution recently so custom location resolvers (like 
DockerResolver in Clocker) are loaded properly. Perhaps the same needs 
to happen when the server scans for @Catalog annotated classes.

Speaking of discrepancies, it feels unusual to me that location 
definitions are not part of the catalogue. I guess this is historical, 
but the split makes life a bit awkward. I'm working toward persisting a 
structure ~ like:

      -> all entities in management context
      -> locations used by entities
      id -> xml representation of a brooklyn.catalog.CatalogItem.

There is nowhere to store location definitions (/specs) in this 
structure. Do I try to work them in to the catalog directory or should 
they be another top-level item?


On 02/09/2014 14:29, Richard Downer wrote:
> Hi Sam,
> Is there any way to merge the persisted catalog with the defined
> catalog? So that if the user adds new entries to the catalog through
> another mechanism (catalog.xml being the obvious one) they will be
> added to Brooklyn even if there is persisted state.
> Perhaps only late-added catalog entries - using the mechanism you
> suggest - should be persisted? Everything loaded through catalog.xml
> does not get persisted?
> Ideally in the future I'd like to see the catalog get populated
> automatically through introspection, so that dropping e.g. the Clocker
> jar into dropins would be all that's needed to get it into the
> catalog. So I'm keen that your solution here wouldn't conflict with
> that. OTOH, code talks, and I don't have any code yet :-)
> Richard.
> On 1 September 2014 11:10, Sam Corbett <> wrote:
>> Hi all,
>> Another feature proposal and request for comments.
>> Brooklyn maintains a catalogue of applications, entities and policies. This
>> catalogue can be updated programatically:
>>      managementContext.getCatalog().addItem(..)
>> Or restfully by VERBing /v1/catalog.
>> At the moment this catalogue is not persisted when you stop Brooklyn. Any
>> modifications made after start-up are lost forever. I would like to change
>> that.
>> I think the only point of contention is what is loaded from where and when.
>> I propose that when the server starts:
>> * If persistence if disabled load the default catalogue;
>> * If persistence is enabled but there is no persisted catalogue (i.e. the
>> server is running for the first time) then load the default catalogue;
>> * Otherwise load the persisted catalogue. Do _not_ load the default
>> catalogue.
>> Any comments?
>> Thanks,
>> Sam

View raw message