<p dir="ltr"><br>
Le 20 oct. 2014 20:13, "Dan Smith" <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> a écrit :<br>
><br>
> > OK, so in reviewing Dan B's patch series that refactors the virt<br>
> > driver's get_available_resource() method [1], I am stuck between two<br>
> > concerns. I like (love even) much of the refactoring work involved in<br>
> > Dan's patches. They replace a whole bunch of our nested dicts that are<br>
> > used in the resource tracker with real objects -- and this is something<br>
> > I've been harping on for months that really hinders developer's<br>
> > understanding of Nova's internals.<br>
><br>
> dict['line1'] = 'Agreed, this is extremely important stuff.'<br>
> dict['line2'] = 'The current dict mess that we have there is '<br>
> dict['line3'] = 'really obscure and confusing.'<br>
> reply = jsonutils.dumps(dict)<br>
><br>
> > However, all of the object classes that Dan B has introduced have been<br>
> > unversioned objects -- i.e. they have not derived from<br>
> > nova.objects.base.NovaObject. This means that these objects cannot be<br>
> > sent over the wire via an RPC API call. In practical terms, this issue<br>
> > has not yet reared its head, because the resource tracker still sends a<br>
> > dictified JSON representation of the object's fields directly over the<br>
> > wire, in the same format as Icehouse, therefore there have been no<br>
> > breakages in RPC API compatibility.<br>
><br>
> Right, so the blueprint for this work states that it's not to be sent<br>
> over the RPC wire or stored in the database. However, it already is in<br>
> some cases (at least the ComputeNode object has the unversioned<br>
> JSONified version of some of these hardware models in it).<br>
><br>
> If the modeling is purely for internal-to-compute-node purposes, then<br>
> it's all good. However, it surely seems like with the pending scheduler<br>
> isolation work, we're in a spot where we are building two parallel model<br>
> hierarchies, and I'm not really sure why.<br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr">Here, the virt-to-RT interface has to be objectified, hence Dan's work.<br>
On the other end of the RT, the RT-to-scheduler interface has to be objectified, hence Jay and mine's work.<br>
I hope we will provide a clear big picture and a  roadmap for the Summit so we could give you more insights.</p>
<p dir="ltr">> > My proposal is that before we go and approve any BPs or patches that add<br>
> > to nova/virt/hardware.py, we first put together a patch series that<br>
> > moves the object models in nova/virt/hardware.py to being full-fledged<br>
> > objects in nova/objects/*<br>
><br>
> I'm not sure that just converting them all to NovaObjects is really<br>
> necessary here. If it's all stuff that is going to go over the wire<br>
> eventually as part of the resource tracker's expansion, then probably<br>
> so. If there are bits of the model that only serve to let the resource<br>
> tracker do its calculations, then perhaps it doesn't make sense to<br>
> require those be NovaObjects.<br>
></p>
<p dir="ltr">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.<br>
We just need to objectify the interface to explicitetly provide what kind of resources are sent but that's it.</p>
<p dir="ltr">> Regardless, it sounds like we need some discussion on how best to<br>
> proceed here. Since it's entirely wrapped up in the scheduler work, we<br>
> should definitely try to make sure that what we're doing here fits with<br>
> those plans. Last I heard, we weren't sure where we were going to draw<br>
> the line between nova bits and scheduler bits, so erring on the side of<br>
> "more versioned interfaces" seems safest to me.<br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr">-Sylvain</p>
<p dir="ltr">> --Dan<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
></p>