Let's just implement two functions. :)
We will post the patch to SF tracker.
Optionally we may send a mail to devel list about the patch.
Yes, I was wrong in Note #1. So Note #1.1 - return ERR_DUPLICATE.
I suggest to create new feature request - "add oHpiDomainAdd and
oHpiDomainAddById in hpi_shell".
So we will have two patches - one for base lib and another for hpi_shell.
Which parts would you like to do?
Anton Pak
On Thu, 16 Sep 2010 18:22:55 +0400, Kleber, Ulrich (NSN - DE/Munich)
<[email protected]> wrote:
> 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
