[openstack-dev] [Oslo] Code review I7ec346db: Improve usability when backdoor_port is nonzero

Mark McLoughlin markmc at redhat.com
Fri Jun 14 16:01:40 UTC 2013


On Thu, 2013-06-13 at 12:29 -0500, Ray Pekowski wrote:
> I suppose that since my patch for this code review was given a -2 it needs
> to be discussed in this mailing list.

Bear in mind that not everyone reading this thread would know what
review you're talking about. It's this one:

  https://review.openstack.org/31714

> The code review addresses this as a usability problem, but perhaps by
> approaching it as a bug fix, the community will be more amenable to the
> proposed solution.  The bug is the failure of enabling the eventlet
> backdoor functionality on all but the first service that comes up when the
> backdoor_port is configured to be anything other than 0.  Why provide an
> option that will 100% fail in a common situation (more than one service)
> unless one specific value is configured?
> 
> I see two solutions:
> 
> 1) Change the backdoor_port configuration option to a boolean named
> enabled_backdoor and always use a port number of 0.  I don't like this
> solution.

Honestly, I think it would be perfectly fine if we did two simple
things:

  1) Logged (at INFO) level the port number chosen

       [INFO] Eventlet backdoor listening on port 4321

  2) Changed the help string for backdoor_port to say "set to zero to
     enable the backdoor on a random port and non-zero to enable it on a
     specific port. The chosen port is displayed in the service's log 
     file."

So, yes you hit a usability issue with a pretty obscure feature. But
let's not get too side-tracked on this - a tiny patch goes a long way to
stop anyone hitting that same issue.

Long term, I think services will have a more useful service control RPC
API for administrators as suggested by Vish a while ago:

  https://etherpad.openstack.org/grizzly-common-services-control

it's through this interface we'd expose a more usable way of querying
the backdoor port.

> 2) Change the backdoor_port configuration option name to
> backdoor_starting_port and find a non-conflicting port by iteratively
> incrementing the port number until an unused port is found.  The first
> service gets backdoor_starting_port and the second service likely gets
> backdoor_starting_port+1 and so on.
> 
> I like the second option.  I have submitted a new patch that implements it
> and logs a message about backdoor_port being deprecated if it is found.
> 
> Please evaluate whether this new patch removes the objection that raised
> the -2, namely that using a port number other than the one specified on the
> backdoor_port would be unexpected and bad behavior.

I don't think the starting_port thing helps too much - fundamentally,
you still need to be prepared to figure out which service ended up on
which port.

Cheers,
Mark.




More information about the OpenStack-dev mailing list