PR Created: https://github.com/apache/brooklyn-server/pull/813
On 8 September 2017 at 12:08, Graeme Miller <gra...@cloudsoft.io> wrote:
> Geoff, agree we should be adding it to adjunct, that'll be looked at as
> part of a stage 2 (Alex is going to pick this up). Not sure about the term
> "usage
> metadata" things like triggers wouldn't be usage info, and if we extend
> this to adjuncts I imagine people writing enricher highlights might want to
> include things like source and target.
>
> Also, I think adding to the policy endpoint is fine, as it is a property
> of a policy in the same way that status or config is.
>
> Thomas, good point about the keys. How would you feel about the endpoint
> not returning any name field:
> [{
> ...
> "highlights": {
> "lastConfirmation": {
> "description": "sdjnfvsdjvfdjsng",
> "time": 12345689,
> "taskId": 1345
> },
> ...
> }
> }]
> Having both the name and the key might be redundant. If not, I also favour
> your list approach although it is a bit of a pain for the API consumer.
>
>
> On 7 September 2017 at 14:58, Alex Heneveld <alex.heneveld@cloudsoftcorp.
> com> wrote:
>
>>
>> +1 to this, with Thomas's suggestion of a list instead of map and Geoff's
>> suggestion of doing it on adjuncts. would be nice to have an adjunct api
>> which lets clients treat policies, enrichers, and feeds the same.
>>
>> i can see this being useful for policies to record selected highlights of
>> their activity so a consumer doesn't have to trawl through all activity to
>> see what a policy has done lately. last value is a good compromise between
>> having some info without trying to remember everything. sensors on
>> adjuncts could be another way -- maybe we'd move to that in future -- but
>> for now that seems overly complex.
>>
>> --a
>>
>>
>>
>> On 07/09/2017 14:02, Thomas Bouron wrote:
>>
>>> Hi Graeme.
>>>
>>> Sounds very useful to me. Would be great to have this info properly
>>> formatted in the CLI and UI.
>>>
>>> As for the structure, I would suggest to avoid spaces in map keys as best
>>> practice, so having either:
>>>
>>> [{
>>> ...
>>> "highlights": {
>>> "lastConfirmation": {
>>> "name": "Last Confirmation",
>>> "description": "sdjnfvsdjvfdjsng",
>>> "time": 12345689,
>>> "taskId": 1345
>>> },
>>> ...
>>> }
>>> }]
>>>
>>> or maybe even better, something like this:
>>> [{
>>> ...
>>> "highlights": [
>>> {
>>> "name": "Last Confirmation",
>>> "description": "sdjnfvsdjvfdjsng",
>>> "time": 12345689,
>>> "taskId": 1345
>>> },
>>> ...
>>> ]
>>> }]
>>>
>>> In terms of implementation, it would be useful to extend it to other
>>> types
>>> of Brooklyn Object such as enrichers, etc. Although, it looks like Geoff
>>> has already made the same comment/suggestion.
>>>
>>> Cheers
>>>
>>>
>>> On Thu, 7 Sep 2017 at 13:30 Graeme Miller <gra...@cloudsoft.io> wrote:
>>>
>>> Hello,
>>>>
>>>> I'd like to make a change to the REST API for policies. As this is a
>>>> REST
>>>> API change I figured it would be best to flag it on the mailing list
>>>> first
>>>> in case anyone has any objections.
>>>>
>>>> It would be useful when consuming this API to be able to find out more
>>>> information about the policy. Specifically, it would be useful to find
>>>> out
>>>> things like last action performed, last policy violation, last
>>>> confirmation, what the triggers are etc.
>>>>
>>>> To do so, I plan to amend the REST API to include 'highlights' for a
>>>> policy. Highlights are a map of a name to a tuple of information
>>>> including
>>>> description, time and task.
>>>>
>>>> Essentially this endpoint:
>>>> "GET /applications/{application}/entities/{entity}/policies"
>>>> Will now include this:
>>>> [{
>>>> ...
>>>> "highlights": {
>>>> "Last Confirmation": {
>>>> "description": "sdjnfvsdjvfdjsng",
>>>> "time": 12345689,
>>>> "taskId": 1345
>>>> },
>>>> ...
>>>> }
>>>> }]
>>>>
>>>> Please shout if you have any problems with this, otherwise I'll submit
>>>> a PR
>>>> shortly with this change.
>>>>
>>>> Regards,
>>>> Graeme Miller
>>>>
>>>>
>>
>
