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" <berra...@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 :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev