On Thu, Aug 21, 2008 at 11:15:14AM -0700, Steven Dake wrote:
> I may be dense, but I am still not sure what you are proposing. It
> sounds like you would like a function added to the service engine
> structure which allows the setting of the nodeid for that local node.
Yes, exactly that.
> This approach has several issues:
> 1) If two service engines define this function, which one gets to set
> the node id? Both? Then *two* sets of nodeids have to be transmitted
> across the network.
No, they don't. You're assuming that we allow an older openais
to interact with this new one. We obviously can't. This means either a
protocol break (the old and new daemons recognize that they can't speak
together) or a configuration switch. This covers (2) as well.
Basically, you require that the sysadmin be smart enough not to
have two different openais environments interacting. They must be
distinct. This is not a new requirement - you can't have a cman-running
openais work with a non-cman-running one today either.
> 3) A service engine can already set the node id statically in the
> configuration object database. Why not just do it that way?
This is what cman does today, and it's a pain, because the
sysadmin must actively configure node ids.
Unless...you're saying that the service engine does this
up-front, just like cman does, but using an auto-node-id method of its
own choice. Basically you're saying the mechanism is what cman does
today, but the generator of the ids is Beekhof's ip_addr & 0x7FFFFFFF?
That might just work.
It still won't allow interaction between cman/pacemaker and
non-cman/pacemaker openais, but that doesn't work today either.
Joel
--
There are morethings in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
