On Tue, 2008-10-28 at 15:12 -0400, Beeton, Carolyn (CAR:9D60) wrote:
> > The controlling directives moved from sipxsupervisor-config to
> > domain-config:
> >
> > SUPERVISOR_PORT (was SIP_WATCHDOG_XMLRPC_PORT)
> > CONFIG_HOSTS (was SIP_WATCHDOG_XMLRPC_PEERS)
> >
> > The SUPERVISOR_HOST directive in sipxsupervisor-config is
> > read, but is not required. It specifies the host that the
> > supervisor is running on and that host is always added to the
> > internal list of valid peers (CONFIG_HOSTS).
> >
>
> right - I forgot there is an issue open asking for sipxsupervisor-config
> to be generated. The chicken and egg problem is that it can't be
> generated if sipxsupervisor refuses the request because it isn't in the
> list of valid peers.
Which is supposed to be solved by the sipx-setup script initializing
domain-config correctly. On the master, that happens because the script
knows the host name and puts it in to CONFIG_HOSTS; on a distributed
host, the file is fetched from sipXconfig in a setup tarball (the
sipXconfig side of this is not checked in yet).
The other problem I just remembered is that there is no process
definition for sipXsupervisor itself, and so there is no resource
definition for sipxsupervisor-config, so it can't be replicated. I can
think of two ways to address that one:
1. Have sipXsupervisor internally create the requisite file
resource definition for sipxsupervisor-config without actually
creating a process definition for it to be in.
2. Create the sipxsupervisor-process.xml process definition, but
have sipXsupervisor recognize its own definition so that it
doesn't try to manage itself.
Opinions?
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
