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
