I don't think we can use TOSCA functions for Martin's example, at least
not directly.
TOSCA functions have a much narrower scope, from what I understand, so
it is worth looking closely at that, and at the semantics around when
the functions are evaluate which I think in general is as early as
possible. Brooklyn OTOH evaluates them as late as possible. I don't
know if the Brooklyn way of putting promises (Tasks and Futures and
DeferredSuppliers) into maps to achieve this is compatible.
I think the TOSCA way to handle Martin's use case is with requirements;
these could be translated into $brooklyn:attributeWhenReady when
converting to Brooklyn. However if converting from Brooklyn to TOSCA I
expect we'll need two paths:
* a "naive" path which permits arbitrary strings set in TOSCA to be
evaluated by Brooklyn as YAML (and the $brooklyn DSL interpreted then)
* a requirements path which defines relevant requirements/relationships
in a generic way
The second is likely quite a lot more work, and may require work for
each of many many different contexts where we use the Brooklyn DSL, but
it will lead to an elegant formal model around requirements and
dependency injection, as opposed to the semantically loose way the DSL
is used. For instance it would be very hard to support our current
dependency injection with an intuitive UI; the TOSCA formal model would
give this, but of course we'll have to do all the work to have types so
that a UI can support the many kinds of dependency injection that people
do. Martin's use case is a good first example.
Best
Alex
On 23/10/2015 11:15, Jose Carrasco wrote:
Hi all
I think we should add support for TOSCA functions instead of use DSL directly
on TOSCA templates.
However, we could use the DSL implementations for supporting the TOSCA
functions. For example, the concat function could be
done using FormatString DSL class. And adding the FunctionWithArgs to the
EntitySpec.
The getAttribute function, {getAttribute template, att }, could be supported
using getAttibute DSL, (of course using the tosca.node.type ConfigKey instead
of camp.id)
I am using these functions on Relations Section from TOSCA document (I will try
finalize this section today ;-) ).
does it make sense?
Best,
Jose
El 23/10/2015, a las 11:57, Martin Harris <[email protected]>
escribió:
Hi Folks,
As part of the TOSCA integration, we're (as an initial spike) passing
arbitrary DSL in as part of the TOSCA spec
What is the best way to resolve the DSL, e.g.
`$brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
component("MySqlNode").attributeWhenReady("datastore.url"), "visitors",
"brooklyn", "br00k11n")`
Cheers
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
