[openstack-dev] eventlet_backdoor Configuration Option
Matthew Treinish
treinish at linux.vnet.ibm.com
Tue Nov 6 19:12:43 UTC 2012
Hi Everyone,
I recently pushed https://review.openstack.org/#/c/15446/ to gerrit. This
changed the backdoor_port configuration option to be per service. Currently,
to use backdoor ports for multiple services you need to use separate config
files for each of the services with different ports in each file. This commit
changed it so there was a different port option for each service. For example:
backdoor_port_api
backdoor_port_cpu
backdoor_port_cert
There were 2 reasons for this: First is for the coverage extension that I am
working on. The plan is for coverage to be started through backdoors to each
of the services to provide a full picture. However if multiple configuration
files are used per service we will not be able to pull in all the ports to the
api server.
The second reason is for devstack integration. In devstack using multiple
configuration files is going to be tricky since nova.conf is auto generated
currently. For the coverage extension the plan was to integrate it into the CI
system with tempest as a periodic run. But, it would also be useful to be able
to enable backdoors through devstack easily.
Based on the review comments however, the consensus is against replacing
multiple config files with a bunch of new options. Which is understandable,
especially considering the recent push to clean up the options.
So, the open question is where does this leave the coverage extension, which
requires accessing all the service backdoors at once? Since multiple
configuration files will not work for this case.
The other approach that I was considering was to just auto increment the port
until there wasn't a port collision anymore. However, this doesn't solve the
access problem for the api server with the coverage extension, so I would need
to add an rpc call to the api server to either receive or ask for all the
backdoor ports, which can get tricky.
Thanks,
-Matt Treinish
More information about the OpenStack-dev
mailing list