Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: neykov <git@git.apache.org>
To: dev@brooklyn.apache.org
Reply-To: dev@brooklyn.apache.org
Message-ID: <git-pr-617-brooklyn-server@git.apache.org>
Subject: [GitHub] brooklyn-server pull request #617: Persist management plane ID
Content-Type: text/plain
Date: Mon,  3 Apr 2017 07:45:49 +0000 (UTC)
archived-at: Mon, 03 Apr 2017 07:45:51 -0000

GitHub user neykov opened a pull request:

    https://github.com/apache/brooklyn-server/pull/617

    Persist management plane ID

    Some considerations on where to place the planeId initialisation:
     * BrooklynMemento (RebindManager). `planeId` will be available only after rebind, so it will
       be available to MASTER nodes only (and potentially HOT_STANDBY)
     * ManagementPlaneSyncRecord (HighAvailabilityManager). Used only when HA is enabled. When HA is disabled
       HighAvailabilityManager is not initialised, doesn't access the store at all, no
       records are getting written.
     * Separate init step in BrooklynLauncher. Early in the lifecycle so users need not to care
       too much when they are allowed to read it. On the other hand it's not encapsulated so
       need to touch all places that use persistence (i.e. launcher, copy-state, backup). Can
       only read from the store at this point, write access is not enabled yet. If HA is configured
       store writes are enabled only after becoming master. Writing to the store in this case would
       be risky, even if we know that it's a clean state (no planeId file). Better leave only the
       master update the store.
    
    Because of the above I decided to go for a mixed approach:
      * persist the `planeId` immediately after starting persistence (i.e. MASTER when HA) and repeat hourly
      * don't overwrite persisted store `planeId` if different
      * init `planeId` as part of the rebind sequence; if no `planeId` exists in store generate one
      * init `planeId` when reading the management records so we have it initialized for non-`MASTER` nodes as well; don't generate one if not in persisted store

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/neykov/brooklyn-server plane-id

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/617.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #617
    
----
commit 7bcc566bec9e4875207036b1943c4528aae72bea
Author: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
Date:   2017-03-30T14:19:43Z

    Persist management plane ID

commit 701c716aa27dbc3999c9c2fdd728e09089448b1a
Author: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
Date:   2017-04-03T07:32:54Z

    Persisting management plane ID test coverage

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---