Open Stack

On Fri, Jun 14, 2013 at 9:20 AM, Matthew Treinish <mtreinish at kortar.org>wrote:

> 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 decided to find out how to set a different config file per service and
the only thing I could come up with is modifying the files in /etc/init.
For example, /etc/init/nova-api.conf file has a last line that looks like
this:

exec su -s /bin/sh -c "exec nova-api --config-file=/etc/nova/nova.conf" nova

Am I correct in that changing this line is the best way to get a config
file 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.


Please clarify how incrementing an integer to find the next port number is
any sketchier than randomly picking a port number.  At least Flavio's
argument is that it isn't necessary, not that it is any worse.  Let's at
least have consensus in that it isn't any worse.

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.
>

I'll admit that I read that code and still don't understand the value.  To
use the backdoor you have to be on the local machine, so providing a way to
get the port number remotely doesn't make sense to me, but I think it is a
lack of understanding on my part.  I like the idea of either using "lsof |
grep :<first two digits of port number hint>" or just grepping it out of
the log files (which requires a change to log the port numbers).

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130614/b4e664c4/attachment.html>