+1 great addition! I'm also in favour of returning YAML instead of plain string, will make the UI work way easier. Alex, I just eyeballed your PR, looks good but left a comment and question there.
Best. On Fri, 21 Sep 2018 at 12:34 Alex Heneveld <[email protected]> wrote: > > +1 > > I've implemented this for the server side at > https://github.com/apache/brooklyn-server/pull/999 . > > One minor tweak to Aled's proposal, I think we should output a > structured YAML rather than the toString, so clients don't have to do > complex parsing. IE instead of sending the string syntax > `requiredUnless("X")` we'd send `requiredUnless: X`. (On input we can > accept either representation, a toString or yaml.) > > Will add support in the UI next (new PR obviously). > > Best > Alex > > > On 21/09/2018 09:08, Geoff Macartney wrote: > > Hi Aled, > > > > I'd say go for it, that looks like something that could be valuable in > > various cases. > > I take it your example of "exactly one of config X or config Y" would be > > expressed > > along the lines of a parallel set of constraints between each config - > > > > On X: > > constraints: > > - requiredUnless("Y") > > - forbiddenIf("Y") > > > > On Y: > > constraints: > > - requiredUnless("X") > > - forbiddenIf("X") > > > > Geoff > > > > > > On Tue, 18 Sep 2018 at 17:05 Aled Sage <[email protected]> wrote: > > > >> Hi all, > >> > >> I'd like to add support for more sophisticated config constraints, where > >> there are inter-dependencies between config keys. I'd like the blueprint > >> composer web-console to understand (a small number of) these, and thus > >> to give feedback to the user about what is required and whether their > >> blueprint is valid. > >> > >> For example, a blueprint that requires exactly one of config X or config > >> Y. Another example: config X2 is required if and only if config X1 is > >> supplied. > >> > >> There are a few questions / decision points: > >> > >> 1. What constraints should we support out-of-the-box? > >> 2. What naming convention do we use, so that the UI can parse + > >> understand these? > >> 3. Should we support multiple constraints (we do in the REST api, but > >> not currently in the Java API or in the Blueprint Composer UI) > >> > >> --- > >> I suggest we support things like: > >> > >> constraints: > >> - requiredUnless("Y") > >> - forbiddenIf("Y") > >> > >> and: > >> > >> constraints: > >> - requiredIf("X1") > >> - forbiddenUnless("X1") > >> > >> The structure of this string would be: > >> > >> {required,forbidden}{If,Unless}("<config>") > >> > >> requiredIf("X1"): value is required if config X1 is set; > >> otherwise optional. > >> forbiddenUnless("X1"): value must be null if config X1 is not set; > >> otherwise optional. > >> requiredUnless("Y"): value is required if config Y is not set; > >> otherwise optional. > >> forbiddenIf("Y"): value must be null if config Y is set; > >> otherwise optional. > >> > >> I don't think we want to get too sophisticated. For example, do *not* > >> support "must match regex '[a-z]+' unless config Y is present". I don't > >> think we should create a full-blown DSL for this! > >> > >> --- > >> Implementation notes: > >> > >> We already have the basis of this in our Java code. We support a > >> predicate of type > >> `org.apache.brooklyn.core.objs.BrooklynObjectPredicate`, which has the > >> additional method `boolean apply(T input, BrooklynObject context)`. The > >> `BrooklynObject` could be an entity, or location, etc. An implementation > >> of this predicate can therefore lookup other config key's values, when > >> validating the value. > >> > >> For the UI, the Blueprint Composer calls: > >> > >> http://localhost:8081/v1/catalog/bundles/ > >> <bundle>/<version>/types/<blueprint>/latest > >> > >> This returns things like: > >> > >> "config": [ > >> { > >> "name": "myPredicate", > >> "type": "java.lang.String", > >> "reconfigurable": false, > >> "label": "myPredicate", > >> "pinned": false, > >> "constraints": [ > >> "MyPredicateToString()" > >> ], > >> "links": {} > >> }, > >> ... > >> > >> The constraint returned here is the toString() of the predicate. > >> > >> In the UI [1], there is currently some very simple logic to interpret > >> this string for particular types of constraint. > >> > >> Aled > >> > >> [1] > >> > >> > brooklyn-ui/ui-modules/blueprint-composer/app/components/providers/blueprint-service.provider.js > >> > >> > > -- Thomas Bouron Senior Software Engineer *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud GitHub: https://github.com/tbouron Twitter: https://twitter.com/eltibouron Need a hand with AWS? Get a Free Consultation.
