> 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
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev