Well, It shall be integrated with existing plug-in which will provide information about Boards and Modules and connectivity parameters. I suspect the same code duplication (fetching resources, mapping, adding entity root) in the every plug-in that will support subordinate OpenHPI.
Performance is also an issue of Setup#4. If Main OpenHPI runs on the Shelf Manager with a not powerful CPU. Proxying HPI traffic for all subordinate OpenHPI instances will load it a lot. In contrary providing a reference to Board/Module OpenHPI seems to be not a hard task. Also the base library will perform entity path expansion so it will work for every plug-in that provides a reference. Anton Pak > Hi, > sounds like you are right and peers are queers. > So let's call them children. > Wouldn't it be an easy thing to write a plugin as a handler for such a > child? > Cheers, > Uli > >> -----Original Message----- >> From: ext [email protected] >> [mailto:[email protected]] >> Sent: Wednesday, August 11, 2010 11:20 AM >> To: [email protected] >> Subject: Re: [Openhpi-devel] More on multi-domain >> configurations in real setups >> >> I am not an expert with domains stuff. >> HPI spec says: >> ------------------------- >> In this architecture, the HPI implementation represents independent >> domains that are expected to contain the same resources. An HPI User >> should treat peer domains that do not contain RPT entries for >> the same set >> of resources as a fault condition. Likewise, an HPI User >> should treat peer >> domains that do not contain the same domain references, excluding a >> reference to itself, as a fault condition. >> ------------------------- >> >> Anton Pak >> >> > Hi Anton, >> > >> > about the peer domains I was not so sure whether this >> relationship must be >> > symmetric. For your parent domain, the child is the same as >> a peer. The >> > parent's >> > RPT will contain all RPT entries of the child. But not vice versa. >> > That's why I found it similar. >> > Does HPI spec allow that domain 1 has IsPeer set for domain >> 2 but not vice >> > versa? >> > If everything is identical in both directions for peers, >> why would I want >> > to >> > have two domain ids? But we are leaving the main topic here ... >> > >> > Cheers, >> > Uli >> > >> >> -----Original Message----- >> >> From: ext [email protected] >> >> [mailto:[email protected]] >> >> Sent: Wednesday, August 11, 2010 10: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 > ------------------------------------------------------------------------------ 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
