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
