You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Sam Corbett <sa...@cloudsoftcorp.com> on 2014/09/01 12:10:42 UTC
Persisting catalogues
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
RE: Persisting catalogues
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
Hi Sam,
It'd be useful to have one more case:
* If persistence is enabled and there is a persisted catalogue provide the
option to override and load the default catalog. Useful when updating the
catalogue.
We should consider cases with serialization where the catalog item depends
on external resources - YAML references or OSGi bundles. Those resources are
not guaranteed that they will be accessible on the failover nodes, available
long term or even if they will not change. The simplest case is local file
URLs which won't be valid globally.
Svet.
-----Original Message-----
From: Sam Corbett [mailto:sam.corbett@cloudsoftcorp.com]
Sent: Monday, September 1, 2014 1:11 PM
To: dev@brooklyn.incubator.apache.org
Subject: Persisting catalogues
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
Re: Persisting catalogues
Posted by Aled Sage <al...@gmail.com>.
Hi all,
I spoke to Richard about this. Here's a summary of our
discussion/conclusions.
Comments/feedback gratefully received.
_*Use-cases*_
To summarise, the use-cases are:
1. Bootstrapping brooklyn: the first ever startup by a new user should
by default show everything in the catalog.
2. Can explicitly add new blueprints via the REST api, including for:
1. a blueprint that is purely YAML (i.e. all entities + resources
are already on the classpath somehow)
2. a YAML + new OSGi bundles combo
3. Can add/remove/upgrade blueprints via OSGi bundles
i.e. equivalent of (1), where the catalog items were auto-discovered
from the blueprints shipped with brooklyn (i.e. in OSGi bundles?) at
startup
1. Add a new bundle
(its implicit blueprints will be added automatically)
2. Upgrade a bundle
(the new versions of its implicit blueprints will be added
automatically)
3. Delete a bundle
(its implicit blueprints will automatically be deleted)
4. Changes to the catalog/bundles are persisted:
1. Survives a brooklyn restart
2. All Brooklyn servers (including standby servers for HA) are
automatically updated as well
By a bundle's "implicit blueprints", I mean those entities annotated
with `@Catalog` or the YAML blueprints contained within that resource.
(separate discussion for how these are referenced - e.g. classpath
scanning for @Catalog, and/or a mechanism similar to Java services in
meta-inf for referencing the YAML files).
Deferred use-cases:
1. A power-user wants to restrict the catalog items to only those
explicitly listed (i.e. no "implicit blueprints").
This power-user might want a nice tick-list to select the blueprints
to expose.
2. If deleting a bundle, detecting which other blueprints will be
affected, i.e. which reference entities in that particular (version
of the) bundle.
---
_*Proposal*_
The definitive list of catalog items is persisted, along side the entity
state. (@sjcorbett is working on this)
If Brooklyn is started with no persisted state, then catalog.xml is read
(for bootstrapping). Otherwise, it is ignored (with log.info
<http://log.info> saying so).
REST api extended to support bundle deployment. The bundle's "implicit
blueprints" are found, and automatically added to the catalog.
On a bundle being added (including if referenced as in use-case 2.2),
the bundle is downloaded and persisted (e.g. in object store).
_*Proposal future stages: bundle dropin*_
Support a bundle "dropin" directory. Similar to WildFly / Tomcat,
additions are auto-detected. The bundle is loaded and a marker file is
written to ./dropins/ to indicate success/failure. Once loaded, it is
identical to if the bundle was added via the REST api.
_*Proposal future stages: all entities in OSGi bundles*_
In the main brooklyn distro, we ship anything that contains
blueprints/entities/policies as OSGi bundles. These no longer go in
./lib/brooklyn/*.jar on the classpath. Instead they go in a directory of
core bundles.
The addition/removal/upgrade of these bundles is handled in the same way
as any other user bundles.
We would not use ./lib/patch/*.jar for these. Instead a new bundle
version would be deployed.
The brooklyn core project etc would for now remain as vanilla jar files
(i.e. in ./lib/brooklyn/*.jar), with the existing ./lib/patch/*.jar
mechanism continuing to be used.
Aled
On 04/09/2014 10:41, Sam Corbett wrote:
> 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.
>
> Sam
>
> P.S. For long-lived Brooklyns and managing changes to entities, Svet
> did a lot of work on versioning in #92
> <https://github.com/apache/incubator-brooklyn/pull/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
>> <sa...@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.
>
>
Re: Persisting catalogues
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
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.
Sam
P.S. For long-lived Brooklyns and managing changes to entities, Svet did
a lot of work on versioning in #92
<https://github.com/apache/incubator-brooklyn/pull/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 <sa...@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.
Re: Persisting catalogues
Posted by Richard Downer <ri...@apache.org>.
Hi Sam,
On 3 September 2014 17:28, Sam Corbett <sa...@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.
Re: Persisting catalogues
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
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 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.
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:
/
entities/
-> all entities in management context
locations/
-> locations used by entities
..
catalog/
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?
Sam
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 <sa...@cloudsoftcorp.com> 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
Re: Persisting catalogues
Posted by Richard Downer <ri...@apache.org>.
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 <sa...@cloudsoftcorp.com> 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