[Ovirt-devel] [RFC] Beginnings of a OVirt API

[David Lutterkort]

Here are a few patches that implement the beginnings of an API for
OVirt. They cover handling hosts and storage and hardware pools so
far. This patch is mostly meant for discussion, since there's still a few
things that need to be tweaked.

If you're only interested in seeing how the API is used, jump straight to
patch 5/5; it contains all the client side (example) code. To see what gets
sent across the wire, you can request stuff like /ovirt/hosts or
/ovirt/hardware_pools?path=/default/foo/bar in your browser and admire the
XML.

In doing this, it became apparent that there are various things in the
existing OVirt server code that need to be adapted to better accomodate the
API:

  * Enable simple HTTP authentication

    It should be possible for people to run scripts without hooking the
    client into the krb5 infrastructure; instead, scripts should be able to
    use simple username/password authentication.

  * Fold the Rest:: controllers into the main controllers

    Once we have non-krb5 authn, the controllers I wrote to support the API
    should be folded into the controllers that drive the WUI. There's some
    annoying duplication of code right now, and having just one controller
    for each aspect of the API/WUI would eliminate that.

    I don't think there's a need to have 'base' controllers with separate
    subclasses for WUI and API - for the most part, WUI and API just differ
    in how the results are rendered, and should be able to have exactly the
    same logic to load/manipulate model objects. But as with anything, the
    devil will be in the details.

    One sideeffect of this would be that the API is accessible under
    /ovirt, and not /ovirt/rest as is the case with these patches.

  * Rename some of the WUI controllers

    The REST support (ActionController::Resources) is pretty specific about
    the names of controllers; for example, hardware pools in the API are
    served by a HardwarePoolsController, not a HardwareController as in the
    WUI. It's possible to work around that, but ultimately easiest if we
    just follow the preferred naming conventions of Rails.

  * Reconcile some of the differences in parameter naming

    With REST, the names of attributes in objects maps directly to
    parameter names in certain requests, and the naming in the WUI
    sometimes differs from that. For example, when creating a hardware
    pool, the WUI sends parameters for that in params[:pool], whereas the
    API sends it in params[:hardware_pool]

    Again, this can be overcome on a case-by-case basis, but it's easiest
    if the WUI uses the naming conventions preferred by the Rails' REST
    support.

  * Too many attributes are dumped into the XML

    I haven't tried to prune the attributes that are sent across the wire
    for each object to a reasonable subset. For example, right now
    attributes of very questionable use to an API user, like updated_at,
    lock_version, lft, rgt etc. are all sent.

  * Where's the CLI ?

    I intended to accompany this with a nice clean CLI client that you can
    use for lots of things. Even with the current subset of the API, there
    are lots of interesting queries and actions one could perform, even
    with the current subset of the API. I'd like to avoid offering a
    million options from the CLI though. If anybody has pressing needs for
    CLI functionality, let me know, otherwise, I'll start making stuff up.

    Especially for querying, it's questionable if CLI access to query
    functionality is useful at all - if you want to see all the hosts in
    hardware pool 7, you can just

      wget http://management.priv.ovirt.org:3000/ovirt/rest/hardware_pools/7/hosts

    and get a nice XML document.

    Is there a need for a CLI client for interactive use that lets you
    avoid using a browser ? Not sure how important that is.