My idea with a plugin for childdomain was that the plugin calls the daemon that implements the childdomain with the same interface currently used by the library. It's no inter-plug-in API since it needs to contact the childdomain. And the childdomain could be something different to ipmidirect. Probably it will always be, since it needs a plugin that does only the board local stuff.
Cheers, Uli > -----Original Message----- > From: ext Anton Pak [mailto:[email protected]] > Sent: Wednesday, August 11, 2010 5:07 PM > To: [email protected] > Subject: Re: [Openhpi-devel] More on multi-domain > configurations in real setups > > I guess there should be integration between ipmidirect (who > knows about > Boards and Modules) and this plug-in. > May be the same about a plug-in for HP/IPMB systems. > It seems that code should be on library or daemon level or in the > ipmidirect or we have to implement inter-plug-in API. > > Anton Pak > > > On Wed, 11 Aug 2010 13:46:04 +0400, Kleber, Ulrich (NSN - DE/Munich) > <[email protected]> wrote: > > > 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 > ------------------------------------------------------------------------------ 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
