Open Stack

On 14/06/13 10:01 -0500, Ray Pekowski wrote:
>On Fri, Jun 14, 2013 at 2:47 AM, Flavio Percoco <flavio at redhat.com> wrote:
>
>    FWIW, I don't consider it broken either and I agree with the support
>    for unix sockets.
>
>
>The common use case is multiple services using the same config file. 
>backdoor_port allows for a non-zero value and most people will likely not
>choose 0 as their first choice.  That will fail 100% of the time for all but
>the first service.
> 

Well, that means 2 things to me:

1) It's definitely a better idea to use enable_backdoor and always
pick a random port.

2) Like you said, folks are setting a specific port instead of using 0
and that breaks their deployment. And again, they have to either use 0
and pick a random one or use a different config file for every service
and make sure they don't clash.

I'm not saying this is the most easy way to do things, in fact, I'm
suggesting - as Eric did - to replace current backdoor_port with
enable_backdoor and always pick a random port. In addition, we could
also support linux sockets.


>
>    Also, I'd rather use a boolean that *always* pick a random port. It
>    doesn't make sense to allow port hints if the user will have to "find
>    out" what port was picked up anyways.
>
>
>There is some value in the values being close to a chosen number.  Because once
>you find out in either case, it is easier to remember that 8801 is nova-api and
>8802 is nova-compute than it is to remember 9281 is nova-api and 3724 is
>nova-compute.

TBH, that doesn't convince me at all. It could be 8802 or 8803 or any
number higher than that. Even though it is sequential to the chosen
port, it is still non-deterministic.

My thinking is that we should support:

1) Random port
2) Linux sockets

Cheers,
FF

-- 
@flaper87
Flavio Percoco