<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
@font-face
        {font-family:"Book Antiqua";
        panose-1:2 4 6 2 5 3 5 3 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:289363046;
        mso-list-type:hybrid;
        mso-list-template-ids:-500265494 1153040962 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Russ<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think it comes down to modularity and separation of concerns.  However, I am going to put to paper what maintaining 2 databases would look like versus having the OFMF be the maintainer for all of the data.  That would involve having the
 Composability Layer have a more structured meaning.  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I am starting on the left side with a set of clients.  With the clients set up, I think I can start to work out what a ‘Composability Layer’ looks like and then back to the middle, if that makes sense.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">"Herrell, Russ W (Senior System Architect)" <russ.herrell@hpe.com><br>
<b>Date: </b>Monday, August 22, 2022 at 4:01 PM<br>
<b>To: </b>"Aguilar, Michael J." <mjaguil@sandia.gov>, "ofmfwg@lists.openfabrics.org" <ofmfwg@lists.openfabrics.org>, "Cayton, Phil" <phil.cayton@intel.com>, "Ahlvers, Richelle" <richelle.ahlvers@intel.com>, Jim Hull <jmhull@intelliprop.com>, "Sandur, Atul"
 <Atul.Sandur@amd.com>, "Blagodurov, Sergey" <Sergey.Blagodurov@amd.com><br>
<b>Cc: </b>Michele Gazzetti1 <Michele.Gazzetti1@ibm.com><br>
<b>Subject: </b>[EXTERNAL] RE: OFMFWG---Latest update-to-date OFMF diagram<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D">Sorry I was un-available last Friday.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I had a similar clarifying viewpoint in mind, except the resource pool data base (my term for Redfish/Swordfish database) is part of the composability layer and the OFMF layer was the keeper of the Redfish description
 of all fabric inventory.  The ‘composability layer’ consists of FAM managers, NVMe managers, compute managers, etc, and they probably have their own bookkeeping DB for details that the OFMF Redfish tree doesn’t need to know.  But all HW settings and logical
 inventory assignments (ala memoryChunks and address zones) are also tracked in the ONE Redfish DB in the OFMF layer, so Kubernetes tools can interact with other vendor container managers indirectly through the OFMF layer. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I need someone to explain to me what is the difference in the OFM Database and the RF/SF Database, since I thought all objects and resources being tracked by the OFMF Services were represented as Redfish objects
 (or Swordfish objects that are essentially expanded Redfish schema and linked back to Redfish objects for physical representation) and there was only need for one database. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Quite frankly, I was thinking that Swordfish is the storage resource manager API.  As such, apps and tools that already use the Swordfish APIs just make their calls into the OFMF Redfish / Swordfish API of the
 OFMF.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The Swordfish API’s StorageService would sit immediately above the OFMF Redfish Service since the physical resources that make up the inventory for Swordfish Storage Pools are part of the fabric based resources
 tracked in the OFMF inventory.  Below is the SNIA diagram that leads me to think this way:
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><img width="866" height="400" style="width:9.0208in;height:4.1666in" id="Picture_x0020_2" src="cid:image001.png@01D8B6C7.79A84E50"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">However, my vision has all Redfish objects part of the OFMF Redfish tree….<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Maybe we should be looking at the OFMF layer as an aggregated RF/SF API that allows clients to manipulate storage, compute, fabric, and FAM resources from one ‘Service’ that operates from ONE Redfish/Swordfish
 database,  like so:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><img width="578" height="326" style="width:6.0208in;height:3.3958in" id="_x0000_i1026" src=""></span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I can adjust my thinking to the above…. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">But I don’t see a need for two ‘databases’, from a functional point of view.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">(Perhaps the problem is the Swordfish services code cannot be merged easily with the Redfish services code?  Maybe that’s Richelle’s point?)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Russ<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:blue"><img width="60" height="17" style="width:.625in;height:.177in" id="Picture_x0020_3" src="cid:image002.gif@01D8B6C7.79A84E50" alt="hpesm_pri_grn_pos_rgb"></span><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:4.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Russ  Herrell<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:black">Distinguished Technologist | Hewlett Packard Labs | System Architecture Lab
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:black">Hewlett Packard Enterprise |
<a href="mailto:russ.herrell@hpe.com">russ.herrell@hpe.com</a> | Mobile: +1 970 420 1707<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:5.0pt;margin-left:0in;text-autospace:none">
<span style="font-size:8.0pt;font-family:"Book Antiqua",serif;color:black">“The betterment of our society is not a job to be left to a few; it is a responsibility to be shared by all.”  -- Dave Packard<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> Ofmfwg [mailto:ofmfwg-bounces@lists.openfabrics.org]
<b>On Behalf Of </b>Aguilar, Michael J.<br>
<b>Sent:</b> Monday, August 22, 2022 1:58 PM<br>
<b>To:</b> ofmfwg@lists.openfabrics.org; Cayton, Phil <phil.cayton@intel.com>; Ahlvers, Richelle <richelle.ahlvers@intel.com>; Jim Hull <jmhull@intelliprop.com>; Sandur, Atul <Atul.Sandur@amd.com>; Blagodurov, Sergey <Sergey.Blagodurov@amd.com><br>
<b>Cc:</b> Michele Gazzetti1 <Michele.Gazzetti1@ibm.com><br>
<b>Subject:</b> [Ofmfwg] OFMFWG---Latest update-to-date OFMF diagram<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Everyone<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">We have a new version of an abstract look at the OFMF to look at. 
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">After the meetings on Wednesday and Friday morning, we have:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">     
</span></span><![endif]>Separated out some of the memory structures and resource information into a separate Redfish/Swordfish database.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">     
</span></span><![endif]>Added a ‘Composability Layer’ on the left side of the first slide.  The Composability Layer communicates to the OFMF and to the other Redfish/Swordfish database to gather and provide information to the OFMF (fabrics and fabric connections)
 and to the other database for resource control and management.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">     
</span></span><![endif]>The Gen-Z and CXL Agents communicate to the OFMF and to the other database to gather information, as they are capable of working with the end-point resources. 
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">4)<span style="font:7.0pt "Times New Roman"">     
</span></span><![endif]>The resources are controlled by the Redfish/Swordfish database and the connections are controlled by the OFMF.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">I think, it appears, that the Composability Manager, on the left, is the key part of what we were missing.  In the end, we want the functionality that Gen-Z and CXL provide through their Agents, but we want separation
 of concerns.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Please, feel free to edit and we’ll continue to meet and hash out the diagram. 
<b>Also, please feel free to respond to this email thread and submit changes, ahead of the meetings, to try to work out, edit, and ‘flesh’ out this diagram.</b>  It will be helpful to get some portions done before we meet.  We’ll consider this diagram a living
 document.  In addition, please tag on any Use-Case descriptions, UML, and flow diagrams that you want to test against the current OFMF diagrams, at any step.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Right now, I am trying to work out how the left side of the diagram looks and works for HPC clients.  That is slide 2.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Slide 1:  Our current diagram after Friday<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Slide 2:  Left side clients and the Composability Layer<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Slide 3:  The old diagram, pre-Wednesday and pre-Friday<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Mike<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</body>
</html>