Martin-
This should do it, given a mgmt context and a map object:
CampUtils.getCampPlatform(mgmt).pdp().applyInterpreters(map);
The code is intended for CAMP deployment plans but actually there is
actually nothing CAMP-specific about that portion which applies the DSL
interpreter. It could be quite easily refactored if desired. If your
input might not be a map, you can just wrap it in a map of course.
Best
Alex
On 23/10/2015 13:17, Martin Harris wrote:
Hi Alex,
Makes sense. I'm currently working on the "naive" path, but I can't find a
way to resolve the $brooklyn DSL. Is there a sensible way of doing this?
Cheers
M
On 23 October 2015 at 12:06, Alex Heneveld <[email protected]>
wrote:
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.
--
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.
