Hi,
OK.
Just to re-align. A slave domain is a domain having the same handlers as
its master domain, but won't do any changes. So in case of ipmidirect
plugin,
it would connect to the same host:port as the master (specified in
openhpi.conf, host being the address of teh ShM and port the RMCP port).
How does the slave domain know it's a slave? Do we need a mechanism to
make the slave active, when the master's daemon dies?
The library needs the host address of the daemon serving the domain as
specified typically in the openhpiclient.conf.
So I got a bit confused between your two "host:port" below.
I would appreciate very much a oHpiDomainConfAdd or oHpiDomainAdd API.
I think it should have 3 parameters:
- domain-id IN/OUT (OpenHPI should be able to assign a domain id or use
the id as specified)
- host IN
- port IN
So according to my previous mail, I would also add interface to free the
domain-id and
Maybe the disconnect is done already by saHpiSessionClose.
And maybe the restart would be possible already by calling
saHpiSessionClose
and saHpiSessionOpen.
Cheers,
Uli
> -----Original Message-----
> From: ext [email protected]
> [mailto:[email protected]]
> Sent: Tuesday, September 14, 2010 8:43 AM
> To: [email protected]
> Subject: Re: [Openhpi-devel] Dynamic domains configuration: first step
>
> My idea now is about base lib dynamically connecting to an additional
> (new) domain.
>
> (actually I need it for slave domain).
>
> The problem is - I know slave host:port from plug-in configuration in
> openhpi.conf.
> Then I load baselib to connect this host:port and need to set
> OPENHPI_DAEMON_HOST / OPENHPI_DAEMON_PORT or add a record in
> openhpiclient.conf. To avoid this I suggest oHpiDomainConfAgg API
> in baselib.
>
> Anton Pak
>
>
> > Hi,
> > I agree with both.
> >
> > But maybe I misunderstood the idea a bit.
> > Were you talking about the baselib dynamically connecting to an
> > additional (new) domain? That is I start a new daemon on a new
> > machine and the client can connect to it with the same loaded and
> > initialized baselib?
> > Or were you thinking of the new child-domain concept, since you
> > said openhpi.conf is affected?
> >
> > Both are very reasonable ideas, and in both cases we maybe should
> > think about persistency a bit.
> > The configuration as in openhpi.conf and openhpiclient.conf is
> > persistent, but dynamic changes now are not.
> > So in case of a daemon restart, all plugin-instances loaded by
> > oHpiHandlerCreate are gone and those unloaded by oHpiHandlerDestroy
> > are loaded again.
> > If these plugins represent child-domains with your new concept, this
> > is also valid.
> >
> > The same would apply for clients when the baselib connects to other
> > domains than in openhpiclient.conf. When the client process
> restarts,
> > the baselib initializes and the configuration of openhpiclient.conf
> > is effecive again.
> >
> > Re-connect for the baselib to repair communication to a
> daemon we can
> > discuss in a separate thread.
> >
> > Cheers,
> > Uli
> >
> >
> >
> >> -----Original Message-----
> >> From: ext Anton Pak [mailto:[email protected]]
> >> Sent: Monday, September 13, 2010 4:52 PM
> >> To: [email protected]
> >> Subject: Re: [Openhpi-devel] Dynamic domains
> configuration: first step
> >>
> >> Uli,
> >>
> >> Welcome back!
> >>
> >> My comments are inline.
> >>
> >> Anton Pak
> >>
> >> On Mon, 13 Sep 2010 18:46:22 +0400, Kleber, Ulrich (NSN -
> DE/Munich)
> >> <[email protected]> wrote:
> >>
> >> > Hi,
> >> > this is a great idea.
> >> >
> >> > I think we should add also a function to delete a
> domain, since HA
> >> > systems
> >> > should live rather long, so a set of domain changes may
> >> happen over time
> >> > and
> >> > a clean-up could be helpful.
> >>
> >>
> >> In this case I suggest to protect domain configuration entries from
> >> openhpiclient.conf.
> >> Or at least default domain entry.
> >>
> >>
> >> > I don't think we need the modify. A sequence of delete
> >> (remove?) and add
> >> > domain,
> >> > would do.
> >>
> >>
> >> Ok for me.
> >>
> >>
> >> >
> >> > But I remember a Bug some time ago: 3019712:Daemon becomes
> >> > non-responsiveupon comms loss.
> >> > Perhaps we should add some restart-communication API, so we
> >> can repair
> >> > the library when
> >> > a daemon interface becomes broken without affecting
> other domains.
> >>
> >>
> >> Well, we may implement this. Need additional investigation on this.
> >> Suggest to do it as a separate feature.
> >>
> >>
> >> >
> >> > Cheers,
> >> > Uli
> >> >
> >> >> -----Original Message-----
> >> >> From: ext [email protected]
> >> >> [mailto:[email protected]]
> >> >> Sent: Sunday, September 12, 2010 1:05 AM
> >> >> To: [email protected]
> >> >> Subject: [Openhpi-devel] Dynamic domains configuration:
> first step
> >> >>
> >> >> Hello!
> >> >>
> >> >> Currently domain configuration is done with
> >> openhpiclient.conf in the
> >> >> following way:
> >> >> ---------------------------
> >> >> domain <id>
> >> >> {
> >> >> host = "<host>"
> >> >> port = <port>
> >> >> }
> >> >> ---------------------------
> >> >>
> >> >> It is proposed to introduce new function oHpiDomainConfAdd
> >> >> for adding domain configuration dynamically.
> >> >> Proposed function signature is:
> >> >>
> >> >> SaErrorT oHpiDomainConfAdd(
> >> >> const SaHpiTextBufferT *host,
> >> >> SaHpiUint16T port,
> >> >> SaHpiDomainIdT *domain_id
> >> >> );
> >> >>
> >> >> The function will be supported only on base lib level.
> >> >> OpenHPI daemon code will contain a stub returning
> UNSUPPORTED_API.
> >> >>
> >> >> Not sure if we need more functions: to delete or modify domain
> >> >> configurations.
> >> >>
> >> >> Just created feature request #3064532 for it.
> >> >>
> >> >> Comments welcome.
> >> >>
> >> >> Anton Pak
> >> >>
> >> >>
> >> >> --------------------------------------------------------------
> >> >> ----------------
> >> >> Start uncovering the many advantages of virtual appliances
> >> >> and start using them to simplify application deployment and
> >> >> accelerate your shift to cloud computing
> >> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> >> _______________________________________________
> >> >> Openhpi-devel mailing list
> >> >> [email protected]
> >> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> >> >>
> >> >
> >> >
> >> --------------------------------------------------------------
> >> ----------------
> >> > Start uncovering the many advantages of virtual appliances
> >> > and start using them to simplify application deployment and
> >> > accelerate your shift to cloud computing
> >> > http://p.sf.net/sfu/novell-sfdev2dev
> >> > _______________________________________________
> >> > Openhpi-devel mailing list
> >> > [email protected]
> >> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> >>
> >>
> >> --------------------------------------------------------------
> >> ----------------
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> Openhpi-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> >>
> >
> >
> --------------------------------------------------------------
> ----------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Openhpi-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> >
>
>
>
> --------------------------------------------------------------
> ----------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
