Open Stack

On Thu, Jun 13, 2013 at 05:51:11PM -0500, Ray Pekowski wrote:
> On Thu, Jun 13, 2013 at 4:16 PM, Ray Pekowski <pekowski at gmail.com> wrote:
> 
> >
> > - enable_backdoor (default is tcp sockets with port 0)
> > - enable_backdoor_ipc (unix domain sockets)
> > - enable_backdoor_starting_port (tcp sockets with port number hint)
> >
> 
> Better option names perhaps:
> - enable_backdoor
>   * boolean option
>   * defaults to port 0 and tcp sockets
> - backdoor_use_unix_domain_sockets
>   * boolean option
>   * implies enable_backdoor = True
>   * mutually exclusive to backdoor_tcp_socket_port_hing
>   * forces the use of unix domain sockets and with a filename based on the
> pid
> - backdoor_tcp_socket_port_hint
>   * integer value
>   * implies enable_backdoor = True
>   * mutually exclusive to backdoor_use_unix_domain_sockets
>   * uses the hint as a starting point incrementing by one for collisions
> 
> backdoor_port should be deprecated

So I don't necessarily think that there is anything wrong with the current model
for setting the backdoor_port. If you need to explicitly set the port for multiple
services why not just use multiple config files per service? I don't think we want
to default any behavior that auto increments from a base integer value. It gets
sketchy real fast. The unix domain sockets sound like an interesting idea to me,
but I'm not sure if there is any real advantage to using it over what exists now.

Using the random assigned port with 0 is a workable solution for projects if you
don't want to use multiple config files per service. Take a look at how nova
uses backdoor ports. (with the coverage extension) When the service is created
the backdoor port is stored in the object and an rpc call is used to query the
port when necessary. This can then be exposed anyway deemed necessary (an api
extension, etc.). In nova's case this is used in the coverage extension to
control coverage collection and reporting on all the services.

-Matt Treinish