+1 On Mon, 21 Sep 2015 at 15:02 Alex Heneveld <[email protected]> wrote:
> > +1 > > I think we didn't have EntitySpecs when entities weren't automatically > managed. Now that we have it this will be a nice big cleanup! > > Best > Alex > > > On 21/09/2015 06:25, Aled Sage wrote: > > Hi all, > > > > I'd like entities to be automatically managed, rather than us having > > an explicit Entities.manage() method. > > > > _*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. > > > > Thoughts? > > > > Aled > > > > > > > -- > Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. > Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP > > This e-mail message is confidential and for use by the addressee only. If > the message is received by anyone other than the addressee, please return > the message to the sender by replying to it and then delete the message > from your computer. Internet e-mails are not necessarily secure. Cloudsoft > Corporation Limited does not accept responsibility for changes made to this > message after it was sent. > > Whilst all reasonable care has been taken to avoid the transmission of > viruses, it is the responsibility of the recipient to ensure that the > onward transmission, opening or use of this message and any attachments > will not adversely affect its systems or data. No responsibility is > accepted by Cloudsoft Corporation Limited in this regard and the recipient > should carry out such virus and other checks as it considers appropriate. > -- Thomas Bouron • Software Engineer @ Cloudsoft Corporation • http://www.cloudsoftcorp.com/ Github: https://github.com/tbouron Twitter: https://twitter.com/eltibouron -- Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
