Open Stack

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

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

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

--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/20141021/f65b834c/attachment.pgp>