[dashboard list] Add new endpoints + dog cmd for dashboard lists #252
Conversation
datadog/api/dashboard_lists.py
Outdated
| :returns: Dictionary representing the API's JSON response | ||
| """ | ||
| return super(DashboardList, cls)._trigger_class_action('GET', 'dashboards', id, params) | ||
|
|
There was a problem hiding this comment.
I think we should add a PUTmethod (.. PATCH ideally but it's better to be consistent with other api).
This would allow people to modify dashboards in a list in an atomic way, without callling delete first. It comes in handy when people have lists stored somewhere in source control and want to make sure Datadog resources are in sync with what they have.
datadog/api/hosts.py
Outdated
| @@ -8,7 +8,7 @@ class Host(ActionAPIResource): | |||
| _class_url = '/host' | |||
|
|
|||
| @classmethod | |||
| def mute(cls, host_name, **params): | |||
| def mute(cls, host_name, **body): | |||
datadog/dogshell/dashboard_list.py
Outdated
| report_warnings(res) | ||
| report_errors(res) | ||
|
|
||
| if args.string_ids: |
There was a problem hiding this comment.
I've chatted with @yannmh about this logic, it's definitely a legacy behavior, I think there is little benefit in adding more instances of it. Let's not include it.
I see it's used in timeboard screenboard monitor downtime, we can handle those separately.
There was a problem hiding this comment.
When moving from the dogapi to the datadogpy Python library, we forced all the resources to share the same interface, defined by the (Creatable|Updatable|..)APIResources classes for CRUD operations.
The result is a more homegeneous interface, i.e.
api.Dashboard.create(...)
api.Tag.create(...)
api.Graph.create(...)instead of something like (in dogapi)
api.create_dashboard(...)
api.add_tag_to_host(...)
api.make_snapshot(...)I feel like the DashboardList resource interface "breaks" with the current design by adding more CRUD methods on top of the standard (create|update|get|delete) ones. The result is a bit confusing:
api.DashboardList.get(...)
api.DashboardList.get_dashboards(...)I understand why it's made like that, as a single endpoint supports CRUD on two sets of resources, although I wonder if we can abstract that in the library client. For example, we could split the current DashboardList resource into two distinct resources: one for managing dashboard lists, the other for mapping dashboards to dashboard lists.
I don't have a clear solution to suggest. Instead I am happy to discuss this directly with you, to figure something out together.
| 'POST', | ||
| 'host/api/v1/actionname/{0}'.format(actionable_object_id), | ||
| data={'mydata': "val"} | ||
| ) |
datadog/api/resources.py
Outdated
| else: | ||
| return APIClient.submit(method, name + "/" + str(id), params) | ||
| return APIClient.submit(method, name + "/" + str(id), body) |
| resource_name=cls._resource_name, | ||
| resource_id=id | ||
| ) | ||
| return APIClient.submit('POST', path, body, attach_host_name=attach_host_name, **params) |
This PR adds the new API endpoints for managing dashboard lists:
Get all dashboard lists:
GET dashboard/lists/manualGet dashboard list:
GET dashboard/lists/manual/{dashboard_list_id}Create dashboard list:
POST dashboard/lists/manualUpdate dashboard list:
PUT dashboard/lists/manual/{dashboard_list_id}Delete dashboard list:
DELETE dashboard/lists/manual/{dashboard_list_id}Get dashboards for dashboard list:
GET dashboard/lists/manual/{dashboard_list_id}/dashboardsAdd dashboards to dashboard list:
POST dashboard/lists/manual/{dashboard_list_id}/dashboardsUpdate dashboards of dashboard list:
PUT dashboard/lists/manual/{dashboard_list_id}/dashboardsDelete dashboards from dashboard list:
DELETE dashboard/lists/manual/{dashboard_list_id}/dashboards