If OpenHPI running on the Board/AMC does not know its Hardware Address then how do you match a resource on the Main OpenHPI instance with a resource on the subordinate OpenHPI instance? GUID? Serial Number?
-----Original Message----- From: Anton Pak [mailto:[email protected]] Sent: Wednesday, August 11, 2010 8:31 AM To: [email protected] Subject: Re: [Openhpi-devel] More on multi-domain configurations in real setups I doubt this. There may be the System Interface (IPMI based) between payload system and IPMC/MMC. And IPMC/MMC responds as 0x20 over this interface. Vendor-specific OEM mechanism may provide information about IPMB-0/IPMB-L hardware address. And even with knowledge about hardware address it is hard to determine a site type/site number for the slot. Anton Pak On Wed, 11 Aug 2010 15:57:42 +0400, Thompson, Michael <[email protected]> wrote: > Can I assume that OpenHPI running on the Board/AMC can determine it's > Hardware Address from the IPMC/MMC and therefore know what slot it is in? > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, August 11, 2010 4:39 AM > To: [email protected] > Subject: Re: [Openhpi-devel] More on multi-domain configurations in real > setups > > Uli, > > Thank you for feedback. > > My comments: > > 1) > > With Setup#4 all resources will be visible via domain on Main OpenHPI. > HPI application will not connect to subordinate OpenHPI instances > directly. > I guess it is on of the drawbacks on Setup#4. > > For the Setup#4 there will be following resources: > > OpenHPI on Board 1 Payload: > - Payload CPU - {CPU,1} > - Payload Disk - {DISK,1} > > OpenHPI on AMC: > - Payload CPU - {CPU,1} > - Payload Memory - {MEMORY,1} > > Main OpenHPI: > - Shelf - {CHASSIS,1} > - Board 1 - {CHASSIS,1}{PHYS_SLOT,1}{BOARD,1} > - Board 2 - {CHASSIS,1}{PHYS_SLOT,2}{BOARD,2} > - AMC on Board2 - {CHASSIS,1}{PHYS_SLOT,2}{BOARD,2}{AMC_SLOT,1}{AMC,1} > - resources collected from subordinate OpenHPIs > -- Payload CPU - {CHASSIS,1}{PHYS_SLOT,1}{BOARD,1}{CPU,1} > -- Payload Disk - {CHASSIS,1}{PHYS_SLOT,1}{BOARD,1}{DISK,1} > -- Payload CPU - > {CHASSIS,1}{PHYS_SLOT,2}{BOARD,2}{AMC_SLOT,1}{AMC,1}{CPU,1} > -- Payload Memory - > {CHASSIS,1}{PHYS_SLOT,2}{BOARD,2}{AMC_SLOT,1}{AMC,1}{MEMORY,1} > > I guess it is parent-child domain association. > As for peer domains HPI spec says: > > --------------- > Two domains, domain-A and domain-B, are "peers" if they are intended to > provide an HPI User with access to the same set of resources > --------------- > Because peer domains are intended to provide access to a common set of > resources, the same set of resources should be listed in the RPTs of both > domains. The RPTs in each of the peer domains are separate, and, in > particular, the RPT entries may be ordered differently in each peer > domain. However, the ResourceId, ResourceInfo, ResourceEntity, > ResourceCapabilities, and HotSwapCapabilities fields in the corresponding > RPT entries for a common resource must be identical in each peer domain. > Of these, the ResourceId field is guaranteed to be unique in each RPT > entry in a single domain. Therefore, RPT Entries corresponding to common > resources can be identified in peer domains by comparing the ResourceId > fields of RPT entries in the peer domains > -------------- > > I don't think we may use peer domains here. > What say? > > 2) Very good point! > And I suspect that 2 level hierarchy may be not enough for OpenHPI > domains. > Seems the final solution shall allow a tree setup of arbitrary depth. > > > Anton Pak > > >> Hi, >> great discussion! I am very happy this topic proceeds that way. >> >> I think, before we can evaluate the setups, I would like to throw >> two more inputs: >> >> 1. The idea of subsidiary OpenHPI instances in Setup #4 is very >> similar to what HPI defines for peer domains. I didn't dig into >> the peer domains deep enough yet, but as I understood them so far, >> a domain needs to show all resources of a peer and forward any >> commands related to those resources to the peer domain. >> >> 2. Additionally to the setups in the slideset, we need to consider >> configurations with multiple shelves (in xTCA, but similar in other >> architectures). Multiple shelves can be handled with a singe daemon >> or with a daemon per shelf. Dynamic reasons may lead to multiple >> daemons. >> >> Cheers, >> Uli >> >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: ext Thompson, Michael [mailto:[email protected]] >>> Gesendet: Dienstag, 10. August 2010 22:38 >>> An: [email protected] >>> Betreff: Re: [Openhpi-devel] More on multi-domain >>> configurations in real setups >>> >>> One blade that I have worked with supports upgrading through >>> the IPMB via the shelf manager. You can also load an IPMI >>> driver that connects to the KCS interface to the IPMC and >>> upgrade from the payload processor. It is very unlikely that >>> a user would try to do both at the same time. >>> >>> The new work in the HPM.x group will provide a mechanism for >>> the shelf manager to determine if an IPMC or MMC has the >>> ability of supporting an Ethernet connection for firmware upgrades. >>> >>> Maybe OpenHPI FUMIs could be enhanced to take advantage of >>> this new capability. Then an Upgrade Agent could make an >>> informed decision about which connection path would be best. >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> Sent: Tuesday, August 10, 2010 4:25 PM >>> To: [email protected] >>> Subject: Re: [Openhpi-devel] More on multi-domain >>> configurations in real setups >>> >>> Yes, the idea is that base library adds entity root to all >>> HPI resources and instruments from the domain. >>> So there is no need for subordinate OpenHPI to know its full >>> entity path. >>> Knowledge of the Board/AMC relative entity path is enough. >>> >>> As for the FUMIes my understanding of coordination is: >>> - entity pathes for two FUMIes should be the same >>> - if an upgrade is performed via the FUMI #1, then then FUMI #2 >>> should refuse upgrade actions or should indicate that >>> upgrade is currently undesirable. >>> I don't see any right generic way to resolve this problem. >>> By the way, how the board vendor copes with this problem >>> (providing more that one upgrade path)? >>> Seems it is not an HPI problem in nature. >>> >>> Anton Pak >>> >>> >>> > With Setup #3 would work nicely if the OpenHPI library provided a >>> > coordinated view of the multiple domains by matching the >>> HPI entity paths. >>> > >>> > How does the subordinate OpenHPI on a blade or module know >>> it's complete >>> > entity path? >>> > >>> > I think that you could have duplicate payload FUMIs. >>> Something like a >>> > payload BIOS could be upgraded through the IPMC and through >>> the payload >>> > processor. I have also seen boards where the IPMC firmware could be >>> > upgraded through the IPMB and from the payload processor. >>> > >>> > How would the OpenHPI library provide a coordinated view of >>> a single FUMI >>> > that has more than one upgrade path? >>> > >>> > -----Original Message----- >>> > From: [email protected] [mailto:[email protected]] >>> > Sent: Tuesday, August 10, 2010 3:28 PM >>> > To: [email protected] >>> > Subject: Re: [Openhpi-devel] More on multi-domain >>> configurations in real >>> > setups >>> > >>> > Michael, >>> > >>> > I am inclined to Setup #3 >>> > - There is no need for the main HPI domain to proxy all HPI traffic. >>> > (it may reduce the performance) >>> > - less code changes needed on the daemon/plug-in level >>> > - more generic code changes >>> > >>> > For Setup #4 there will be code duplication for each plug-in. >>> > Also we may miss Domain Alarm Table and Domain Event Log for >>> > subordinate OpenHPI. However I don't think it is a big trouble. >>> > >>> > As for the resources and instruments of the subordinate OpenHPI. >>> > I don't think there will be duplicates. >>> > My current thinking is that subordinate OpenHPI will provide >>> > payload-specific resources instruments. >>> > They are not visible on IPMI level now. >>> > But for coordination resources and instruments of >>> subordinate OpenHPI >>> > shall have HPI entity path containing the board HPI entity path. >>> > >>> > >>> > Anton Pak >>> > >>> >> I think that Setup #4 with a coordinated view of the >>> entities would be >>> >> the >>> >> easiest to manage. >>> >> >>> >> When a board/module with a Subordinate OpenHPI goes into >>> the M4 state >>> >> there may be duplicate paths to the same resources or >>> instruments. The >>> >> Main OpenHPI on the ShM should filter the duplicate resources and >>> >> instruments to avoid confusion. >>> >> >>> >> Duplicate resources and instruments on the Subordinate >>> OpenHPI may have >>> >> a >>> >> higher performance connection than those connected >>> directly to the Main >>> >> OpenHPI on the ShM. It would be desirable if the higher performance >>> >> connection would be used when the board/module is in the M4 state. >>> >> >>> >> Your diagram on page 1 shows 3 possible connections to a >>> Payload FUMI on >>> >> a >>> >> board/module; through the ShM's IPMB, through the Ethernet >>> connection to >>> >> the IPMC/MMC; and through the payload's Ethernet >>> connection. The Main >>> >> OpenHPI on the ShM should be able to determine that there >>> are multiple >>> >> connections to a FUMI and filter all but the highest performance >>> >> connection. If the board/module changed from the M4 state to the M1 >>> >> state >>> >> the Main OpenHPI on the ShM should use the next highest performance >>> >> connection to the FUMI. I am not sure if the detailed >>> information about >>> >> the specific connection to the FUMI would be of value to a System >>> >> Manager. >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: Anton Pak [mailto:[email protected]] >>> >> Sent: Tuesday, August 10, 2010 1:29 PM >>> >> To: OpenHPI-devel >>> >> Subject: [Openhpi-devel] More on multi-domain >>> configurations in real >>> >> setups >>> >> >>> >> Hello! >>> >> >>> >> I was thinking about multi-domains stuff and how it maps >>> to the real >>> >> setup. >>> >> It is highly possible that the system will have different >>> OpenHPI and >>> >> other HPI >>> >> service instances running at the same time. They all shall provide >>> >> coordinated view of the system. >>> >> Static configuration is an option but painful and complex one. >>> >> >>> >> Seems there shall be generic solution to allow different vendors to >>> >> provide >>> >> vendor-specific management aspects in HPI without exposing >>> source code. >>> >> If we plot a well-known way the integration process will >>> be much easier. >>> >> >>> >> Prepared small presentation. >>> >> xTCA system was used as an example but I think it is applicable to >>> >> wider set of systems. >>> >> >>> >> Please review and share your thoughts. >>> >> >>> >> I hope Bryan will no kill me for the big attachement. :) >>> >> >>> >> Anton Pak >>> >> >>> >> >>> -------------------------------------------------------------- >>> ---------------- >>> >> This SF.net email is sponsored by >>> >> >>> >> Make an app they can't live without >>> >> Enter the BlackBerry Developer Challenge >>> >> http://p.sf.net/sfu/RIM-dev2dev >>> >> _______________________________________________ >>> >> Openhpi-devel mailing list >>> >> [email protected] >>> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel >>> >> >>> > >>> > >>> > >>> > >>> -------------------------------------------------------------- >>> ---------------- >>> > This SF.net email is sponsored by >>> > >>> > Make an app they can't live without >>> > Enter the BlackBerry Developer Challenge >>> > http://p.sf.net/sfu/RIM-dev2dev >>> > _______________________________________________ >>> > Openhpi-devel mailing list >>> > [email protected] >>> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel >>> > >>> > >>> -------------------------------------------------------------- >>> ---------------- >>> > This SF.net email is sponsored by >>> > >>> > Make an app they can't live without >>> > Enter the BlackBerry Developer Challenge >>> > http://p.sf.net/sfu/RIM-dev2dev >>> > _______________________________________________ >>> > Openhpi-devel mailing list >>> > [email protected] >>> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel >>> > >>> >>> >>> >>> -------------------------------------------------------------- >>> ---------------- >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Openhpi-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel >>> >>> -------------------------------------------------------------- >>> ---------------- >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Openhpi-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel >>> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Openhpi-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel >> > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Openhpi-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openhpi-devel > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Openhpi-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
