Hi,
OK thanks for that I will allow arbitrary objects then.
Do you think it is reasonable to also add tags from brooklyn.tags yaml
on rebind?
Valentin.
На 31/03/17 в 14:50, Aled Sage написа:
+1; let's support arbitrary objects.
As for DSL, it does work if your very careful which DSL expressions to
use (e.g. see [1]).
Things like `$brooklyn:external` etc may well be useful, but that's
tricky: we've said elsewhere that we will not store the resolved value
of such a DSL expression. However, our `entity.tags().getTags()` won't
resolve the DSLs so the caller will get back the DSL objects (i.e.
different behavior to config etc). I therefore suggest we deffer
supporting that.
I agree we should forbid Futures/Tasks/DeferredSuppliers - DSL will
only be usable if its parsing resolves the value immediately (which it
does do for `$brooklyn:object` if there are no nested DSL values).
Aled
[1]
https://github.com/apache/brooklyn-server/pull/612#issuecomment-290046363
On 31/03/2017 12:11, Svetoslav Neykov wrote:
I think we should support arbitrary objects for tags. Users should
use only tags they understand, so it's fine to have free-form tags in
there.
The problem with tag objects in YAML is that we can't use DSL -
because the tags need to be resolved pretty early, while
constructing the EntitySpec when there are no running entities. So
Futures/Tasks/DeferredSuppliers should not be allowed for tag values.
On the other hand YAML lists, maps could be useful.
Svet.
On 31.03.2017 г., at 11:49, Valentin Aitken
<[email protected]> wrote:
Hi,
I'd like to bring attention to a new feature I suggested in
BROOKLYN-460 [1] and [2].
Current requirement is to be able to supply String tags in an entity
spec in YAML so it can be then retrieved via REST API with GET
/v1/applications/<appId>/entities/<entityId>/tags.
Example usage in a YAML blueprint:
services:
- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
brooklyn.tags:
- tag1
- "2"
- hello world
Please shout if you have further requirements for brooklyn.tags.
Main concern raised in [2] comments is whether that syntax should
support any Object as a tag.
My concern is that although Object is allowed
in Apache Brooklyn only classes defined in
org.apache.brooklyn.core.mgmt.BrooklynTags are used as a tag.
Every entity has this tag at the moment:
[{"kind":"yaml_spec","contents":"services:\n- type......"}]
That is good since REST query for tags in every entity will have
"kind" field which someone can rely on.
Good use case is to very easy filter out kind -> yaml_spec and
making sure user can retrieve only tags assigned in YAML.
That's why I decided to follow the same pattern and in YAML and accept
string values only which are then passed to
org.apache.brooklyn.core.mgmt.BrooklynTags.newNotesTag
in order to keep existing pattern with "kind" and "contents" fields
for every tag.
[1] https://issues.apache.org/jira/browse/BROOKLYN-460
[2] https://github.com/apache/brooklyn-server/pull/612
--
Valentin Aitken
Software Engineer
Cloudsoft Corporation Ltd.
www.cloudsoft.io
