Well, Agreed that multi-domain scenario is more desirable that master-slave.
However master-slave way allows single-domain old HPI application to work without modifications. And master-slave way does can be used in multi-domain setup too. So it is just orthogonal to multi-domain scenario. See comments inline. Anton Pak > Hi, > I still have multi-domain scenarios in mind. However with your new > concept, it could be avoided. > Currently we suffer severe performance problems with OpenHPI. > Therefore we are very reluctant to create a giant master domain, > that has many slaves. But if possible we would prefer one domain > and slaves. > In the big multi-domain scenarios, dynamic handling of domains looks > very advantageous. The alternative to dynamic creation is to statically > define the maximum configuration, and predefined domain ids here are > helpful. > Therefore I try to make multi-domain scenarios best supported. > > See comments inline. > > Cheers, > Uli > > >> -----Original Message----- >> From: ext [email protected] >> [mailto:[email protected]] >> Sent: Wednesday, September 15, 2010 6:24 PM >> To: Kleber, Ulrich (NSN - DE/Munich) >> Cc: [email protected] >> Subject: RE: [Openhpi-devel] Dynamic domains configuration: folluw-up >> >> Uli, >> >> Cannot say I am convinced. >> >> See my comments inline. >> >> But I am fine if there will be another function, >> for example oHpiDomainAddWithDomainId. >> And it will be used for purposes other than master-slave stuff. > > Why do you prefer a different function? The logic is very easy. > When input did=0, use your existing code to assign free did; > wenn input did>0, check whether it can be used. > So I would prefer libslave calling oHpiDomainAdd with input did=0. > I think that a way with two functions "add entry with I don't care" and "add entry with id I want" is more simple than a way with complex function "if the parameter is 0 add entry with I don't care otherwise add entry with id I want" Special semantics for 0 domain id for the function is also looks fishy. >> >> Anton Pak >> >> > Hi Anton, >> > I would like to start persuading ;-). >> > oHpiDomainAdd should allow the user to specify the desired >> domain id. >> > >> > 1. openhpiclient.conf defines currently: >> > domain 1 { >> > host = "my_domain1_host" # String value. Double quotes >> > required. >> > port = my_domain1_port # Interger value >> > } >> > >> > domain 2 { >> > host = "my_domain2_host" # String value. Double quotes >> > required. >> > port = my_domain2_port # Interger value >> > } >> > >> > So here we allow the user to specify domain ids. >> >> >> Yes, but we do not perform a check for unique domain id. > > Good point. I need to try what happens, when domain ids are not unique. > We should introduce that check and reject the configuration or at > least output a warning. > Agreed. >> >> >> > I used that and defined domain ids that are similar to the >> daemon-host's >> > IP address: >> > >> > domain 11 { >> > host = 192.168.31.11 # String value. Double quotes >> > required. >> > port = 4743 # Interger value >> > } >> > domain 31 { >> > host = 192.168.31.31 # String value. Double quotes >> > required. >> > port = 4743 # Interger value >> > } >> > >> > Therefore I would like to be able to use fixed domain-ids also with >> > dynamic >> > domains. >> >> >> Yes, here it looks good. >> And it does not appeal for any new oHpi* function :) > > But it should work together with the new oHpiDomainAdd. > When oHpiDomainAdd fills all the gaps between the predefined > domain-ids, that looks confusing, when you still look to > domain-ids. > I don't get your argument here. >> >> >> > >> > >> > 2. Domain ids are very visible on the user interface. Of >> course in case >> > of the "nested domains", which we introduce with the >> libslave plugin, >> > the id will not be so very visible as with the "master-domain". >> > But still the baselib#2 (picture slave3, the one linked to >> the daemon) >> > will open sessions using the domain id, and configurable >> values might >> > help for debugging. >> > The more slave domains we will have the more confusing it >> gets when the >> > user >> > cannot easily know where he will find domain 37. With >> predefined value, >> > a >> > user can define for rack 7, shelf 2, blade 11, AMC 2 the >> slave-domain-id >> > >> > 702112 and immediately knows what baselib#2 does. >> >> >> I doubt that it will be difficult to debug libslave. >> Assigned Domain Id may be reported to the log along with >> host/port info. > Right. But still you will get different domain ids for every test. > Well, we are living in the world that is continuously changing. :) >> >> >> > >> > >> > 3. The oHpiDomainAdd function is a general new feature. >> When used for >> > adding >> > "real" top-level domains, that is not slaves in the new >> concept, it can >> > be >> > helpful for a user when he can use his own numbering scheme. >> > >> >> Now I cannot see any possible application other than libslave. >> Could you share you vision on this? > > See above multi domain configurations. Start with initial > openhpiclient.conf and add more real domains dynamically, > e.g. when adding more racks. > > I think the oHpiDomainAdd should be a generally usable function, > like oHpiHandlerCreate, not a special function for libslave. > Agreed. >> >> >> > >> > 4. Any argument why they shouldn't configurable? >> > >> >> My arguments: >> >> For me the domain id is similar to the file descriptor. >> Why do we need >> fd = 10; open( "/etc/passwd", fd ); >> more than existing >> fd = open( "/etc/passwd" ); >> ? >> > Unfortunately the standard uses the domain id a lot. > Some functions would work just with entity path as input, > but some HPI concepts won't. > I don't get your argument here. > >> >> > >> > So I suggest for libslave in openhpi.conf: >> > handler libslave >> > { >> > did = <domain-id #1> # optional, can >> be dynamically >> > assigned >> > host = <Slave OpenHPI Daemon #1 host> # >> > port = <Slave OpenHPI Daemon #1 port> # optional, default 4743 >> > entity_root = ... # optional, default "" >> > } >> >> >> I guess there may be potential collisions between openhpi.conf >> and openhpiclient.conf. > > There we would need the similar check as above, when the same > domain id is used multiple times within openhpiclient.conf. > >> >> >> > >> > I would be willing to implement that as an addition to your patch. >> >> >> Good! When we will come to the final decision. >> >> > >> > Cheers, >> > Uli >> > >> > >> > >> >> -----Original Message----- >> >> From: Kleber, Ulrich (NSN - DE/Munich) >> >> Sent: Wednesday, September 15, 2010 2:12 PM >> >> To: 'ext Anton Pak' >> >> Subject: RE: [Openhpi-devel] Dynamic domains >> configuration: first step >> >> >> >> Hi, >> >> The new patch compiles fine. But I don't have a program (yet) >> >> to call oHpiDomainAdd. >> >> >> >> For hpi_shell I like command domain new host:port (or domain >> >> new 9 host:port, if I can >> >> persuade you to input did). >> >> Maybe even better domain add n host:port. >> >> >> >> Command line arguments for hpi_shell currently don't provide >> >> functionality of subcommands, >> >> and I don't think it makes sense for this one. >> >> >> >> Cheers, >> >> Uli >> >> >> > >> >> >> > ------------------------------------------------------------------------------ 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
