Thanks, this confirms and clarifies a lot of points.
I do have more questions :o)
Let say we have:
- A shelf manager with IPMI service (In fact, there is 2
shelf-manager, but the second one is in standby mode)
- 2 blades running each an openhpi daemon, each of them connected to
the shelf-manager to retrieve IPMI data
- A SMS connected to OpenHPI with the libopenhpi.so
Probably using a Master/Slave model, I think that both daemons should have the
data in sync in order to be able to provide HPI service in case one of the HPI
daemons disappears. Right? How hard do you think it would be to keep
necessary data in sync? We would probably add a data pipe between the 2
daemons to transfer synchronization data and heartbeat? Should we also sync
some files (Domain Event Log, etc...?)
What do you think about this? I am trying to evaluate how much of effort it
will be required by us to add these features (in order for me to get the
goahead)?
Thanks!
Jean-Michel Audet
Kontron Canada
________________________________
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Renier Morales
Envoyé : Wednesday, September 12, 2007 4:29 PM
À : [email protected]
Objet : Re: [Openhpi-devel] Daemon Sync
[EMAIL PROTECTED] wrote on 09/12/2007 02:25:00 PM:
> I had seen the answer but maybe I am not sure to correctly
> understand the concept.
>
> Could you explain a little bit more the "domain connection manager"?
What we have now as standard is libopenhpi.so and openhpid. Running openhpid
creates a complete (monolithic?) HPI instace. All domains live within that
space. By linking to libopenhpi.so, you get access to that instance over TCP.
The change that I was talking about is to, instead of having openhpid house all
of the domains, to have multiple openhpids, each representing one domain. So we
break the openhpid HPI instance into pieces at the domain level.
Now we need to add logic to libopenhpi.so to know how to connect to multiple
daemons (which are now single domains). That involves making libopenhpi.so map
domain ids to ip/port numbers in order to communicate with the domains (each
now a daemon).
That logic is what I call the "domain connection manager", which would be
transparent to the API user, except for maybe a configuration file which would
have the domain id to ip/port map information, unless the mapping can be done
differently.
With that, I think that the domain relationships (e.g. peer) described in the
spec become more useful and meaningful.
>
> My understanding is that there will be 2 instance of OpenHPI running
> on 2 different blades. One of the instances will be connected to a
> domain and the second instance will have a peer connection to the
> same domain (same hardware). Right?
The idea is that the application linking to libopenhpi.so can be connected to 2
domains (i.e. daemons) at the same time. Each one of these daemons can be
running anywhere on the network. Domains themselves can be peers of one
another. Peer domains give you access to the same set of hardware resources.
How these domains access hardware depends on the OpenHPI plugin they use. Peer
domains don't necessarily have to be using the same plugin or same plugin
configuration. One could be using a local-based plugin, another a network-based
plugin to get to the same hardware.
> Where will be the "RAM" data
> storing all the information. II am not sure to fully understand
> how this will work but really interested in more discussions.
The domain instances (daemon processes) hold the domain data. Some of this can
be persisted to disk (e.g. domain alarm table, domain event log) in order to
survive a domain restart.
>
> We might be interested in contributing to OpenHPI to add this
> functionality. Is it something OpenHPI might be interested. Do you
> think that OpenHPI developers might help doing and supporting it.
Yes, we would be interested in a contribution like this. I'd be able to provide
help on this.
>
> By the way, do you have any other documentation than the HPI manual.
I'm afraid not. The HPI specification and OpenHPI manual is what we have for
now...
--Renier
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
