Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [PROPOSAL] BROOKLYN-460 Brooklyn Camp syntax for adding tags to
 an entity spec
Date: Fri, 31 Mar 2017 14:11:14 +0300
References: <07be005d-ab28-a77e-058b-44265cb428ec@cloudsoft.io>
To: dev@brooklyn.apache.org
In-Reply-To: <07be005d-ab28-a77e-058b-44265cb428ec@cloudsoft.io>
Message-Id: <A989F492-A606-4F23-BC73-AE9DE5EAD170@cloudsoftcorp.com>
archived-at: Fri, 31 Mar 2017 11:11:23 -0000

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 =D0=B3., at 11:49, Valentin Aitken =
<valentin.aitken@cloudsoftcorp.com> wrote:
>=20
> Hi,
>=20
> 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.
>=20
> Example usage in a YAML blueprint:
> services:
> - type: =
org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
>  brooklyn.tags:
>  - tag1
>  - "2"
>  - hello world
>=20
> Please shout if you have further requirements for brooklyn.tags.
>=20
> Main concern raised in [2] comments is whether that syntax should =
support any Object as a tag.
>=20
> 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......"}]
>=20
> 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.
>=20
>=20
> [1] https://issues.apache.org/jira/browse/BROOKLYN-460
> [2] https://github.com/apache/brooklyn-server/pull/612
>=20
> --=20
> Valentin Aitken
> Software Engineer
> Cloudsoft Corporation Ltd.
> www.cloudsoft.io
>=20