brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ciprian Ciubotariu <>
Subject Re: Locations defined on child items -- Inheriting and overriding locations
Date Thu, 14 Jan 2016 17:10:41 GMT
This seems to clear up the way locations are assigned in these corner cases, 
making blueprint authoring an easier task.


On Thursday 14 January 2016 15:52:01 Alex Heneveld wrote:
> Hi folks-
> In #1143 we're trying to resolve some inconsistencies in how catalog
> items are referenced and extended.
> (Disclaimer: this is quite a subtle point, and it has no effect on most
> cases where locations are defined at the root and software processes are
> used.)
> Most of the fixes are uncontroversial but there are two which are
> noteworthy:
> FIRST:  Locations inherited rather than passed to start(...)
> * Previously when a location was set on an app in YAML, it was passed by
> the app as a parameter to "start"
> * Entities tend to find their locations by looking 1) at what is passed
> in to start (if supported), then
>      2) what is defined as location/locations on the entity in yaml,
> then 3) what ancestors have defined as location/locations
> This combination meant that if I have this YAML:
> services:
> - type: A
>    location: L2
> - type: B
> location: L1
> Then A would normally take location L1 because the app passed it and (1)
> above applied.  This meant L2 could be ignored.  With a change in #1143
> we will now prefer L2 for A.  The more common case, "B", will still get
> L1 because it should look in its ancestry as it has no locations
> available locally.  Note that this means that calls to
> "Entity.getLocations()" might return a smaller set than previously.
> "Entities.getAllInheritedLocations(Entity)" has been introduced for when
> that behaviour is desired.
> This moves us away on relying on start(Location) which while it was
> handy in java, is awkward in a YAML-based world.  It also makes
> behaviour consistent with when things are declared as entity-specs (when
> a locally-defined location, eg L2, was preferred).
> SECOND:  Can override locations when extending a type
> Now let's consider a type T1 defined in the type registry (fka catalog)
> which includes a "location: L1" block intended as a default or an
> example (as in templates 2 and 4 in our default catalog).  A caller
> defines a block with
>      type: T1
>      location: L2
> Previously these were *combined* and T1 would have L1 and L2.  But we
> didn't normally notice because of the FIRST problem.  Now however we
> need a way for the caller to override L1.  And combining locations is an
> odd thing in most cases.  So these semantics have changed, L2 replaces
> L1.  The same is true if the caller supplies a list "locations".  In
> particular, if the caller wants his block to inherit from the outer
> location, he can do this:
> services:
> - type: T1
>    locations: []   # means inherit
> location: L2
> It would be good to find clearer ways to express this, but this shift in
> semantics solves all known use cases (in particular templates 2,3,4 in
> the examples!) without needing new concepts.  It passes the "does what I
> expect in most cases" test, although edge cases are more complicated
> than we'd like!
> I hope this finds favour among the list until we have a better
> approach.  (And as mentioned I'd really like to use better typed
> relationships as a foundation of a better approach, cf HOSTED_ON from
> tosca.)
> Best
> Alex

View raw message