brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request #480: Config self reference fix
Date Wed, 07 Dec 2016 02:57:00 GMT
GitHub user ahgittin opened a pull request:

    https://github.com/apache/brooklyn-server/pull/480

    Config self reference fix

    builds on #462 fixing the remaining issues discussed in BROOKLYN-329
    
    immediate eval could be improved yet further but this fixes scope/resolution issues and
in general makes immediate things much more reliable, as well as fixing recursive references
in config settings, and helping to debug bad task traces

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server config-self-reference-fix

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/480.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #480
    
----
commit 667c3dffbe654dfb409a64ab7e2675784c7d7433
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2016-11-17T15:12:09Z

    implement inheritance of config default values
    
    test and code changes to respect the additional inheritance argument added in the previous
request:
    resolves https://issues.apache.org/jira/browse/BROOKLYN-267

commit 53ae1c611c736ee572801f840785266690531da9
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2016-11-24T10:56:46Z

    migrate config inheritance to new classes
    
    pioneers use of `readResolve` that actually works brilliantly out of the box due to xstream
    
    also tidying `BasicConfigInheritance` and adding a placeholder (not used yet)
    for resolving ancestor defaults
    
    includes tests for config inheritance serialization

commit aef2c7c55f854027bc79bf9ec3ada336ff86955f
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2016-11-24T16:29:21Z

    document better config inheritance semantics

commit 2d762c4c9ee4dd4345fe1b4419cf4f52fb8e1ff3
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2016-11-24T17:34:10Z

    uncomment another assertion about inherited config

commit 536fb1a78066d5c1b0f1c3d3337ee8aa89e4f8e5
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2016-11-29T11:51:57Z

    don't use transients as not reset on deserialization

commit 13648d8c7e5c453c62f7d6de67a3681616c4b930
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-02T00:46:03Z

    PR comments on config defaults

commit 5c6c72136732f1d20e21f217a109db5a7d88b6f1
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-02T00:47:16Z

    no need for `keepSameInstance` in `RebindOptions` as we have a field `mementoDir`

commit 944757ce916c3d70f84612ec26a647c1fe3865c2
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-02T09:17:01Z

    comments on parameter/config inheritance/merging

commit ae0ac1e0ec6b5b054987c909f97fb993705b40ea
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-02T13:54:12Z

    fix test for taking default from parameter
    
    as per (1) at https://issues.apache.org/jira/browse/BROOKLYN-329

commit 1a6717097caabe13872133c432d158360b0123fb
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-02T13:54:50Z

    improve methods for retrieving config keys
    
    previously only looked at what was in the map, not what reference keys might be defined
in the container (eg entity)
    
    as per (5) at https://issues.apache.org/jira/browse/BROOKLYN-329

commit 7177662931b7d0109e44f4653a7e09ddfaffbd7b
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T08:53:49Z

    fix version reference in config inheritance test

commit cc639c52c28b4337eb4b638bfd4182c775891e50
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T10:03:04Z

    need to restrict keys to those present for ssh commands
    
    else we pick up `null` values ... alternatively could take declared and filter for nulls,
    but this change restores the old working behaviour
    
    if ever we need to get default values of keys when passing in this way, we should revert
this and filter null values

commit a2f8b207cc576c350a9a9e9d3431bc8c2df86e8d
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-05T10:50:38Z

    merge default values in config inheritance
    
    as per (6) at https://issues.apache.org/jira/browse/BROOKLYN-329
    
    (only does it for yaml parameters, but that's a limitation we can live with i think;
    notes included on doing it for java)
    
    also switches to new `fromString` which adjusts the interpretation of inheritance "none"
to be NOT_INHERITED,
    with new keyword "never" available if caller really wants NEVER_INHERITED
    (this is in keeping with previous changes to the semantics)

commit b66c5966074a564091c3d35a76d2f8fb94d52791
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T10:50:10Z

    clean up SpecParameterUnwrappingTest

commit e464d2a6237eb668e9233863ad4108c44acc01a5
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T11:42:48Z

    fix merge wrapper semantics to combine parameters not overwrite

commit 4d61ff8f2a0ff785afa9c0fe0437856237d8fe2a
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T15:50:18Z

    handle recursive task errors incl self-ref config
    
    address BROOKLYN-329 case (2), where a config key is defined as a function of itself
    
    detect the endless loop that results and fail with a good message
    
    also better handling in general of endless-loop task failures,
    including:
    
    * bail-out logic in Exceptions.collapse to prevent crazy long strings and traces
    * warning whenever active tasks passes N*1000

commit 373ae654a826d1e572a42e2d67fecfbda9e44213
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T16:09:20Z

    add (failing) test re config loop and immediate evaluation

commit 42c8c103eb90c9b6a33f99332a820a43118c4647
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T16:26:41Z

    better logging and reporting if no entity available for immediate eval

commit f4b22615f3bbe554db08a2c6a9633c4d7caffaff
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2016-11-17T15:11:14Z

    flesh out test cases around non-blocking evaluation

commit 9fe59acfc7c1296303fcc270253417141a005e41
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T22:15:10Z

    immediate execution runs in a fake tag allowing context to be evaluated
    
    most new immediate tests now passing, including a new test which detects recursive config
values for immediate;
    except we still have:
    
    * cancellations of immediate execution goes too far, and cancels tasks which are set as
values
    * task factories still not supported for evaluation

commit 2966283ede9fce959fccfd5a7175ca479b6cda7d
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T22:34:46Z

    solve problem with map eval where tasks are cancelled permanently
    
    sets non-transient if a task is requested for a value-resolver
    
    we might want to deprecate that altogether, instead use TaskFactory
    so we can cancel things
    
    don't think there will be much leaking because the ValueResolver isn't used for new tasks,
    just for tasks which are set as values -- but we need to keep an eye on that.
    such tasks should be cancelled when the entities are cleaned up.

commit a94af161d21bd56d5738d09415c473eb95a3d41a
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-07T00:46:13Z

    slow tests moved to integration group

commit dd887dda687cba3ef14207ffef05b2267d512867
Author: Alex Heneveld <alex@alexs-macbook-pro.local>
Date:   2016-12-06T22:45:14Z

    cleanup, and allow TaskFactory to be supplied as a config and other ValueResolver input
    
    the TF will create a task which will then be used for evaluation.
    much cleaner semantics than setting tasks as values:
    
    tasks evaluate once and remember their result, whereas task factory spawns a new task
each time.
    furthermore, the former cannot be interrupted without making the value _never_ resolvable
(which was the case prior to the previous commit)
    so it is left running if immediate eval is done, whereas the latter can be safely cancelled.

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message