brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Locations defined on child items -- Inheriting and overriding locations
Date Thu, 14 Jan 2016 15:52:01 GMT

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


Mime
View raw message