Open Stack

Le 20 oct. 2014 20:13, "Dan Smith" <dms at danplanet.com> a écrit :
>
> > OK, so in reviewing Dan B's patch series that refactors the virt
> > driver's get_available_resource() method [1], I am stuck between two
> > concerns. I like (love even) much of the refactoring work involved in
> > Dan's patches. They replace a whole bunch of our nested dicts that are
> > used in the resource tracker with real objects -- and this is something
> > I've been harping on for months that really hinders developer's
> > understanding of Nova's internals.
>
> dict['line1'] = 'Agreed, this is extremely important stuff.'
> dict['line2'] = 'The current dict mess that we have there is '
> dict['line3'] = 'really obscure and confusing.'
> reply = jsonutils.dumps(dict)
>
> > However, all of the object classes that Dan B has introduced have been
> > unversioned objects -- i.e. they have not derived from
> > nova.objects.base.NovaObject. This means that these objects cannot be
> > sent over the wire via an RPC API call. In practical terms, this issue
> > has not yet reared its head, because the resource tracker still sends a
> > dictified JSON representation of the object's fields directly over the
> > wire, in the same format as Icehouse, therefore there have been no
> > breakages in RPC API compatibility.
>
> Right, so the blueprint for this work states that it's not to be sent
> over the RPC wire or stored in the database. However, it already is in
> some cases (at least the ComputeNode object has the unversioned
> JSONified version of some of these hardware models in it).
>
> If the modeling is purely for internal-to-compute-node purposes, then
> it's all good. However, it surely seems like with the pending scheduler
> isolation work, we're in a spot where we are building two parallel model
> hierarchies, and I'm not really sure why.
>

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.

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.
I hope we will provide a clear big picture and a  roadmap for the Summit so
we could give you more insights.

> > My proposal is that before we go and approve any BPs or patches that add
> > to nova/virt/hardware.py, we first put together a patch series that
> > moves the object models in nova/virt/hardware.py to being full-fledged
> > objects in nova/objects/*
>
> I'm not sure that just converting them all to NovaObjects is really
> necessary here. If it's all stuff that is going to go over the wire
> eventually as part of the resource tracker's expansion, then probably
> so. If there are bits of the model that only serve to let the resource
> tracker do its calculations, then perhaps it doesn't make sense to
> require those be NovaObjects.
>

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.
We just need to objectify the interface to explicitetly provide what kind
of resources are sent but that's it.

> Regardless, it sounds like we need some discussion on how best to
> proceed here. Since it's entirely wrapped up in the scheduler work, we
> should definitely try to make sure that what we're doing here fits with
> those plans. Last I heard, we weren't sure where we were going to draw
> the line between nova bits and scheduler bits, so erring on the side of
> "more versioned interfaces" seems safest to me.
>

Again, we hope to give you all a better understanding at the Summit. I
can't develop further as I'm in vacation until next Wed so I totally assume
my last paragraph as an horrible teaser unless someone else from the gang
adds more details.

-Sylvain

> --Dan
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/7cf0a8ca/attachment.html>