* Storing host data on the BMC @ 2020-05-04 14:52 Sunitha Harish 2020-05-04 15:56 ` Deepak Kodihalli 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-04 14:52 UTC (permalink / raw) To: patrick, dkodihal, suryakanth.sekar, openbmc [-- Attachment #1: Type: text/plain, Size: 2926 bytes --] Hi, We have some user defined host settings which we are presently keeping it in phosphor-settings-manager and the associated pldm bios attributes are there in the pldm BIOS table. Few properties in the object hosted by the phosphor-settings-manager are read-only for out of band but through in-band it can be changed. For example; the IP origin (static/dhcp) in the below commit. https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/ UseCase: The redfish client will set the hypervisor IP address via bmcweb. This will be taken to the hypervisor via pldm. Once the system is powered on, the hypervisor will apply the IP address to its Ethernet Interface. Properties like IPAddress, SubnetMask, Gateway are having one to one mapping in the PLDM BIOS attr table and Dbus object properties, Now concern here is on the Origin property which PLDM reads as sensor from Hypervisor. We have two views on this scenario. View 1: These are not suitable to be stored in the existing phopsphor-settings-manager since these are not the writable out-of-band user settings. View 2: These sensors can be part of this settings table, can be considered as a read-only attribute for the out-of-band access. These can be writable to the host. I understand that there are some efforts going on by Intel to come up with internal Bios settings table but this problem is agnostic to whether we keep the data in settings Dbus object or in the new app which is array of key-value pairs. Below are the two solutions which i can think of: ------------------------------------------------------------- 1. Let there be an attribute in the existing BIOS attribute table (Settings Storage), which will be settable from the hypervisor through PLDM, however pldm reads it as a sensor.This setting will be read-only for the out-of-band clients(redfish). This approach is something similar to the redfish schema, where we implement the writable & read-only attributes in the same schema/resource. Redfish also has the origin as a settings but they made it as a read-only attribute. This helps in bringing the related attributes together under same object. 2. Let create a new table/object for mapping of pldm sensors ; the Sensors Storage table which will contain only those attributes which are mapped to the pldm sensors. This sensor table can be set by the pldm, and other interested components can read this to get the required attribute values. If we do this, then openBMC would be having two tables 1) Settings Storage for Bios settings 2) Sensors Storage for pldm sensors. It is kind of bringing the pldm complexities to the external application. Also complexities involved in bringing the related attributes together from two different tables. Please let me know your views on these. What could be the better long term solution for this? It would be great if you can propose any other way of handling this. Thanks & regards, Sunitha [-- Attachment #2: Type: text/html, Size: 3163 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-04 14:52 Storing host data on the BMC Sunitha Harish @ 2020-05-04 15:56 ` Deepak Kodihalli 2020-05-05 6:42 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Deepak Kodihalli @ 2020-05-04 15:56 UTC (permalink / raw) To: Sunitha Harish, patrick, dkodihal, suryakanth.sekar, openbmc On 04/05/20 8:22 pm, Sunitha Harish wrote: > Hi, > > We have some user defined host settings which we are presently keeping > it in phosphor-settings-manager and the associated pldm bios attributes > are there in the pldm BIOS table. Few properties in the object hosted by > the phosphor-settings-manager are read-only for out of band but through > in-band it can be changed. > > For example; the IP origin (static/dhcp) in the below commit. > https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/ Is the Origin property here a host setting/BIOS attribute? I don't believe it is. From a PLDM perspective, this is a sensor that the host can update and notify the BMC via an event, for eg. Even if you make it read-only, it is not a setting for the host firmware - which is what BIOS attributes are meant for. Thanks, Deepak ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-04 15:56 ` Deepak Kodihalli @ 2020-05-05 6:42 ` Sunitha Harish 2020-05-05 6:59 ` Deepak Kodihalli 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-05 6:42 UTC (permalink / raw) To: Deepak Kodihalli, patrick, dkodihal, suryakanth.sekar, openbmc 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. I am looking for the opinion on the two approaches proposed ; so that we can handle these kind of scenarios. Thanks & regards, Sunitha On 04-05-2020 21:26, Deepak Kodihalli wrote: > On 04/05/20 8:22 pm, Sunitha Harish wrote: >> Hi, >> >> We have some user defined host settings which we are presently >> keeping it in phosphor-settings-manager and the associated pldm bios >> attributes are there in the pldm BIOS table. Few properties in the >> object hosted by the phosphor-settings-manager are read-only for out >> of band but through in-band it can be changed. >> >> For example; the IP origin (static/dhcp) in the below commit. >> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/ > > Is the Origin property here a host setting/BIOS attribute? I don't > believe it is. From a PLDM perspective, this is a sensor that the host > can update and notify the BMC via an event, for eg. Even if you make > it read-only, it is not a setting for the host firmware - which is > what BIOS attributes are meant for. > > Thanks, > Deepak ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-05 6:42 ` Sunitha Harish @ 2020-05-05 6:59 ` Deepak Kodihalli 2020-05-06 7:23 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Deepak Kodihalli @ 2020-05-05 6:59 UTC (permalink / raw) To: Sunitha Harish, patrick, dkodihal, suryakanth.sekar, openbmc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-05 6:59 ` Deepak Kodihalli @ 2020-05-06 7:23 ` Sunitha Harish 2020-05-11 6:14 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-06 7:23 UTC (permalink / raw) To: Deepak Kodihalli, patrick, dkodihal, suryakanth.sekar, openbmc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-06 7:23 ` Sunitha Harish @ 2020-05-11 6:14 ` Sunitha Harish 2020-05-11 12:07 ` Patrick Williams 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-11 6:14 UTC (permalink / raw) To: Deepak Kodihalli, patrick, dkodihal, suryakanth.sekar, openbmc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-11 6:14 ` Sunitha Harish @ 2020-05-11 12:07 ` Patrick Williams 2020-05-11 16:05 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Patrick Williams @ 2020-05-11 12:07 UTC (permalink / raw) To: Sunitha Harish; +Cc: Deepak Kodihalli, dkodihal, suryakanth.sekar, openbmc [-- Attachment #1: Type: text/plain, Size: 2558 bytes --] 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 -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-11 12:07 ` Patrick Williams @ 2020-05-11 16:05 ` Sunitha Harish 2020-05-13 15:07 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-11 16:05 UTC (permalink / raw) To: Patrick Williams; +Cc: Deepak Kodihalli, dkodihal, suryakanth.sekar, openbmc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-11 16:05 ` Sunitha Harish @ 2020-05-13 15:07 ` Sunitha Harish 2020-05-13 15:27 ` Deepak Kodihalli 2020-05-13 21:18 ` Patrick Williams 0 siblings, 2 replies; 21+ messages in thread From: Sunitha Harish @ 2020-05-13 15:07 UTC (permalink / raw) To: Patrick Williams; +Cc: Deepak Kodihalli, dkodihal, suryakanth.sekar, openbmc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-13 15:07 ` Sunitha Harish @ 2020-05-13 15:27 ` Deepak Kodihalli 2020-05-13 21:18 ` Patrick Williams 1 sibling, 0 replies; 21+ messages in thread From: Deepak Kodihalli @ 2020-05-13 15:27 UTC (permalink / raw) To: Sunitha Harish, Patrick Williams; +Cc: suryakanth.sekar, openbmc On 13/05/20 8:37 pm, Sunitha Harish wrote: > 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. Makes sense. > 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. Agree. > My question&proposal is about how/where to store this value? Anywhere but the BIOS attributes store on D-Bus? For eg could you come up with another D-Bus interface to house this property? The PLDM demon can relay a PLDM sensor to a D-Bus object that implements this property. There are other PLDM sensors that the host owns, that are already handled this way today - the host updates a PLDM sensor and lets the BMC know about it. The BMC can update a corresponding D-Bus property. > Thanks & regards, > Sunitha ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-13 15:07 ` Sunitha Harish 2020-05-13 15:27 ` Deepak Kodihalli @ 2020-05-13 21:18 ` Patrick Williams 2020-05-14 3:43 ` Deepak Kodihalli 1 sibling, 1 reply; 21+ messages in thread From: Patrick Williams @ 2020-05-13 21:18 UTC (permalink / raw) To: Sunitha Harish; +Cc: Deepak Kodihalli, dkodihal, suryakanth.sekar, openbmc [-- Attachment #1: Type: text/plain, Size: 2623 bytes --] On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote: > My scenario is : > 1. Redfish client sets the host interface parameters for the IPv4 > address. These user settable values are stored in the DBus. Ignoring which process "stores" this data, we have two mechanisms over DBus to store this kind of data. I can't tell fully from your explaination which is more appropriate for this data. 1. Data we want to split out into well-formed, existing dbus objects. * We already have interfaces to store networking information under xyz/openbmc_project/Network. 2. Data which is generic / opaque to the BMC and we're just using the BMC as a "storage location". * This would be the proposed BIOS attributes interface. So the question to you is, do you want the BMC to actively interact with and manage this data, like we do for our own data, or do you want the BMC to just be a dumb passthru of this data? > 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. It doesn't seem like two steps matter with respect to the 1/2 above. Where the data is obtained in this regard can be self-contained in your PLDM provider, correct? > 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". This description makes it seem like you want it to be more "managed" data than "opaque", if I'm reading this correctly. > 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? I think we need to be careful about being hung up on the name "BIOS table". For opaque data that is more OS-centric, we could make the proposed "BIOS Attributes" interface more generic to store different levels of host-owned data: BIOS, Hypervisor, OS. This might be a good comment to make on the interface code review. If you are wanting the data to be managed, utilizing existing DBus interfaces we have around networking, doesn't phosphor-settingsd cover that from an implementation perspective? -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-13 21:18 ` Patrick Williams @ 2020-05-14 3:43 ` Deepak Kodihalli 2020-05-14 12:33 ` Patrick Williams 0 siblings, 1 reply; 21+ messages in thread From: Deepak Kodihalli @ 2020-05-14 3:43 UTC (permalink / raw) To: Patrick Williams, Sunitha Harish; +Cc: dkodihal, suryakanth.sekar, openbmc On 14/05/20 2:48 am, Patrick Williams wrote: > On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote: >> My scenario is : >> 1. Redfish client sets the host interface parameters for the IPv4 >> address. These user settable values are stored in the DBus. > > Ignoring which process "stores" this data, we have two mechanisms over > DBus to store this kind of data. I can't tell fully from your > explaination which is more appropriate for this data. > > 1. Data we want to split out into well-formed, existing dbus objects. > > * We already have interfaces to store networking information under > xyz/openbmc_project/Network. > > 2. Data which is generic / opaque to the BMC and we're just using the > BMC as a "storage location". > > * This would be the proposed BIOS attributes interface. > > So the question to you is, do you want the BMC to actively interact with > and manage this data, like we do for our own data, or do you want the > BMC to just be a dumb passthru of this data? > >> 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. > > It doesn't seem like two steps matter with respect to the 1/2 above. > Where the data is obtained in this regard can be self-contained in your > PLDM provider, correct? > >> 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". > > This description makes it seem like you want it to be more "managed" > data than "opaque", if I'm reading this correctly. > >> 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? > > I think we need to be careful about being hung up on the name "BIOS > table". For opaque data that is more OS-centric, we could make the > proposed "BIOS Attributes" interface more generic to store different > levels of host-owned data: BIOS, Hypervisor, OS. This might be a good > comment to make on the interface code review. I think the current proposal from Surya enables this already. Do you just mean the design doc should explicitly state this isn't restricted to the "BIOS" firmware. As far as Sunitha's question goes, my point is that not all host firmware generated data is a BIOS attribute. For eg if the host tells me about the presence of certain FRUs, or their functional states, I wouldn't want to store those in the BIOS attributes backend, I'd rather associates those with the existing D-Bus interfaces for the FRU inventory. I think the same applies to the Origin property that has been described - associate with the networking D-Bus backend. > If you are wanting the data to be managed, utilizing existing DBus > interfaces we have around networking, doesn't phosphor-settingsd cover > that from an implementation perspective? I don't think the 'Origin' property is a setting. Regards, Deepak ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-14 3:43 ` Deepak Kodihalli @ 2020-05-14 12:33 ` Patrick Williams 2020-05-18 11:53 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Patrick Williams @ 2020-05-14 12:33 UTC (permalink / raw) To: Deepak Kodihalli; +Cc: Sunitha Harish, dkodihal, suryakanth.sekar, openbmc [-- Attachment #1: Type: text/plain, Size: 2064 bytes --] On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote: > On 14/05/20 2:48 am, Patrick Williams wrote: > > On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote: > I think the current proposal from Surya enables this already. Do you > just mean the design doc should explicitly state this isn't restricted > to the "BIOS" firmware. Yep. > As far as Sunitha's question goes, my point is that not all host > firmware generated data is a BIOS attribute. For eg if the host tells me > about the presence of certain FRUs, or their functional states, I > wouldn't want to store those in the BIOS attributes backend, I'd rather > associates those with the existing D-Bus interfaces for the FRU > inventory. I think the same applies to the Origin property that has been > described - associate with the networking D-Bus backend. I think we're in agreement here. Data which is interesting to represent on the BMC, for which we already have a defined-interface, use it. For data which isn't interesting the to BMC, use the generic BIOS attribute table. > > If you are wanting the data to be managed, utilizing existing DBus > > interfaces we have around networking, doesn't phosphor-settingsd cover > > that from an implementation perspective? > > I don't think the 'Origin' property is a setting. Well the name "settingsd" is somewhat arbitrary based on its original definition. I believe the current implementation can make a placeholder instance of any dbus interface. Having said that, one weakness with settingsd is that you can't easily restrict property changes to data coming from the host. Once you make a settingsd object, anyone can make dbus calls to change properties on it. If we want to be able to restrict that to specific interfaces, we might want to look at a phosphor-inventory-manager like implementation which has a special "backdoor" method to create / update the instances but prevents modification through the normal property change interfaces. -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-14 12:33 ` Patrick Williams @ 2020-05-18 11:53 ` Sunitha Harish 2020-05-21 5:12 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-18 11:53 UTC (permalink / raw) To: Patrick Williams, Deepak Kodihalli; +Cc: dkodihal, suryakanth.sekar, openbmc Thanks Deepak & Patrick. So the preferred approach would be to define the host settable data in a new phosphor-host-inventory-manager, and make this as read-only to the other BMC applications. The Interface: xyz.openbmc_project.Network.EthernetInterface - DHCPEnabled property is a Bios attribute. https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ Lets take a scenario - when the Ethernet interface set to be DHCP enabled ( by setting the DHCPEnabled = true via redfish), the IPAddress, SubnetMask and Gateway along with the Origin property will not be BIOS one as all they can't be settable by the redfish in the case of DHCP and they will be part of this new manager. However in the case of Static IP configuration(IPAddress, SubnetMask and Gateway) will become bios setting. Would we be having these attributes in both Bios table and in the new settings manager ? By considering all these , can you please weigh in your thoughts about extending the existing settings interface table, by defining the attribute as read-only for BMC ? We can block the "write" to these attributes at user level. This would make things simpler , and it will be in line with the redfish interface definitions as well. Redfish already defines the schema where it makes some attributes read-only for the users. Thanks & regards, Sunitha On 14-05-2020 18:03, Patrick Williams wrote: > On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote: >> On 14/05/20 2:48 am, Patrick Williams wrote: >>> On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote: > >> I think the current proposal from Surya enables this already. Do you >> just mean the design doc should explicitly state this isn't restricted >> to the "BIOS" firmware. > Yep. > >> As far as Sunitha's question goes, my point is that not all host >> firmware generated data is a BIOS attribute. For eg if the host tells me >> about the presence of certain FRUs, or their functional states, I >> wouldn't want to store those in the BIOS attributes backend, I'd rather >> associates those with the existing D-Bus interfaces for the FRU >> inventory. I think the same applies to the Origin property that has been >> described - associate with the networking D-Bus backend. > I think we're in agreement here. Data which is interesting to represent > on the BMC, for which we already have a defined-interface, use it. For > data which isn't interesting the to BMC, use the generic BIOS attribute > table. > >>> If you are wanting the data to be managed, utilizing existing DBus >>> interfaces we have around networking, doesn't phosphor-settingsd cover >>> that from an implementation perspective? >> I don't think the 'Origin' property is a setting. > Well the name "settingsd" is somewhat arbitrary based on its original > definition. I believe the current implementation can make a placeholder > instance of any dbus interface. > > Having said that, one weakness with settingsd is that you can't easily > restrict property changes to data coming from the host. Once you make a > settingsd object, anyone can make dbus calls to change properties on it. > If we want to be able to restrict that to specific interfaces, we might > want to look at a phosphor-inventory-manager like implementation which > has a special "backdoor" method to create / update the instances but > prevents modification through the normal property change interfaces. > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-18 11:53 ` Sunitha Harish @ 2020-05-21 5:12 ` Sunitha Harish 2020-05-21 5:16 ` Deepak Kodihalli 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-21 5:12 UTC (permalink / raw) To: Patrick Williams, Deepak Kodihalli; +Cc: dkodihal, suryakanth.sekar, openbmc Hi, Any inputs? Thanks & regards, Sunitha On 18-05-2020 17:23, Sunitha Harish wrote: > Thanks Deepak & Patrick. > > So the preferred approach would be to define the host settable data in > a new phosphor-host-inventory-manager, and make this as read-only to > the other BMC applications. > > The Interface: xyz.openbmc_project.Network.EthernetInterface - > DHCPEnabled property is a Bios attribute. > https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ > Lets take a scenario - when the Ethernet interface set to be DHCP > enabled ( by setting the DHCPEnabled = true via redfish), the > IPAddress, SubnetMask and Gateway along with the Origin property will > not be BIOS one as all they can't be settable by the redfish in the > case of DHCP and they will be part of this new manager. > > However in the case of Static IP configuration(IPAddress, SubnetMask > and Gateway) will become bios setting. > > Would we be having these attributes in both Bios table and in the new > settings manager ? > > By considering all these , can you please weigh in your thoughts about > extending the existing settings interface table, by defining the > attribute as read-only for BMC ? We can block the "write" to these > attributes at user level. This would make things simpler , and it will > be in line with the redfish interface definitions as well. Redfish > already defines the schema where it makes some attributes read-only > for the users. > > Thanks & regards, > Sunitha > > > On 14-05-2020 18:03, Patrick Williams wrote: >> On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote: >>> On 14/05/20 2:48 am, Patrick Williams wrote: >>>> On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote: >>> I think the current proposal from Surya enables this already. Do you >>> just mean the design doc should explicitly state this isn't restricted >>> to the "BIOS" firmware. >> Yep. >> >>> As far as Sunitha's question goes, my point is that not all host >>> firmware generated data is a BIOS attribute. For eg if the host >>> tells me >>> about the presence of certain FRUs, or their functional states, I >>> wouldn't want to store those in the BIOS attributes backend, I'd rather >>> associates those with the existing D-Bus interfaces for the FRU >>> inventory. I think the same applies to the Origin property that has >>> been >>> described - associate with the networking D-Bus backend. >> I think we're in agreement here. Data which is interesting to represent >> on the BMC, for which we already have a defined-interface, use it. For >> data which isn't interesting the to BMC, use the generic BIOS attribute >> table. >> >>>> If you are wanting the data to be managed, utilizing existing DBus >>>> interfaces we have around networking, doesn't phosphor-settingsd cover >>>> that from an implementation perspective? >>> I don't think the 'Origin' property is a setting. >> Well the name "settingsd" is somewhat arbitrary based on its original >> definition. I believe the current implementation can make a placeholder >> instance of any dbus interface. >> >> Having said that, one weakness with settingsd is that you can't easily >> restrict property changes to data coming from the host. Once you make a >> settingsd object, anyone can make dbus calls to change properties on it. >> If we want to be able to restrict that to specific interfaces, we might >> want to look at a phosphor-inventory-manager like implementation which >> has a special "backdoor" method to create / update the instances but >> prevents modification through the normal property change interfaces. >> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-21 5:12 ` Sunitha Harish @ 2020-05-21 5:16 ` Deepak Kodihalli 2020-05-21 10:30 ` Sunitha Harish 2020-05-22 3:59 ` Sunitha Harish 0 siblings, 2 replies; 21+ messages in thread From: Deepak Kodihalli @ 2020-05-21 5:16 UTC (permalink / raw) To: Sunitha Harish, Patrick Williams; +Cc: openbmc On 21/05/20 10:42 am, Sunitha Harish wrote: > Hi, > > Any inputs? > > Thanks & regards, > Sunitha Hi Sunitha, I believe you had got a direction based on the discussion below. >>>> As far as Sunitha's question goes, my point is that not all host >>>> firmware generated data is a BIOS attribute. For eg if the host >>>> tells me >>>> about the presence of certain FRUs, or their functional states, I >>>> wouldn't want to store those in the BIOS attributes backend, I'd rather >>>> associates those with the existing D-Bus interfaces for the FRU >>>> inventory. I think the same applies to the Origin property that has >>>> been >>>> described - associate with the networking D-Bus backend. >>> I think we're in agreement here. Data which is interesting to represent >>> on the BMC, for which we already have a defined-interface, use it. For >>> data which isn't interesting the to BMC, use the generic BIOS attribute >>> table. ^^ You use existing (or come up with new) D-Bus interfaces to represent your data. Those D-Bus interfaces can be implemented by settingsd or networkd or something else. Thanks, Deepak ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-21 5:16 ` Deepak Kodihalli @ 2020-05-21 10:30 ` Sunitha Harish 2020-05-22 3:59 ` Sunitha Harish 1 sibling, 0 replies; 21+ messages in thread From: Sunitha Harish @ 2020-05-21 10:30 UTC (permalink / raw) To: Deepak Kodihalli, Patrick Williams; +Cc: openbmc On 21-05-2020 10:46, Deepak Kodihalli wrote: > On 21/05/20 10:42 am, Sunitha Harish wrote: >> Hi, >> >> Any inputs? >> >> Thanks & regards, >> Sunitha > > Hi Sunitha, > > I believe you had got a direction based on the discussion below. > >>>>> As far as Sunitha's question goes, my point is that not all host >>>>> firmware generated data is a BIOS attribute. For eg if the host >>>>> tells me >>>>> about the presence of certain FRUs, or their functional states, I >>>>> wouldn't want to store those in the BIOS attributes backend, I'd >>>>> rather >>>>> associates those with the existing D-Bus interfaces for the FRU >>>>> inventory. I think the same applies to the Origin property that >>>>> has been >>>>> described - associate with the networking D-Bus backend. >>>> I think we're in agreement here. Data which is interesting to >>>> represent >>>> on the BMC, for which we already have a defined-interface, use it. >>>> For >>>> data which isn't interesting the to BMC, use the generic BIOS >>>> attribute >>>> table. > > ^^ You use existing (or come up with new) D-Bus interfaces to > represent your data. Those D-Bus interfaces can be implemented by > settingsd or networkd or something else. If i am getting it correctly , the current changes which were made to the phosphor-settings-manager should be good enough to handle all the scenarios. In my last email i mentioned that ===>> -------------------------------------------------------------------------------------------------------------------------- When the Ethernet interface set to be DHCP enabled ( by setting the Bios attribute DHCPEnabled = true via redfish), the IPAddress, SubnetMask and Gateway along with the Origin property will not be Bios settings. Here the user will be setting the DHCPEnabled property. However in the case of Static IP configuration(IPAddress, SubnetMask and Gateway) they will become bios setting. --------------------------------------------------------------------------------------------------------------------------- Currently we are using the xyz.openbmc_project.Network.IP and this interface is being implemented by settings object - https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ Do you see any issues here? > Thanks, > Deepak > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-21 5:16 ` Deepak Kodihalli 2020-05-21 10:30 ` Sunitha Harish @ 2020-05-22 3:59 ` Sunitha Harish 2020-05-29 10:57 ` Sunitha Harish 1 sibling, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-22 3:59 UTC (permalink / raw) To: Deepak Kodihalli, Patrick Williams; +Cc: openbmc On 21-05-2020 10:46, Deepak Kodihalli wrote: > On 21/05/20 10:42 am, Sunitha Harish wrote: >> Hi, >> >> Any inputs? >> >> Thanks & regards, >> Sunitha > > Hi Sunitha, > > I believe you had got a direction based on the discussion below. > >>>>> As far as Sunitha's question goes, my point is that not all host >>>>> firmware generated data is a BIOS attribute. For eg if the host >>>>> tells me >>>>> about the presence of certain FRUs, or their functional states, I >>>>> wouldn't want to store those in the BIOS attributes backend, I'd >>>>> rather >>>>> associates those with the existing D-Bus interfaces for the FRU >>>>> inventory. I think the same applies to the Origin property that >>>>> has been >>>>> described - associate with the networking D-Bus backend. >>>> I think we're in agreement here. Data which is interesting to >>>> represent >>>> on the BMC, for which we already have a defined-interface, use it. >>>> For >>>> data which isn't interesting the to BMC, use the generic BIOS >>>> attribute >>>> table. > > ^^ You use existing (or come up with new) D-Bus interfaces to > represent your data. Those D-Bus interfaces can be implemented by > settingsd or networkd or something else. If i am getting it correctly , the current changes which were made to the phosphor-settings-manager should be good enough to handle all the scenarios. In my last email i mentioned that ===>> -------------------------------------------------------------------------------------------------------------------------- When the Ethernet interface set to be DHCP enabled ( by setting the Bios attribute DHCPEnabled = true via redfish), the IPAddress, SubnetMask and Gateway along with the Origin property will not be Bios settings. Here the user setting is the DHCPEnabled property of ? However in the case of Static IP configuration(IPAddress, SubnetMask and Gateway) they will become bios setting. --------------------------------------------------------------------------------------------------------------------------- Currently we are using the xyz.openbmc_project.Network.IP and this interface is being implemented by settings object - https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ Do you see any issue here? > Thanks, > Deepak > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-22 3:59 ` Sunitha Harish @ 2020-05-29 10:57 ` Sunitha Harish 2020-05-29 11:03 ` Deepak Kodihalli 0 siblings, 1 reply; 21+ messages in thread From: Sunitha Harish @ 2020-05-29 10:57 UTC (permalink / raw) To: Deepak Kodihalli, Patrick Williams; +Cc: openbmc On 22-05-2020 09:29, Sunitha Harish wrote: > > On 21-05-2020 10:46, Deepak Kodihalli wrote: >> On 21/05/20 10:42 am, Sunitha Harish wrote: >>> Hi, >>> >>> Any inputs? >>> >>> Thanks & regards, >>> Sunitha >> >> Hi Sunitha, >> >> I believe you had got a direction based on the discussion below. >> >>>>>> As far as Sunitha's question goes, my point is that not all host >>>>>> firmware generated data is a BIOS attribute. For eg if the host >>>>>> tells me >>>>>> about the presence of certain FRUs, or their functional states, I >>>>>> wouldn't want to store those in the BIOS attributes backend, I'd >>>>>> rather >>>>>> associates those with the existing D-Bus interfaces for the FRU >>>>>> inventory. I think the same applies to the Origin property that >>>>>> has been >>>>>> described - associate with the networking D-Bus backend. >>>>> I think we're in agreement here. Data which is interesting to >>>>> represent >>>>> on the BMC, for which we already have a defined-interface, use >>>>> it. For >>>>> data which isn't interesting the to BMC, use the generic BIOS >>>>> attribute >>>>> table. >> >> ^^ You use existing (or come up with new) D-Bus interfaces to >> represent your data. Those D-Bus interfaces can be implemented by >> settingsd or networkd or something else. > > If i am getting it correctly , the current changes which were made to > the phosphor-settings-manager should be good enough to handle all the > scenarios. > > In my last email i mentioned that ===>> > -------------------------------------------------------------------------------------------------------------------------- > > When the Ethernet interface set to be DHCP enabled ( by setting the > Bios attribute DHCPEnabled = true via redfish), the IPAddress, > SubnetMask and Gateway along with the Origin property will not be Bios > settings. Here the user setting is the DHCPEnabled property of ? > > However in the case of Static IP configuration(IPAddress, SubnetMask > and Gateway) they will become bios setting. > --------------------------------------------------------------------------------------------------------------------------- > > Currently we are using the xyz.openbmc_project.Network.IP and this > interface is being implemented by settings object - > https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ > Do you see any issue here? Hi , any feedback ? Thanks & regards, Sunitha > >> Thanks, >> Deepak >> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-29 10:57 ` Sunitha Harish @ 2020-05-29 11:03 ` Deepak Kodihalli 2020-05-29 11:26 ` Sunitha Harish 0 siblings, 1 reply; 21+ messages in thread From: Deepak Kodihalli @ 2020-05-29 11:03 UTC (permalink / raw) To: Sunitha Harish, Patrick Williams; +Cc: openbmc On 29/05/20 4:27 pm, Sunitha Harish wrote: > > On 22-05-2020 09:29, Sunitha Harish wrote: >> >> On 21-05-2020 10:46, Deepak Kodihalli wrote: >>> On 21/05/20 10:42 am, Sunitha Harish wrote: >>>> Hi, >>>> >>>> Any inputs? >>>> >>>> Thanks & regards, >>>> Sunitha >>> >>> Hi Sunitha, >>> >>> I believe you had got a direction based on the discussion below. >>> >>>>>>> As far as Sunitha's question goes, my point is that not all host >>>>>>> firmware generated data is a BIOS attribute. For eg if the host >>>>>>> tells me >>>>>>> about the presence of certain FRUs, or their functional states, I >>>>>>> wouldn't want to store those in the BIOS attributes backend, I'd >>>>>>> rather >>>>>>> associates those with the existing D-Bus interfaces for the FRU >>>>>>> inventory. I think the same applies to the Origin property that >>>>>>> has been >>>>>>> described - associate with the networking D-Bus backend. >>>>>> I think we're in agreement here. Data which is interesting to >>>>>> represent >>>>>> on the BMC, for which we already have a defined-interface, use >>>>>> it. For >>>>>> data which isn't interesting the to BMC, use the generic BIOS >>>>>> attribute >>>>>> table. >>> >>> ^^ You use existing (or come up with new) D-Bus interfaces to >>> represent your data. Those D-Bus interfaces can be implemented by >>> settingsd or networkd or something else. >> >> If i am getting it correctly , the current changes which were made to >> the phosphor-settings-manager should be good enough to handle all the >> scenarios. >> >> In my last email i mentioned that ===>> >> -------------------------------------------------------------------------------------------------------------------------- >> >> When the Ethernet interface set to be DHCP enabled ( by setting the >> Bios attribute DHCPEnabled = true via redfish), the IPAddress, >> SubnetMask and Gateway along with the Origin property will not be Bios >> settings. Here the user setting is the DHCPEnabled property of ? >> >> However in the case of Static IP configuration(IPAddress, SubnetMask >> and Gateway) they will become bios setting. >> --------------------------------------------------------------------------------------------------------------------------- >> >> Currently we are using the xyz.openbmc_project.Network.IP and this >> interface is being implemented by settings object - >> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ >> Do you see any issue here? > > Hi , any feedback ? Sorry I forgot to respond to this. If your question is whether the Origin property (and the interface it lies in) can be implemented by phosphor-settingsd, then I think the answer is yes. We did say that we can look at phosphor-settingsd as an arbitrary data holder (not limited to user settings). > Thanks & regards, > Sunitha >> >>> Thanks, >>> Deepak >>> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storing host data on the BMC 2020-05-29 11:03 ` Deepak Kodihalli @ 2020-05-29 11:26 ` Sunitha Harish 0 siblings, 0 replies; 21+ messages in thread From: Sunitha Harish @ 2020-05-29 11:26 UTC (permalink / raw) To: Deepak Kodihalli, Patrick Williams; +Cc: openbmc On 29-05-2020 16:33, Deepak Kodihalli wrote: > On 29/05/20 4:27 pm, Sunitha Harish wrote: >> >> On 22-05-2020 09:29, Sunitha Harish wrote: >>> >>> On 21-05-2020 10:46, Deepak Kodihalli wrote: >>>> On 21/05/20 10:42 am, Sunitha Harish wrote: >>>>> Hi, >>>>> >>>>> Any inputs? >>>>> >>>>> Thanks & regards, >>>>> Sunitha >>>> >>>> Hi Sunitha, >>>> >>>> I believe you had got a direction based on the discussion below. >>>> >>>>>>>> As far as Sunitha's question goes, my point is that not all host >>>>>>>> firmware generated data is a BIOS attribute. For eg if the host >>>>>>>> tells me >>>>>>>> about the presence of certain FRUs, or their functional states, I >>>>>>>> wouldn't want to store those in the BIOS attributes backend, >>>>>>>> I'd rather >>>>>>>> associates those with the existing D-Bus interfaces for the FRU >>>>>>>> inventory. I think the same applies to the Origin property that >>>>>>>> has been >>>>>>>> described - associate with the networking D-Bus backend. >>>>>>> I think we're in agreement here. Data which is interesting to >>>>>>> represent >>>>>>> on the BMC, for which we already have a defined-interface, use >>>>>>> it. For >>>>>>> data which isn't interesting the to BMC, use the generic BIOS >>>>>>> attribute >>>>>>> table. >>>> >>>> ^^ You use existing (or come up with new) D-Bus interfaces to >>>> represent your data. Those D-Bus interfaces can be implemented by >>>> settingsd or networkd or something else. >>> >>> If i am getting it correctly , the current changes which were made >>> to the phosphor-settings-manager should be good enough to handle all >>> the scenarios. >>> >>> In my last email i mentioned that ===>> >>> -------------------------------------------------------------------------------------------------------------------------- >>> >>> When the Ethernet interface set to be DHCP enabled ( by setting the >>> Bios attribute DHCPEnabled = true via redfish), the IPAddress, >>> SubnetMask and Gateway along with the Origin property will not be >>> Bios settings. Here the user setting is the DHCPEnabled property of ? >>> >>> However in the case of Static IP configuration(IPAddress, SubnetMask >>> and Gateway) they will become bios setting. >>> --------------------------------------------------------------------------------------------------------------------------- >>> >>> Currently we are using the xyz.openbmc_project.Network.IP and this >>> interface is being implemented by settings object - >>> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ >>> Do you see any issue here? >> >> Hi , any feedback ? > > Sorry I forgot to respond to this. If your question is whether the > Origin property (and the interface it lies in) can be implemented by > phosphor-settingsd, then I think the answer is yes. We did say that we > can look at phosphor-settingsd as an arbitrary data holder (not > limited to user settings). Thanks Deepak , So I believe now we can go ahead with the current implementation in the gerrit links : https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/ https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/ Lets continue the review there for any further comments, and please provide your scores as well. > >> Thanks & regards, >> Sunitha >>> >>>> Thanks, >>>> Deepak >>>> > ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2020-05-29 11:27 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-04 14:52 Storing host data on the BMC Sunitha Harish 2020-05-04 15:56 ` Deepak Kodihalli 2020-05-05 6:42 ` Sunitha Harish 2020-05-05 6:59 ` Deepak Kodihalli 2020-05-06 7:23 ` Sunitha Harish 2020-05-11 6:14 ` Sunitha Harish 2020-05-11 12:07 ` Patrick Williams 2020-05-11 16:05 ` Sunitha Harish 2020-05-13 15:07 ` Sunitha Harish 2020-05-13 15:27 ` Deepak Kodihalli 2020-05-13 21:18 ` Patrick Williams 2020-05-14 3:43 ` Deepak Kodihalli 2020-05-14 12:33 ` Patrick Williams 2020-05-18 11:53 ` Sunitha Harish 2020-05-21 5:12 ` Sunitha Harish 2020-05-21 5:16 ` Deepak Kodihalli 2020-05-21 10:30 ` Sunitha Harish 2020-05-22 3:59 ` Sunitha Harish 2020-05-29 10:57 ` Sunitha Harish 2020-05-29 11:03 ` Deepak Kodihalli 2020-05-29 11:26 ` Sunitha Harish
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.