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. > > 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. > > > > 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. > > > > > > > > 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. > > > > > > > > 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. > > > > > > 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. > > > > > 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
