brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivana Yovcheva <ivana.yovch...@cloudsoftcorp.com>
Subject Re: Support for external config in catalog definition
Date Thu, 07 Jan 2016 14:27:31 GMT
Hi,

This is the PR - #1130
<https://github.com/apache/incubator-brooklyn/pull/1130>. Could someone
review please?
Thanks!

Best,
Ivana


On 5 January 2016 at 19:36, Aled Sage <aled.sage@gmail.com> wrote:

> Hi Ivana,
>
> Tricky - given the first level of yaml parsing is being done in a
> completely different place.
>
> I think that BasicBrooklynCatalog just stores the yaml of the "item" as a
> String, and later will get the brooklyn-camp module to parse it.
>
> ---
> In BasicBrooklynCatalog, can you just look up the CampYamlParser, and use
> that to parse the relevant values? That would be a similar approach as in
> PR #1112:
>
> mgmt.getConfig().getConfig(CampYamlParser.YAML_PARSER_KEY)
>
> ---
> I don't think we should have to write another parser. Can you elaborate on
> what you are intending to do with "writing now a small parser", so can we
> just solve that by looking up the CampYamlParser instead?
>
> Aled
>
>
> On 05/01/2016 17:01, Ivana Yovcheva wrote:
>
>> Hi all,
>>
>> I'm working on the usage of external config in catalog definition.
>>
>> Here is an example:
>>
>> *brooklyn.catalog:*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *  id: mysql  version: 1.0  description: A MySql server  displayName:
>> Mysql  iconUrl: classpath:///mysql-logo-110x57.png  itemType: template
>> brooklyn.libraries:  - $brooklyn:external(A, B)  item:    services:*
>>
>>
>> *    - type: brooklyn.entity.database.mysql.MySqlNode*
>> For the value of *'item' *there is working code that parses the
>> '$brooklyn'
>> tag.
>> So we are interested in the other keys.
>> As there is no recursion for them, the best approach is to parse each
>> value
>> and if it contains the tag, to replace it with the object returned from
>> the
>> parser or leave it unchanged otherwise.
>>
>> *Here comes a problem.* *DslParser* is in *brooklyn-camp* module, which
>> depends on *brooklyn-core*.
>> I need to use it in *BasicBrooklynCatalog *which is in *brooklyn-core* but
>> cannot depend on *brooklyn-camp*.
>>
>> There is similar PR (#1112
>> <https://github.com/apache/incubator-brooklyn/pull/1112>) to support
>> external config in *BrooklynProperties*, were there is no recursion, but
>> it
>> is used from classes in the* brooklyn-camp* module.
>>
>>
>> One approach is to write similar parser out of the camp module, but this
>> means too much repetitive code.
>>
>> The other is to move *DslParser *out of *brooklyn-camp*, which looks the
>> best for the future.
>>
>> I am writing now a small parser for the catalog only in order to introduce
>> the feature and we can remove it after refactoring as moving *DslParser
>> *is
>> bigger task.
>>
>> Could you give some advice or share opinion?
>>
>> Best,
>> Ivana
>>
>>
>

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