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
