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.
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.
> 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 :)
>
>
> 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.
>
>
> 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?
>
> 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" );
?
>
> 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.
>
> 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
