From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=google.com (client-ip=2a00:1450:4864:20::130; helo=mail-lf1-x130.google.com; envelope-from=rhanley@google.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="v5jd86oV"; dkim-atps=neutral Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47SP9M2G9BzDqSs for ; Wed, 4 Dec 2019 14:15:02 +1100 (AEDT) Received: by mail-lf1-x130.google.com with SMTP id v201so4807795lfa.11 for ; Tue, 03 Dec 2019 19:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dFc4bJKrv0Ye40BUw6crMwPU9uykYUqy1JJetWCrPAY=; b=v5jd86oVKOIUwUemnqLokVx00qYRsLZZ78MFD+KE39iUbzRVivjL2sy3HPcZNRhOfZ tWAG+l9ExjEZ6qjb6gDQDmCcBDQMuSaLgH5rUV7DP2TsJQ/j8VgvVXdAXWd1wMrfY2Rn nevcASXWw7Z24M25A64AGPYtJqjvAAxk/UMZ7kgDoPD/xRuFAZntADN0LHg9FWAAYRgf 6kb+bBBwcH2Zr0xinVIMeswkyAGT/T5agyKJrjrpaLMBBQUFC8ptquf/mstyGEddsBqs B72uWcungmL3/Cuj6scEjac2kNrJpAR6cd/CW5R9D9pSL3VesIvtgQAF2OVki8Zlrz82 H9HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dFc4bJKrv0Ye40BUw6crMwPU9uykYUqy1JJetWCrPAY=; b=a4TGGt8/vN8IiEzTl0ZMcBG1bFQYGqa06Ote+wq7o5fmry50JTOVOz+RFIYYTlgJV6 zqn75OUjX69HdNKljopSll9J1RB4hpA9awMvWpcS9Ki3p82YaO/nuCi7gZRcwiooXSGx vXlVK2jUbBahz+mU2DqTU7mkJg1k4bXGrXI1Ogr1yRYUUPCEuXIZu/DEAZQJBVE/MzP0 eOBwNaV8kpcqHqmMDQj+OI1yJcoFmKBc4Hyo3RsTKLp4Bw3ohRoLK+7xnY3/TN18zkjW +muSAZmHP0B5GFe+3qTifvbyTKfGvWPrR1y8BJS7SmMEsArzZZ4lxt3VnjVOakNwvO4p HeUQ== X-Gm-Message-State: APjAAAWz0rhqJC1fvNGhy3u9R0bQxzErSNzCc6c0HKts109hsECUL+9f PBJ3FrzRhiyPebI5Dt1u1RycJoo0L3iSsuk5GRMv3eGJ6zM= X-Google-Smtp-Source: APXvYqy/Sb4Vhw7RzJ1BINzvlSm72t7JyUrp9TsknQHj4oYTQ64+/ENJeidIriz8Anl+ziPntbS6gjYsJuar5vVG5j4= X-Received: by 2002:a19:8104:: with SMTP id c4mr637166lfd.191.1575429297517; Tue, 03 Dec 2019 19:14:57 -0800 (PST) MIME-Version: 1.0 From: Richard Hanley Date: Tue, 3 Dec 2019 19:14:46 -0800 Message-ID: Subject: Inserting a Redfish Aggregator To: OpenBMC Maillist Content-Type: multipart/alternative; boundary="000000000000a609db0598d8378c" X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 03:15:04 -0000 --000000000000a609db0598d8378c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I=E2=80=99ve been thinking a bit about how to separate Redfish logic from D= Bus in bmcweb. As a motivating example, imagine a Redfish aggregator that has some chassis that is located outside of its local instance. Once the aggregator finds the external chassis, it needs to add it to the chassis collection. However, looking at the current implementation of the ChassisCollection.(located here: https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#= L246) It isn=E2=80=99t clear to me how to add this in. The current implementation does some setup on the response payload, and then makes a DBus call to look through the entity manager. The collection it sends as a response is entirely defined by the result from the entity manager. I basically see three ways that this could be solved. 1. Move the aggregator logic down to the entity manager 2. Refactor the Chassis Collection to have its own data model separate from the entity manager. 3. Create some service that works on top of the bmcweb implementation of Redfish. I think this comes up to a fundamental design decision, how modular/flexible should the Redfish implementation be? Right now bmcweb provides a very sane default implementation, and is tied very closely to the current hardware it is running on. Whereas I am envisioning a Redfish implementation that is a bit more abstracted from any particular hardware. It=E2=80=99s taken me awhile to get up to speed with Redfish, Open BMC, and Google=E2=80=99s infrastructure; but I=E2=80=99m starting to get a more con= crete design for an aggregator. However, I=E2=80=99m unsure about whether this should be fr= amed as a new layer on top of the existing implementation, or as a refactor of that implementation? I can see some pros and cons between the two, but I=E2=80=99m interested in= how everyone feels about this. Regards, Richard --000000000000a609db0598d8378c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,


I= =E2=80=99ve been thinking a bit about how to separate Redfish logic from DB= us in bmcweb.


As a motivating example, imagine a Redfish aggregat= or that has some chassis that is located outside of its local instance.=C2=A0 Once the aggregator f= inds the external chassis, it needs to add it to the chassis collection.


However, looking at the current implementation of t= he ChassisCollection.(located here: https://github.com/openbmc/bmcweb/blob/m= aster/redfish-core/lib/chassis.hpp#L246) It isn=E2=80=99t clear = to me how to add this in.


The current implementation does some setup on the r= esponse payload, and then makes a DBus call to look through the entity mana= ger.=C2=A0 The collectio= n it sends as a response is entirely defined by the result from the entity = manager. I basically see three ways that this could be solved.


  1. Move the aggregator logic down to the entity mana= ger
  2. Refactor the Chassis Collection to have its own d= ata model separate from the entity manager.
  3. Create some service that works on top of the bmcw= eb implementation of Redfish.


I think this comes up to a fundamental design decis= ion, how modular/flexible should the Redfish implementation be?=C2=A0 Right now bmcweb provides a = very sane default implementation, and is tied very closely to the current h= ardware it is running on.=C2=A0= Whereas I am envisioning a Redfish implementation that is a bit mor= e abstracted from any particular hardware.


It=E2=80=99s taken me awhile to get up to speed wit= h Redfish, Open BMC, and Google=E2=80=99s infrastructure; but I=E2=80=99m s= tarting to get a more concrete design for an aggregator.=C2=A0 However, I=E2=80=99m unsure about wh= ether this should be framed as a new layer on top of the existing implement= ation, or as a refactor of that implementation?


I can see some pros and cons between the two, but I= =E2=80=99m interested in how everyone feels about this.


Regards,

<= p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-v= ariant-east-asian:normal;font-stretch:normal;line-height:normal">Richard

--000000000000a609db0598d8378c--