From: Anton P. <ant...@pi...> - 2010-09-14 10:34:32
|
Uli, I tried to show possible setups on the attached pictures. The variant I prefer is one where openhpiclient.conf is not needed. Anton Pak On Tue, 14 Sep 2010 13:17:57 +0400, Kleber, Ulrich (NSN - DE/Munich) <ulr...@ns...> wrote: > 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 ant...@pi... >> [mailto:ant...@pi...] >> Sent: Tuesday, September 14, 2010 8:43 AM >> To: ope...@li... >> 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:ant...@pi...] >> >> Sent: Monday, September 13, 2010 4:52 PM >> >> To: ope...@li... >> >> 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) >> >> <ulr...@ns...> 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 ant...@pi... >> >> >> [mailto:ant...@pi...] >> >> >> Sent: Sunday, September 12, 2010 1:05 AM >> >> >> To: ope...@li... >> >> >> 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 >> >> >> Ope...@li... >> >> >> 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 >> >> > Ope...@li... >> >> > 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 >> >> Ope...@li... >> >> 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 >> > Ope...@li... >> > 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 >> Ope...@li... >> 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openhpi-devel |