Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@grkvlt all we'll do for `SoftwareProcess` instances is change `NONE` from
`NEVER_INHERIT` to `NOT_REINHERITED` so yes, `SP` children of `SP` still won't
see parent's commands, but what it
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@grkvlt yes, that should still work: where children of a
VanillaSoftwareProcess do not want to see the parent's config. The config's
value would "not be re-inherited". That is, if the Vanil
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
Comments from discussion:
* Being able to define resolution at the config key would be useful, eg to
say to prepend to a list
* May need to know *who* defined the value eg so we can
Github user grkvlt commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@aledsage @ahgittin I'm not sure if your proposal will still allow the
behaviour now relied on by Kubernetes, for example, where children of a
`VanillaSoftwareProcess` do *not* want to see th
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@aledage I think child-inheritance is separate to the other two. And
"parent-inheritance" is badly named (since parent-child exists also in type
definition hierarchy); it should be somethi
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@ahgittin (cc @grkvlt @sjcorbett @neykov) am I understanding your
terminology correctly (of `NOT_REINHERITED` vs `NEVER_INHERITED`) that the
former is about "child inheritance" and the latt
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@aledsage good observations
firstly yes this is complicated and we should avoid people needing to know
about it in most cases -- eg use the policy approach, and/or come up with new
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@ahgittin @grkvlt @sjcorbett @neykov This all sounds scarily complicated to
describe to users, with the actual behaviour of inheritance for a given
parent/child entity pair being unclear to
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
Implementation-wise I suggest we deprecate `InheritanceMode` in favour of a
new `StandardInheritanceModes` whose constructors set the values above, with
the following upgrade patterns:
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
Thinking aloud...
Where a key is defined at a parent/ancestor/bequeather it could specify
* is this inheritable? (if false, descendants will never see it and all
other opt
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
I've discovered a problem with this /cc @grkvlt @sjcorbett @aledsage
@neykov.
Some blueprints set some of these keys e.g. `pre.install.command` as
anonymous config on a non-softwar
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
Just what that option is intended for! Merging...
---
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 h
Github user grkvlt commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@aledsage I added the tests you suggested, and updated the failing test
pointed out by @sjcorbett so I think this should be able to be merged now
---
If your project is set up for it, you ca
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@grkvlt will you get a chance to look at this again soon?
Hopefully the tests I wrote and pasted into the comment will work for you.
They certainly failed in the right way without y
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@grkvlt test failure since your last commit looks like a real failure:
`ConfigInheritanceYamlTest.testInheritsParentConfig`.
---
If your project is set up for it, you can reply to this ema
Github user grkvlt commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
@sjcorbett @neykov I'll fix the tests. I'm not convinced the file uploads
should be inherited, so I'll ask the `brooklyn-dev` list to convince me...
---
If your project is set up for it, you
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
Suggest you add the following tests to
`org.apache.brooklyn.entity.software.base.VanillaSoftwareProcessTest`:
@Test
public void testCmdNotInheritedByChildrenOfSoftwarePr
Github user sjcorbett commented on the issue:
https://github.com/apache/brooklyn-server/pull/281
+1 to this, it has caught me out in the past. It potentially breaks
existing blueprints though so should be raised on the mailing list.
The test failures are valid:
ConfigInherita
18 matches
Mail list logo
