[bind10-dev] interaction between 'active' module list and multi-process modules

[Jerry Scharf]

Hi,

A couple comments from the peanut gallery.

It is great that this being taken up, and I am sure some of what I wrote 
up about UI will need to change to reflect this.

I think it should be enforced that all things that share a comm channel 
and have no built in routing must have the same config. In the case of 
auth, DNS has no specific subrouting method to say use this config 
rather than that. If there is a receptionist that can logically separate 
and route to different instances, then they can have separate configs. 
Whether a given module at a given time supports different configs is a 
design and implementation issue that the UI should be agnostic toward.

As for how to represent modules, this is a more general problem and can 
come up in a number of ways. If you have instances connecting on two 
separate sockets and/or are binding to different interfaces, the same 
problem comes up. In this case, there is a clear routing function that 
separates traffic. One could have separate Boss processes, but this 
makes the management of the box much more complex and seems undesirable.

To be more exact, there are different cases to be looked at. Case 1 is 
where instances of a module are providing independent function. The 
second case is where the instances are providing a shared function. A 
third is a combination of 1 and 2. One could argue for a case that has a 
hierarchy of flavor 1 and flavor 2 instances of a module, but I think 
this is too complex and should be avoided.

In this light, it seems clear that we need to be able to have the 
control system that can identify and manipulate instances of a module. I 
am careful not to use the term process, because this is an 
implementation issue.

For case 1, the control channel needs to be able to provide enough 
information to differentiate the instances by the service they provide. 
A process number is less that ideal from a UI perspective, since it is 
arbitrary and unrelated to the user context. If they have the same 
services on three servers, they need to map 3 different process ids 
mentally to the same function. It would be ideal to name the different 
functional instances. You can automatically name the first instance 
default and not show names if there is only one functional instance. 
This means no change in behavior for the simple case.

Case 2 is what Jelte brought up. From the user perspective, I don't 
think there is any logical difference between the first and 7th instance 
in a sharing pool. So in the more general case, I think the user would 
want to be able to start/stop/reset the entire set as well as add and 
shrink the pool of instances.

The only time they would need something like a process id for instance 4 
would be for troubleshooting, so IMO this should not be part of the 
basic control design. The troubleshooting set of functions would need to 
involve things like restart, force a core dump, change debugging levels 
of a given instance. You can look at also being able to route a query at 
a given instance when  command channel query routing is implemented. At 
this level, it is fine to expose underlying pieces like process ID, as 
the person may well be looking at things from both the DNS and system level.


Now you can get back to the regularly scheduled work of writing real code.

jerry

On 02/06/2012 07:58 AM, Stephen Morris wrote:
> On 06/02/2012 15:16, Michal 'vorner' Vaner wrote:
>> Hello
>>
>> On Mon, Feb 06, 2012 at 12:28:36PM +0000, Stephen Morris wrote:
>>> Auth shutdown [n]
>>>
>>> Without the argument, the command shuts down all Auth processes;
>>> with the argument it shuts down only Auth process "n".
>> Would that be specific to shutdown or would it work for any
>> command?
> > From the user point of view, it only make sense to accept a parameter
> where there is a possibility of multiple processes, so bindctl would
> only accept one for the authoritative server and resolver.
>
> In the underlying logic, it might be easier if all command messages
> include a parameter indicating the process.
>
>> And if for any command, how would the syntax work together with
>> parameters of the command?
> I would suggest that the command always be sent with a parameter, any
> negative number indicating "all processes" (so "Auth shutdown" is the
> equivalent of "Auth shutdown -1".)
>
>> And who would be responsible for handling the send to all or send
>> to one of them? That could not be the boss, it doesn't see the
>> commands (they are sent directly to the module).
> It would be a "send to all".  The Auth process knows its own number
> (it received it when it started up) so when it receives a shutdown
> command, it shuts down if the process number if negative or equal to
> its own number: otherwise it ignores the command.
>
> Stephen
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev