brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: Locations defined on child items -- Inheriting and overriding locations
Date Thu, 14 Jan 2016 20:11:21 GMT

Sent from my iPhone

> On 14 Jan 2016, at 17:10, Ciprian Ciubotariu <> wrote:
> This seems to clear up the way locations are assigned in these corner cases, 
> making blueprint authoring an easier task.
> +1
>> 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