Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <540741B4.9070003@cloudsoftcorp.com>
References: <54044622.3070404@cloudsoftcorp.com>
	<CABQFKi0sfS2hk=vf+BbyDWoctbQ1+5gb0MpofWm_HNYdxKhHsQ@mail.gmail.com>
	<540741B4.9070003@cloudsoftcorp.com>
Date: Wed, 3 Sep 2014 18:05:52 +0100
Message-ID: 
 <CABQFKi0Gc6je+s3b+G=97nc8m0kM2b-0ytjG-SAj4dhRvwWoOw@mail.gmail.com>
Subject: Re: Persisting catalogues
From: Richard Downer <richard@apache.org>
To: Brooklyn dev <dev@brooklyn.incubator.apache.org>
Content-Type: text/plain; charset=UTF-8

Hi Sam,

On 3 September 2014 17:28, Sam Corbett <sam.corbett@cloudsoftcorp.com> wrote:
> I'm coming to
> interpret catalog.xml and brooklyn.properties 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.