Open Stack

On Tue, Oct 21, 2014 at 08:46:10AM -0700, Dan Smith wrote:
> > As there are multiple interfaces using non versioned dicts and as we are
> > looking at reducing technical debt by Kilo, there are different
> > blueprints which can be worked in parallel.
> 
> I don't think I disagree with anything above, but I'm not sure what
> you're getting at. I think the parallelism we should avoid is building
> models that mirror things we need to send to a remote service and just
> require conversion. If we're modeling things between the virt driver and
> the RT (or interface to the RT) that get aggregated or transformed in
> some way before they leave the service, then that's fine.
> 
> > Here, the virt-to-RT interface has to be objectified, hence Dan's work.
> > On the other end of the RT, the RT-to-scheduler interface has to be
> > objectified, hence Jay and mine's work.
> 
> Right, but if the RT moves out of the compute service, then we'll need
> to be using versioned models, regardless of if it's RPC or REST or
> whatever. So *if* that's going to happen, building an unversioned object
> hierarchy that then necessarily has to be converted to another form
> might be work we don't need to do.

Yep, that's a bit I'm still pretty fuzzy on myself. I have been imaginging
that while the scheduler would split out of nova, the resource_tracker.py
code would still remain part of Nova because it is the bit that interfaces
with the nova virt driver API. We have historically always considered the
Nova virt driver API to be an internal only thing that we retain the right
to change at will so anything talking to it would be in-tree.

If the resource_tracker.py were to move out of Nova, then this now implies
that the get_available_resources() method in virt/driver.py is now defacto
stable API between Nova & the  schedulr project, that we have to preserve
compatibility for. If that is ineed the case then clearly using versioned
NovaObjects for that method's return value is going to be required. IMHO
though this is a not a desirable split of responsibility.


Personally  I was always expecting that resource_tracker.py would stay
part of Nova. It would use the internal get_available_resources()
API to talk to the virt driver, and transform the data it got back into
whatever format the external scheduler project wants to consume via some
formal API and these formats would likely be completely separate. In that
world view, there is no need for the get_available_resources() method to
use NovaObject.

> > I hope we will provide a clear big picture and a  roadmap for the Summit
> > so we could give you more insights.
> 
> Right, since that part is still not fully defined, it's hard to know the
> best course of action going forward. I'd hate to delay any of this work
> until after summit, but if you think that would be the most efficient, I
> guess it's only a couple weeks away.

As mentioned in my other mail, my 20 patch series is split into two real
pieces. The first 10 or so patches are just generall cleanup / prep work
that is hopefully fairly uncontroversial to consider merging. If the second
10 or so patches have to wait until after the summit, so be it, that's not
a big problem. Getting the code structure right is more important long term
than a fast merge.

> > Totally agreed. Here there is no need to version the interface as the
> > virt/Rt interface is not RPC based and purely internal to nova-compute.
> 
> Well, unless the RT is moved outside the compute node, which is (I
> think) what is being proposed, no?

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