[Ofmfwg] OFMFWG---Latest update-to-date OFMF diagram

Tue Aug 23 09:41:22 PDT 2022

This ‘composability layer’ is also not part of OFMF… it is a set of tools that manipulate the Redfish (& Swordfish) objects presented by the OFMF Restful interface.
I agree we need to define what’s in this layer, but in my view of the OFMF, this layer is filled with clients of the OFMF.

Russ

[hpesm_pri_grn_pos_rgb]

Russ  Herrell
Distinguished Technologist | Hewlett Packard Labs | System Architecture Lab
Hewlett Packard Enterprise | russ.herrell at hpe.com<mailto:russ.herrell at hpe.com> | Mobile: +1 970 420 1707
“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

From: Aguilar, Michael J. [mailto:mjaguil at sandia.gov]
Sent: Tuesday, August 23, 2022 9:51 AM
To: Herrell, Russ W (Senior System Architect) <russ.herrell at hpe.com>; ofmfwg at lists.openfabrics.org; Cayton, Phil <phil.cayton at intel.com>; Ahlvers, Richelle <richelle.ahlvers at intel.com>; Jim Hull <jmhull at intelliprop.com>; Sandur, Atul <Atul.Sandur at amd.com>; Blagodurov, Sergey <Sergey.Blagodurov at amd.com>
Cc: Michele Gazzetti1 <Michele.Gazzetti1 at ibm.com>
Subject: Re: [EXTERNAL] RE: OFMFWG---Latest update-to-date OFMF diagram

Russ

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.

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.

Mike

From: "Herrell, Russ W (Senior System Architect)" <russ.herrell at hpe.com<mailto:russ.herrell at hpe.com>>
Date: Monday, August 22, 2022 at 4:01 PM
To: "Aguilar, Michael J." <mjaguil at sandia.gov<mailto:mjaguil at sandia.gov>>, "ofmfwg at lists.openfabrics.org<mailto:ofmfwg at lists.openfabrics.org>" <ofmfwg at lists.openfabrics.org<mailto:ofmfwg at lists.openfabrics.org>>, "Cayton, Phil" <phil.cayton at intel.com<mailto:phil.cayton at intel.com>>, "Ahlvers, Richelle" <richelle.ahlvers at intel.com<mailto:richelle.ahlvers at intel.com>>, Jim Hull <jmhull at intelliprop.com<mailto:jmhull at intelliprop.com>>, "Sandur, Atul" <Atul.Sandur at amd.com<mailto:Atul.Sandur at amd.com>>, "Blagodurov, Sergey" <Sergey.Blagodurov at amd.com<mailto:Sergey.Blagodurov at amd.com>>
Cc: Michele Gazzetti1 <Michele.Gazzetti1 at ibm.com<mailto:Michele.Gazzetti1 at ibm.com>>
Subject: [EXTERNAL] RE: OFMFWG---Latest update-to-date OFMF diagram

Sorry I was un-available last Friday.

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.

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

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:

[cid:image004.png at 01D8B6DC.72674320]

However, my vision has all Redfish objects part of the OFMF Redfish tree….

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:

I can adjust my thinking to the above….
But I don’t see a need for two ‘databases’, from a functional point of view.
(Perhaps the problem is the Swordfish services code cannot be merged easily with the Redfish services code?  Maybe that’s Richelle’s point?)

Russ

[hpesm_pri_grn_pos_rgb]

Russ  Herrell
Distinguished Technologist | Hewlett Packard Labs | System Architecture Lab
Hewlett Packard Enterprise | russ.herrell at hpe.com<mailto:russ.herrell at hpe.com> | Mobile: +1 970 420 1707
“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

From: Ofmfwg [mailto:ofmfwg-bounces at lists.openfabrics.org] On Behalf Of Aguilar, Michael J.
Sent: Monday, August 22, 2022 1:58 PM
To: ofmfwg at lists.openfabrics.org<mailto:ofmfwg at lists.openfabrics.org>; Cayton, Phil <phil.cayton at intel.com<mailto:phil.cayton at intel.com>>; Ahlvers, Richelle <richelle.ahlvers at intel.com<mailto:richelle.ahlvers at intel.com>>; Jim Hull <jmhull at intelliprop.com<mailto:jmhull at intelliprop.com>>; Sandur, Atul <Atul.Sandur at amd.com<mailto:Atul.Sandur at amd.com>>; Blagodurov, Sergey <Sergey.Blagodurov at amd.com<mailto:Sergey.Blagodurov at amd.com>>
Cc: Michele Gazzetti1 <Michele.Gazzetti1 at ibm.com<mailto:Michele.Gazzetti1 at ibm.com>>
Subject: [Ofmfwg] OFMFWG---Latest update-to-date OFMF diagram

Everyone

We have a new version of an abstract look at the OFMF to look at.

After the meetings on Wednesday and Friday morning, we have:

1)      Separated out some of the memory structures and resource information into a separate Redfish/Swordfish database.
2)      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.
3)      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.
4)      The resources are controlled by the Redfish/Swordfish database and the connections are controlled by the OFMF.

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.

Please, feel free to edit and we’ll continue to meet and hash out the diagram.  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.  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.

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.

Slide 1:  Our current diagram after Friday
Slide 2:  Left side clients and the Composability Layer
Slide 3:  The old diagram, pre-Wednesday and pre-Friday

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/7b89d2dd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 412 bytes
Desc: image003.gif
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/7b89d2dd/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 229396 bytes
Desc: image004.png
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/7b89d2dd/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.gif
Type: image/gif
Size: 413 bytes
Desc: image005.gif
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/7b89d2dd/attachment-0003.gif>