* Saggi Mizrahi <smizr...@redhat.com> [2012-06-18 10:05]:
> I would like to put on to the table for descussion the growing need for a way
> to more easily reuse of the functionality of VDSM in order to service projects
> other than Ovirt-Engine.
> Originally VDSM was created as a proprietary agent for the sole purpose of
> serving the then proprietary version of what is known as ovirt-engine. Red 
> Hat,
> after acquiring the technology, pressed on with it's commitment to open source
> ideals and released the code. But just releasing code into the wild doesn't
> build a community or makes a project successful. Further more when building
> open source software you should aspire to build reusable components instead of
> monolithic stacks.


Thanks for sending this out.  I've been trying to pull together some
thoughts on what else is needed for vdsm as a community.  I know that
for some time downstream has been the driving force for all of the work
and now with a community there are challenges in finding our own way.

While we certainly don't want to make downstream efforts harder, I think
we need to develop and support our own vision for what vdsm can be come,
some what independent of downstream and other exploiters.

Revisiting the API is definitely a much needed endeavor and I think
adding some use-cases or sample applications would be useful in
demonstrating whether or not we're evolving the API into something
easier to use for applications beyond engine.
> We would like to expose a stable, documented, well supported API. This gives
> us a chance to rethink the VDSM API from the ground up. There is already work
> in progress of making the internal logic of VDSM separate enough from the API
> layer so we could continue feature development and bug fixing while designing
> the API of the future.
> In order to achieve this though we need to do several things:
>    1. Declare API supportability guidelines
>    2. Decide on an API transport (e.g. REST, ZMQ, AMQP)
>    3. Make the API easily consumable (e.g. proper docs, example code, 
> extending
>       the API, etc)
>    4. Implement the API itself

I agree with the list, but I'd like to work on the redesign discussion so
that we're not doing all of 1-4 around the existing API that's

I'm over due for posting a feature page on vdsm standalone mode, and I
have some other thoughts on various uses.

Some other paths of thought for use-cases I've been mulling over:

    - Simplifying using QEMU/KVM
        - consuming qemu via command line
            - can we manage/support developers launching qemu directly
        - consuming qemu via libvirt
            - can we integrate with systems that are already using

    - Addressing issues with libvirt
        - are there kvm specific features we can exploit that libvirt
    - Scale-up/fail-over
        - can we support a single vdsm node, but allow for building up
        clusters/groups without bringing in something like ovirt-engine
        - can we look at decentralized fail-over for reliability without
        a central mgmt server?

    - pluggability
        - can we support an API that allows for third-party plugins to 
        support new features or changes in implementation?

    - kvm tool integration into the API
        - there are lots of different kvm virt tools for various tasks 
        and they are all stand-alone tools.  Can we integrate their 
        use into the node level API.  Think libguestfs, virt-install,
        p2v/v2v tooling.  All of these are available, but there isn't an
        easy way to use this tools through an API.

    - host management operations
        - vdsm already does some host level configuration (see
              networking e.g.) it would be good to think about extending
        the API to cover other areas of configuration and updates
            - hardware enumeration
            - driver level information
            - storage configuration
                (we've got a bit of a discussion going around
                 libstoragemgmt here)

    - performance monitoring/debugging
        - is the host collecting enough information to do debug/perf
        - can we support specific configurations of a host that optimize
        for specific workloads
            - and can we do this in the API such that third-parties can
            supply and maintain specific workload configurations

> All of these are dependent on one another and the permutations are endless.
> This is why I think we should try and work on each one separately. All
> discussions will be done openly on the mailing list and until the final 
> version
> comes out nothing is set in stone.
> If you think you have anything to contribute to this process, please do so
> either by commenting on the discussions or by sending code/docs/whatever
> patches. Once the API solidifies it will be quite difficult to change
> fundamental things, so speak now or forever hold your peace. Note that this is
> just an introductory email. There will be a quick follow up email to kick 
> start
> the discussions.

> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx

vdsm-devel mailing list

Reply via email to