Open Stack

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

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

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.

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141020/8bc14118/attachment.pgp>