brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Miller <gra...@cloudsoft.io>
Subject Re: REST API: Policy endpoint addition
Date Fri, 08 Sep 2017 11:08:36 GMT
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 <graeme@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
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message