Storing host data on the BMC
Sunitha Harish
sunithaharish04 at gmail.com
Thu May 14 01:07:32 AEST 2020
Hi Patrick/Surya,
Seems to me that the design which Intel proposed does not cover the
scenario which i was mentioning about.
My scenario is :
1. Redfish client sets the host interface parameters for the IPv4
address. These user settable values are stored in the DBus.
2. When the system is powered on , the pldm reads these DBus values ,
and sets the BIOS attributes.
3. The hypervisor reads this BIOS attributes for the interfaces and sets
them.
4. Now the hypervisor sends an indication to the pldm that the IP
address is active at its interface and its Origin is Static ( ie : user
configured) OR it is DHCP ( ie: not user configured, if its DHCP enabled)
5. The pldm should store this Origin value "somewhere".
Redfish client would need this value to interpret where the IP address
has been Originated from. So we need a DBus property to save it. But ,
this is actually an attribute which is set by the hypervisor/host - a
pldm sensor. Its not suitable to be fit into the BIOS table. My
question&proposal is about how/where to store this value?
Thanks & regards,
Sunitha
On 11-05-2020 21:35, Sunitha Harish wrote:
> Hi Patrick,
>
> Thanks for sharing the pointers. I was aware that there was work going
> on in this area. So was looking for your and Surya's inputs on this.
>
> I will go through these designs from my use-case perspective.
>
> Thanks & regards,
> Sunitha
>
>
> On 11-05-2020 17:37, Patrick Williams wrote:
>> Hello Sunitha,
>>
>> Intel has already made significant progress on this problem domain and
>> we seem to be fairly converged on the design direction [1,2]. Have you
>> read through their design proposal? Are there any oversights in their
>> design that would affect your needs?
>>
>> Their design has been on-going for months now. I don't think it is
>> appropriate to start from scratch on the design discussions unless there
>> is something fundamentally broken about their direction.
>>
>> 1. https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/29320
>> 2.
>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242
>>
>> I thought there was even some implementation started in bmcweb for this
>> feature.
>>
>> On Mon, May 11, 2020 at 11:44:35AM +0530, Sunitha Harish wrote:
>>> Hi,
>>>
>>> Gentle reminder for the feedback.
>>>
>>> Thanks & regards,
>>> Sunitha
>>>
>>> On 06-05-2020 12:53, Sunitha Harish wrote:
>>>> Hi Deepak,
>>>>
>>>> Please suggest which other approach you think is better here for
>>>> Origin attribute?
>>>>
>>>> When the interface is set as DHCPEnabled=true ; similar to the Origin
>>>> attribute , the IP address, SubnetMask and Gateway will be set by the
>>>> host. So we would need to consider this usecase also as a candidate
>>>> for the new approach.
>>>>
>>>> Thanks & regards,
>>>> Sunitha
>>>>
>>>>
>>>> On 05-05-2020 12:29, Deepak Kodihalli wrote:
>>>>> On 05/05/20 12:12 pm, Sunitha Harish wrote:
>>>>>> Hi Deepak,
>>>>>>
>>>>>> As mentioned , the Origin is the property which will be set by the
>>>>>> host once the IP address is applied to its interface. Its a
>>>>>> read-only property for the out-of-band user. But its a closely
>>>>>> coupled - related attribute on the host setting/BIOS object.
>>>>> Hi Sunitha,
>>>>>
>>>>> What I'm trying to say is - we shouldn't make this coupling. The BIOS
>>>>> settings table is a group of attributes that can alter the default
>>>>> behavior of the host firmware. The Origin property you describe
>>>>> doesn't fit that description.
>>>>>
>>>>> The host "sets" several things for the BMC, for eg the host firmware
>>>>> can tell us functional/presence states of FRUs which the host has
>>>>> access to. Everything that the host "sets" this way isn't a BIOS
>>>>> attribute. Once you decouple this, I believe we can think about
>>>>> options other than the two you have suggested - since both of them
>>>>> involve making the Origin property seem like a BIOS attribute, which
>>>>> it clearly is not.
>>>>>
>>>>> Thanks,
>>>>> Deepak
More information about the openbmc
mailing list