In https://issues.apache.org/jira/browse/ACE-372
an extension is proposed that allows you to set certain attributes on the target and propagate them as tags or attributes of the target object in the client API. The use case being that certain attributes can only be determined and set by the target itself (memory size, display resolution, IP address, etc.) but would still be very useful to have and match against in the client. It would allow you to select distributions based on them, or fill out configuration templates.
...
I would argue that adding this to the audit log is the best solution. It saves us from having to have two feedback channels. I'd rather have one channel (and possibly slightly rename it) than having multiple ones with potentially more code duplication and worse performance. It would still be possible for users of ACE to define new feedback channels for their own purpose, we just want to make sure that ACE itself only uses one.
Naming attributes
On the target, attributes can have simple (string) names. When merging them with the TargetObject we have to decide two things:
- Do we store them as attributes or tags?
- Do we prefix them to create a certain namespace?
As attributes were designed to be things that fundamentally belong to an object and tags as things that are added by a user, I think we can quickly conclude we want these attributes to be tags.
Creating a namespace has two advantages: First of all, they directly communicate to the end user that this is a tag that was set by the target itself. Secondly, if we reserve a namespace, we can also more easily delete tags that are no longer used. Assuming that every time there is a change, the target sends the full set of tags, our server side logic can simply set all those tags and remove any other tags still in the same namespace.
Usage
To set or update properties, you can simply send a feedback event using the API of the management agent:
| Code Block |
|---|
AgentControl ac;
Map m = new HashMap();
m.put("mykey", "myvalue");
ac.getFeedbackHandler().getChannel("auditlog").write(AuditEvent.TARGETPROPERTIES_SET, p);
|
Make sure you always write the full set of properties, as any old ones will be erased. The keys of the properties you set will end up as tags, prefixed with "target." to distinguish them from other tags that might be set manually.
Note that tags will show up as soon as you do a checkout in the ACE client, at which point you will see the repository is in a modified state. Committing such changes will make them take effect. This was done because you don't want to have such changes take effect at any time. Like any other change in the deployment, it must be a deliberate and controllable change.