Open Stack

On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
> On Thu, 4 Sep 2014 11:24:29 +0100
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> > 
> >  - A fairly significant amount of nova code would need to be
> >    considered semi-stable API. Certainly everything under nova/virt
> >    and any object which is passed in/out of the virt driver API.
> >    Changes to such APIs would have to be done in a backwards
> >    compatible manner, since it is no longer possible to lock-step
> >    change all the virt driver impls. In some ways I think this would
> >    be a good thing as it will encourage people to put more thought
> >    into the long term maintainability of nova internal code instead
> >    of relying on being able to rip it apart later, at will.
> > 
> >  - The nova/virt/driver.py class would need to be much better
> >    specified. All parameters / return values which are opaque dicts
> >    must be replaced with objects + attributes. Completion of the
> >    objectification work is mandatory, so there is cleaner separation
> >    between virt driver impls & the rest of Nova.
> 
> I think for this to work well with multiple repositories and drivers
> having different priorities over implementing changes in the API it
> would not just need to be semi-stable, but stable with versioning built
> in from the start to allow for backwards incompatible changes. And
> the interface would have to be very well documented including things
> such as what exceptions are allowed to be raised through the API.
> Hopefully this would be enforced through code as well. But as long as
> driver maintainers are willing to commit to this extra overhead I can
> see it working. 

With our primary REST or RPC APIs we're under quite strict rules about
what we can & can't change - almost impossible to remove an existing
API from the REST API for example. With the internal virt driver API
we would probably have a little more freedom. For example, I think
if we found an existing virt driver API that was insufficient for a
new bit of work, we could add a new API in parallel with it, give the
virt drivers 1 dev cycle to convert, and then permanently delete the
original virt driver API. So a combination of that kind of API
replacement,  versioning for some data structures/objects, and use of
the capabilties flags would probably be sufficient. That's what I mean
by semi-stable here - no need to maintain existing virt driver APIs
indefinitely - we can remove & replace them in reasonably short time
scales as long as we avoid any lock-step updates.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|