brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Re: Persisting catalogues
Date Wed, 03 Sep 2014 17:05:52 GMT
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.


View raw message