Hi Valentin,
Regarding rebind - not quite sure what you mean. After rebind, the
entities should have the same tags as they had before Brooklyn was
shutdown. That will include all the tags that came from `broolyn.tags`
section of the yaml blueprint, because those have already been set on
the entity instance. Is that not the case? We can discuss technical
details in the PR if that's easier.
Aled
On 31/03/2017 13:20, Valentin Aitken wrote:
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
