Uploaded image for project: 'Brooklyn'
  1. Brooklyn
  2. BROOKLYN-184

Entities to be auto-managed, rather than calling Entities.manage()

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 0.8.0
    • 0.9.0
    • None

    Description

      As per the dev@brooklyn e-mail thread entitled "PROPOSAL] entities always managed when instantiated", entities should be automatically managed, rather than us having an explicit Entities.manage() method.

      http://mail-archives.us.apache.org/mod_mbox/incubator-brooklyn-dev/201509.mbox/%3C55FFE916.7030103%40gmail.com%3E

      Proposal

      When an entity is instantiated (which always involves setting its parent, unless it is a top-level app) then the entity will immediately be managed.

      The call to Entities.manage() will be deprecated. Its implementation will check that the entity is managed - if it is not, there will be a log.warn about the deprecated behaviour and the entity will be explicitly managed (for backwards compatibility).

      We will deprecate the NonDeploymentManagementContext (which is only used internally), and will delete it when Entities.manage() is deleted.

      Historic reason

      The reason we didn't just automatically manage an entity when it is constructed is mostly historic.

      There was a perceived use-case that one might instantiate an entity, explicitly set config on it, and only then manage it. However, everywhere (I believe) we set the entity's configuration on the EntitySpec before instantiating it - that is certainly the case for YAML-based entities! The only time we couldn't do that is if we have two entities (X and Y) that require config values that depend on each other - e.g. X wants a config value of an attributeWhenReady on Y, and vice versa. However, that (contrived?) use-case does not justify the confusion of the explicit manage. We could handle such use-cases by writing Java code in the entity, if we come across them.

      Current code

      Currently, an entity only becomes "managed" (i.e. visible to other entities) when it or its parent/grandparent/etc is explicitly managed.

      This leads to two very different ways of dealing with entities:

      • For child entities instantiated in an entity's init(), one does not
        have to call an explicit manage().
        This is because those children will piggie-back on the parent entity
        becoming managed at some point after it has been initialised.
      • For top-level apps (e.g. referenced via YAML), the code that reads
        the blueprint will automatically do the manage() so folk don't need
        to worry about it.
      • For child entities instantiated after the parent is managed, then
        the parent must explicitly call manage().
        For example, when a cluster grows (i.e. adds additional child
        entities), then that code explicitly calls manage().

      There is overly complicated code for handling entities that have been instantiated but that are not yet managed. The entity has a NonDeploymentManagementContext, which allows some operations and forbids others; that is swapped for the real ManagementContext when the entity becomes managed.

      Attachments

        Activity

          People

            aled.sage Aled Sage
            aled.sage Aled Sage
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: