brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-49) Catalogue should be persisted and used when rebinding
Date Fri, 19 Sep 2014 15:44:33 GMT


ASF GitHub Bot commented on BROOKLYN-49:

Github user aledsage commented on a diff in the pull request:
    --- Diff: core/src/main/java/brooklyn/entity/rebind/ ---
    @@ -573,16 +618,44 @@ protected BrooklynMemento retrieveMemento(final ClassLoader classLoader,
final R
    +            // Register catalogue items with the management context.
    +            CatalogLoadMode catalogLoadMode = managementContext.getConfig().getConfig(BrooklynServerConfig.CATALOG_LOAD_MODE);
    +            if (persistCatalogItemsEnabled && !CatalogLoadMode.LOAD_BROOKLYN_CATALOG_URL.equals(catalogLoadMode))
    +                if (isEmpty) {
    +                    // Load catalogue as normal
    +                    LOG.debug("RebindManager loading default catalog because there is
no persisted state");
    +                    ((BasicBrooklynCatalog) managementContext.getCatalog()).resetCatalogToContentsAtConfiguredUrl();
    +                } else {
    +                    // Reset catalog with previously persisted state
    +                    LOG.debug("RebindManager resetting management context catalog to
previously persisted state");
    +                    managementContext.getCatalog().reset(rebindContext.getCatalogItems());
    +                }
    +            } else if (persistCatalogItemsEnabled) {
    --- End diff --
    I'm a bit confused here. If the feature is enabled (i.e. `persistCatalogItemsEnabled`)
and the catalog mode is `LOAD_BROOKLYN_CATALOG_URL`, then we about ignoring the persisted
catalog but we don't change the persisted state at all. I can kind-of see why (it's like starting
with persistence disabled for the catalog).
    However, it gets confusing because modifications to this catalog will be persisted. Those
modifications might conflict in some way with the already-persisted state.
    Conclusion: I think we need a clearer indication of what to do with the catalog. What
are the use-cases? How many of these are we supporting?
    * no persistence; just catalog.xml
      (i.e. `--persist disabled` from CLI)
    * if there is persisted state, including catalog, then use it
      (i.e. `--persist auto` and set property `persistCatalogItemsEnabled` to true)
    * if there is persisted state, but there is no persisted catalog (e.g. customer has never
turned on this feature before), then populate it from catalog.xml
      (i.e. `--persist auto` and set property `persistCatalogItemsEnabled` to true)
    * use persisted state, but not for the catalog (i.e. just use catalog.xml)
      (i.e. `--persist auto` and set property `persistCatalogItemsEnabled` to false)
    * override the existing persisted catalog with the contents from catalog.xml
      (not currently supported? suggest we ignore this)

> Catalogue should be persisted and used when rebinding
> -----------------------------------------------------
>                 Key: BROOKLYN-49
>                 URL:
>             Project: Brooklyn
>          Issue Type: Improvement
>            Reporter: Sam Corbett
>            Assignee: Sam Corbett
> Proposal:
> The catalogue, consisting of application templates, entities, policies and 'configuration'
(whose purpose is unknown to me and is unused in general), will be persisted to a `catalog`
directory alongside enrichers, entities, locations, nodes, plane and policies. Location definitions
(that are conceptually linked but are unrelated in code) will be stored too.
> Modes of operation:
> * 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. 

This message was sent by Atlassian JIRA

View raw message