DriverVendorPassthru and VendorPassThru are inconsistent

I would also like to see default implementations for driver_vendor_passthru and vendor_passthru in the base class, because now they're nearly identical in all drivers. Ideally the driver would only set routing dict's for both in __init__.py just like it does now.

+1 I'm working on that, having a basic mechanism for routing methods in the base class

Fix proposed to branch: master
Review: https://review.openstack.org/129261

Fix proposed to branch: master
Review: https://review.openstack.org/129662

Fix proposed to branch: master
Review: https://review.openstack.org/129942

Reviewed: https://review.openstack.org/129261
Committed: https://git.openstack.org/cgit/openstack/ironic/commit/?id=b5a531aa4d1e8c5e0056d7aeceda467423009e55
Submitter: Jenkins
Branch: master

commit b5a531aa4d1e8c5e0056d7aeceda467423009e55
Author: Lucas Alvares Gomes <email address hidden>
Date: Wed Oct 29 11:38:44 2014 +0000

    Add a mechanism to route vendor methods

    Each vendor class had to implement a custom method
    to invoke their own vendor functionalities, the commit
    e129faef1762b8335b226298554ed83204c2696a added a decorator @passthru()
    to decorate those vendor methods and guarantee that the errors and
    exceptions are being handled accordingly. This patch is extending that
    decorator to add some metadata to each vendor method and from that be
    able to generically build a way to invoke those without requiring vendor
    drivers to implement a custom method for that.

    The vendor_passthru() and driver_vendor_passthru() methods were removed
    from the VendorInterface base class. Now vendors that wants to implement
    a vendor method should now only care about implementing the method itself
    and decorating them with the @passthru() or @driver_passthru decorator.

    This patch also adds a backward compatibility layer for existing drivers
    out of the tree that may be using the old [driver_]vendor_passthru()
    methods. If the vendor class contains those methods we are going to
    call them just like before, otherwise we are going to use the new
    mechanism. All drivers in tree have been ported to the new mechanism.

    Implements: blueprint extended-vendor-passthru
    Partial-Bug: #1382457
    Change-Id: I7770ccd9668d9c03e02f769aff7c54b33734a770

Reviewed: https://review.openstack.org/129662
Committed: https://git.openstack.org/cgit/openstack/ironic/commit/?id=bc97388931e8722eeef7a379e61ec2e31be01441
Submitter: Jenkins
Branch: master

commit bc97388931e8722eeef7a379e61ec2e31be01441
Author: Lucas Alvares Gomes <email address hidden>
Date: Fri Oct 31 13:54:51 2014 +0000

    Add sync and async support for passthru methods

    This patch extend the @passthru and @driver_passthru decorators to
    add support to vendor to determine whether their methods should run
    synchronously or asynchronously.

    A new flag "async" was added to the decorators, if True (the default)
    run the method asynchronously if False synchronously.

    The RPC methods vendor_passthru() and driver_vendor_passthru() return
    values were updated to also return the mode that the vendor method was
    invoked. This is needed because the API should return a different HTTP
    code depending on the mode, which is 202 (Accepted) for async and 200
    (OK) for sync.

    Before the driver_vendor_passthru() was always synchronously and the
    vendor_passthru() asynchronously, this patch makes things more consistent
    by supporting both modes on both endpoints.

    Partial-Bug: #1382457
    Implements: blueprint extended-vendor-passthru
    Change-Id: I6e7f6c61e9933cba7411d4e9acca9dd8720e9bfe

Reviewed: https://review.openstack.org/129942
Committed: https://git.openstack.org/cgit/openstack/ironic/commit/?id=e03f443b1fb8db08ca3192c54bcb016ad7ac606d
Submitter: Jenkins
Branch: master

commit e03f443b1fb8db08ca3192c54bcb016ad7ac606d
Author: Lucas Alvares Gomes <email address hidden>
Date: Fri Oct 31 16:53:43 2014 +0000

    Vendor endpoints to support different HTTP methods

    This patch extend the VendorPassthru and DriverVendorPasshtru endpoints
    to support to any HTTP method.

    When creating a new vendor function developers can specify which are the
    HTTP methods supported by each vendor function as a list, if the method
    request is not in the list Ironic will return a InvalidParameterValue
    (HTTP 400, Bad Request), otherwise the method will be invoked and the HTTP
    method request will be available to the vendor function as a parameters
    in kwargs called 'http_method'.

    Partial-Bug: #1382457
    Implements: blueprint extended-vendor-passthru
    Change-Id: I01d9d7fdd7eaf9849db41d50fbb4a78fd31bbfdc

I believe this was fixed already as part of the https://review.openstack.org/#/c/134066/ so closing it