Open Stack

On 12/13/2016 8:43 PM, int32bit wrote:
> Hi, all. As we know, the "index()" method usually return object list and
> the "show()" method return an object for detail in api's controller. But
> I found in our InstanceUsageAuditLogController[1], the 'index' method
> return an object, I'm really not sure that index() is buggy, and I
> wonder what it is intended to do and what might be needed to fix it.
>
> Some discussion about this topic:
> https://review.openstack.org/#/c/409413/ .
>
> Thanks for your attention.
>
>
> [1]
> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/instance_usage_audit_log.py#L43
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

It's different but I'm not sure it's a bug, it's probably just a hacky 
way to override GET for different things, i.e. we have GET without the 
id parameter which is the index() implementation, and then we have the 
GET with the id parameter which is the show() implementation and also 
does some filtering (audit logs before the given timestamp). If 
anything, abusing the id parameter for GET is more of a bug as we aren't 
using it as a resource id to show details about a given resource, it's a 
timestamp filter.

Ideally we'd just have a single index() for GET with an optional 
'before' query parameter to toggle the behavior. Chris Dent (cdent in 
IRC) might have an opinion on this from the API working group point of view.

 From a pragmatic standpoint, I question how many deployments are 
actually leveraging this feature. It looks like it was originally added 
for Ceilometer but I wonder how many admins are really enabling it and 
using it for gathering audit data. By default it's disabled, and we 
don't test it anywhere in our CI system beyond unit tests. My point 
being, yeah this is gross, but how much do we really care about fixing 
this right now?

-- 

Thanks,

Matt Riedemann