Open Stack

On Fri, Sep 05, 2014 at 12:40:59PM +0200, Nikola Đipanov wrote:
> On 09/04/2014 12:24 PM, Daniel P. Berrange 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.
> > 
> 
> I think we should not underestimate how big of a job this will be. We
> have been treating that API as internal for a long time and a lot of
> abstractions are just broken and need to be redesigned and then
> refactored. A lot of the stuff is implementation specific (live
> migrations is a good example of this). What makes it more difficult is
> that we need to get this as right as possible before we do the split.
> 
> Now I am not saying this cannot be done or that we shouldn't to it,
> however I _am_ saying that we should not take lightly how much work
> there will be and how fiddly the work itself is.
> 
> On top of that - there are some other serious issues with nova common
> code that we need to take care of ASAP, and this will definitely
> increase the churn and make that more difficult. We should take this
> into account and make sure we are focusing efforts on the right things.
> Making sure we do is the biggest challenge nova core faces in addition
> to all the others mentioned above.
> 
> >  - 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.
> > 
> 
> Not only that - currently nova-objects do their versioning magic only
> over RPC, while they would have to do it over library boundaries. This
> in itself will require work, and is likely going to influence how we
> stabilize the API.
> 
> However - splitting out the scheduler is likely to require objects to be
> able to do similar things, and there are other things that we may want
> to do (e.g. using properly versioned data for the extensible resources)
> that will benefit from this.

Looking at what we did for the NUMA work, the objects we have returned
from the nova/virt/driver.py APIs (as defined in hardware.py) are
separate from the versioned objects we use for persisting the data in
the datbase (as defined nova/objects/numa_topology.py). So in this
case the nova-objects versioning problem doesn't leak into the virt
drivers. If solving the versioning problemm over library boundaries
isn't workable, then perhaps the separate of objects is what we should
look at. ie, the version objects be purely an internal thing for nova
common to deal with and objects to be consumed by the virt drivers are
defined by the virt driver API itself.

> >  - If changes are required to common code, the virt driver developer
> >    would first have to get the necccessary pieces merged into Nova
> >    common. Then the follow up virt driver specific changes could be
> >    proposed to their repo. This implies that some changes to virt
> >    drivers will still contend for resource in the common nova repo 
> >    and team. This contention should be lower than it is today though
> >    since the current nova core team should have less code to look 
> >    after per-person on aggregate.
> > 
> 
> A handy example of this I can think of is the currently granted FFE for
> serial consoles - consider how much of the code went into the common
> part vs. the libvirt specific part, I would say the ratio is very close
> to 1 if not even in favour of the common part (current 4 outstanding
> patches are all for core, and out of the 5 merged - only one of them was
> purely libvirt specific, assuming virt/ will live in nova-common).
> 
> Joe asked a similar question elsewhere on the thread.

In terms of patches merged to Nova, 1385 merged in 6 months, of which
437 (30%) touched /virt/ files. This obviously doesn't distinguish
between virt driver changes that we 100% isolated inside the virt
driver from changes that touch multiple code areas.

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 :|