brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Harris <martin.har...@cloudsoftcorp.com>
Subject Re: Resolving DSL
Date Fri, 23 Oct 2015 14:12:15 GMT
Hi Alex,

That did the trick nicely, thanks

Cheers

M

On 23 October 2015 at 13:33, Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
wrote:

>
> 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 <
>> alex.heneveld@cloudsoftcorp.com>
>> 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 <
>>>> martin.harris@cloudsoftcorp.com> 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.
>



-- 
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855

-- 
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message