My 0.2¢ on the last question - > Should we change the rebind code to be more similar (e.g. so it doesn't try > to coerce), or should we change the provisioning code so that it fails-fast > if the YAML is invalid like this?
I’d vote certainly for the latter; but you could do both together - the former would actually make more sense if the latter were done, surely? Geoff ———————————————————— Gnu PGP key - http://is.gd/TTTTuI > On 13 Nov 2015, at 17:50, Aled Sage (JIRA) <[email protected]> wrote: > > > [ > https://issues.apache.org/jira/browse/BROOKLYN-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004368#comment-15004368 > ] > > Aled Sage commented on BROOKLYN-193: > ------------------------------------ > > We need to fix our rebind code so that it won't fail entirely on errors like > this. > > The error comes from {{BasicEntityRebindSupport.addConfig}} - it calls > {{entity.config().set((ConfigKey<Object>)key, value)}}, which tries to coerce > the value and that fails. > > We probably follow the same pattern as elsewhere in the rebind code - i.e. > call {{rebindContext.getExceptionHandler().on???()}}, and let that handle the > exception. It can choose to just log or to fail. We probably need to add a > new method to {{RebindExceptionHandler}} to indicate this failure type. And > to configure {{RebindExceptionHandlerImpl}} with what to do if there is such > an error - e.g. fail fast, fail at end, or just log. > > We want to document how to set the configuration property (e.g. so that it > will still bring up all the other entities, but with that entity having its > missing config). > > We should also look more at why this was persisted (rather than it failing to > accept the YAML blueprint). It seems that it goes through a different > code-path for provisioning the entity for rebinding the entity. Should we > change the rebind code to be more similar (e.g. so it doesn't try to coerce), > or should we change the provisioning code so that it fails-fast if the YAML > is invalid like this? > > >> Rebind failure: Cannot coerce or set value >> ------------------------------------------ >> >> Key: BROOKLYN-193 >> URL: https://issues.apache.org/jira/browse/BROOKLYN-193 >> Project: Brooklyn >> Issue Type: Bug >> Affects Versions: 0.8.0, 0.9.0, 1.0.0 >> Reporter: Valentin Aitken >> Labels: starter >> >> *Use case* >> If you submit a blueprint with a value of invalid type it is accepted. >> This causes writing invalid data to persistence and which leads to a failure >> on rebind. >> *Steps to reproduce:* >> # Submit a blueprint with a Map value where string value is expected. >> Enter a {color:red}wrong BP{color} >> {code} >> location: aws-centos6 >> services: >> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer >> java.sysprops: >> test: false >> provisioning.properties: >> minRam: 4 >> minHdd: 100 >> {code} >> Instead of {color:green}a correct one{color} >> {code} >> location: aws-centos6 >> services: >> - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer >> java.sysprops: >> test: false >> provisioning.properties: >> minRam: 4 >> minHdd: 100 >> {code} >> # Let's say that by mistake you nest provisioning.properties into >> java.sysprops (java.sysprops is Map<String, String>) >> # The blueprint is accepted and deployed successfully. >> # Restart Apache Brooklyn >> # A startup error occurs >> {code:none} >> java.lang.IllegalArgumentException: Cannot coerce or set' >> 2015-11-13 11:16:50,305 WARN Rebind: continuing after problem rebinding >> entity oisgTyDZ (TomcatServerImpl{id=oisgTyDZ}) >> java.lang.IllegalArgumentException: Cannot coerce or set {minRam=4, >> minHdd=100} to >> java.sysprops.provisioning.properties[ConfigKey:java.lang.String] >> at >> org.apache.brooklyn.core.config.internal.AbstractConfigMapImpl.coerceConfigVal(AbstractConfigMapImpl.java:83) >> ~[classes/:na] >> Caused by: org.apache.brooklyn.util.core.flags.ClassCoercionException: >> Cannot coerce type class >> com.google.common.collect.Maps$TransformedEntriesMap to java.lang.String >> ({minRam=4, minHdd=100}): no adapter known >> at >> org.apache.brooklyn.util.core.flags.TypeCoercions.coerce(TypeCoercions.java:272) >> ~[classes/:na] >> {code} >> *Short-term workaround* >> The persisted state for the relevant entities can be modified to remove the >> incorrect configuration value. >> *The steps to do this are:* >> # stop Apache Brooklyn. >> # backup your existing persisted state. >> # replace the relevant files with those attached. >> # start Apache Brooklyn. >> *Long-term solution* >> We are looking at improvements to Apache Brooklyn: to allow rebind, even >> when there are configuration errors like this (e.g. where the invalid >> configuration value is dropped). > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332)
