<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I spent a little time trying to work out a good way to include this kind of data in the ComputeNode object. You will have seen that I added the supported_instances
reported to the RT by the virt drivers as a list of HVSpec – where HVSpec is a new nova object I created for the purpose.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">>> The rationale behind two parallel data model hiercharies is that the<br>
>> format the virt drivers report data in, is not likely to be exactly<br>
>> the same as the format that the resoure tracker / scheduler wishes to<br>
>> use in the database.<br>
<br>
>Yeah, and in cases where we know where that line is, it makes sense to<br>
>use the lighter-weight modeling for sure.<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Something that happens in some cases in RT is the data reported by the virt driver is modified by the RT – this is certainly the case for stats (which should
probably not have been used by the virt driver – ironic in this case). In other cases memory, cpu, disk etc are split out into other fields at the moment (which is where Jay Pipes is working on a model for resources in general).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Where the data in an object field is not simple (e.g. lists of something) it is not really easy to work with in an object. You can’t just add to a list that
is already stored in an object field, you need to make sure the object knows it has been updated. So the easiest way to work is to add entire fields to the object and not change them in situ. So that seems to me like dealing with non-nova object data types
makes sense as something separate to, say, the ComputeNode object.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">An alternative would be to work on the way nova object handle nested data structures (i.e. recognizing updates in nested structures, api allowing for list manipulation
etc.) It depends whether you think the objects are just doing versioning to support upgrade/mixed versions or are a general purpose object model.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Note that this happens with NUMA data structures and PCI as well at the moment.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">>> FWIW, my patch series is logically split up into two parts. THe first<br>
>> 10 or so patches are just thought of as general cleanup and useful to<br>
>> Nova regardless of what we decide todo. The second 10 or so patches<br>
>> are where the objects start appearing & getting used & the controversial<br>
>> bits needing mor detailed discussion.<br>
<br>
>Right, so after some discussion I think we should go ahead and merge the<br>
>bottom of this set (all of them are now acked I think) and continue the<br>
>discussion on the top half where the modeling is introduced.<br>
<br>
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Paul<o:p></o:p></span></p>
</div>
</body>
</html>