Hi, let's go back concentrate on finding the right interfaces for the new functions. Answers inline. Cheers, uli
> -----Original Message----- > From: ext [email protected] > [mailto:[email protected]] > Sent: Wednesday, September 15, 2010 9:51 PM > To: Kleber, Ulrich (NSN - DE/Munich) > Cc: [email protected]; [email protected] > Subject: RE: [Openhpi-devel] Dynamic domains configuration: folluw-up > > 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. I don't think it is complex. Therefore I created a patch adding that to your patch and attach it. I also created new hpi_shell subcommand for it. hpishell: "domain new" works as before, using "domain newid id host port" you can select the id you want. In case of the way hpi_shell syntax works, I found it easier to have two commands there, but both use the same oHpiDomainAdd. > > >> > >> 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. Will do a bug report and patch. > > >> > >> > >> > 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. I meant the following: If openhpiclient.conf specifies domainids 1,2,3,4,5,11,12,13,14,15, 21,22,23,24,25 for some proprietary reason of numbering, and then I create 7 dynamic domains, those will be assigned with the values 6,7,8,9,10,16,17. > > >> > >> > >> > > >> > > >> > 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. Typically different domains manage resources with entity-paths (EP) starting with different entity-roots. So why not have saHpiOpenSession(EP#1) opening a session to the domain managing EP#1. But SAF decided to allow two different domains managing the same EP with multiple resources via different domains. In that case the domain id is important. So it would be possible to do saHpiOpenSession without did, but then the concept of "overlapping" domains doesn't work anymore. That's what I meant. > > > > >> > >> > > >> > 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 > >> >> > >> > > >> > >> > >> > > > > >
hpi_shell_newid.patch
Description: hpi_shell_newid.patch
oHpiDomainAdd-uli.patch
Description: oHpiDomainAdd-uli.patch
------------------------------------------------------------------------------ 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
