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

Tue Aug 23 03:34:47 PDT 2022

Hi all,

I have also missed Friday's meeting, but I tend to agree with Russ - can't see the need for two DBs.

To me the RF/SF block in Michael's deck should be the data backend of the resource inventory service that we see depicted in the Fabric Management box. In the end they are all redfish objects and therefore I expect them to belong to one resource tree. Swordfish is an extension to RedFish and I believe (not an expert by any mean, so please correct me) that RF objects can be part of the same DB as regular RF ones. On the API side I would expect that the OFMF exposes a regular RF API as well as the SF one (do we need a SF service as parto of the OFMF?).

In the main diagram I would separate the OFMF part of the figure into Services and Data Storage, see pic below.

[cid:0ca92968-693e-4ff9-a4d8-d9dfad5a65fc]

The part where we need to do some more thinking is the Composability layer and align our definitions of composability. RF defines a composability API and specific objects <https://www.dmtf.org/sites/default/files/Redfish_School-Composability_2017_0.pdf> (ResourceBlocks - RB) for supporting composition of systems. In this schema, Composability is merely the creation of a new computer system out of a collection of RBs. In my view RB objects should be part of the OFMF RF DB and be advertised/created by Agents (pic above). Agents work in tandem with FMs and have the knowledge about what components can be composed.
The composability Layer/Managers might keep their own representation (DB) of the composable resources for bookkeeping, implementing policies, etc. This DB would be separated from the OFMF one and not necessarily storing objects in their original RF representation.
If we want the composability layer to incorporate functionalities from FAM managers and alike, then we would probably need to extend RedFish Composability . e.g., clients request the creation of a new system with some memory related requirements (latency). The composability layer could decide to serve part of this memory from a FAM chunk that it created and exposed as a RB. As of today, this is not possible with RedFish composability as there is no way of specifying a FAM MemoryType and to include performance/QoS related constraints in composition requests. FAM is just an example I am using here.

I am happy to discuss this further on Friday.

Christian

Christian Pinto, Ph.D.
Research Scientist
IBM Research Europe - Ireland
________________________________
From: Ofmfwg <ofmfwg-bounces at lists.openfabrics.org> on behalf of Herrell, Russ W (Senior System Architect) <russ.herrell at hpe.com>
Sent: Monday 22 August 2022 23:59
To: Aguilar, Michael J. <mjaguil at sandia.gov>; ofmfwg at lists.openfabrics.org <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: [EXTERNAL] Re: [Ofmfwg] 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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:image002.png at 01D8B63E.1514EC70]

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:

[cid:image005.png at 01D8B640.24F0E980]

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; 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: [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/ac435a59/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 412 bytes
Desc: image001.gif
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/ac435a59/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 229395 bytes
Desc: image002.png
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/ac435a59/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 49178 bytes
Desc: image005.png
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/ac435a59/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 206623 bytes
Desc: image.png
URL: <http://lists.openfabrics.org/pipermail/ofmfwg/attachments/20220823/ac435a59/attachment-0005.png>