OK, Let's see whether somebody gets curious now, since the patches were not on the devel list ;-). About Note #1: with my patch an existing domain id should be rejected. I need to check again. About Note #2: ok. But I didn't do correct indentation anyways....
I won't fight for a single procedure. Better let's start implementing the remaining stuff! Cheers, Uli > -----Original Message----- > From: ext Anton Pak [mailto:[email protected]] > Sent: Thursday, September 16, 2010 3:18 PM > To: Kleber, Ulrich (NSN - DE/Munich) > Cc: [email protected] > Subject: Re: [Openhpi-devel] Dynamic domains configuration: folluw-up > > Uli, > > It works. > But I still stand on position that two function approach is > more simple > and is more clear. > > Note #1: there is no check for duplicated domain id in your patch. > > Note #2: One more note: using spaces instead of tabs makes code more > readable in different editors/viewers. > > Anton Pak > > On Thu, 16 Sep 2010 17:05:48 +0400, Kleber, Ulrich (NSN - DE/Munich) > <[email protected]> wrote: > > > 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 > >> >> >> > >> >> > > >> >> > >> >> > >> >> > >> > > >> > >> > >> > > ------------------------------------------------------------------------------ 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
