[openstack-dev] [nova] [placement] Which service is using port 8778?
sean at dague.net
Tue Dec 20 13:03:35 UTC 2016
On 12/20/2016 07:53 AM, Sylvain Bauza wrote:
> Le 20/12/2016 10:26, Sylvain Bauza a écrit :
>> Le 20/12/2016 10:20, Chris Dent a écrit :
>>> On Tue, 20 Dec 2016, Sylvain Bauza wrote:
>>>> Before moving forward and picking yet another port that could trample
>>>> another service, I'd rather prefer first that Senlin jobs would
>>>> temporarely disable the placement-* services so that the gate would be
>>>> happy, while in the same time we try to identify a free port number that
>>>> the placement API can safely bind.
>>> Another option here may be to not have the placement api bind to two
>>> ports. The current set up binds 8778 with the API at /, but what's
>>> registered in the service catalog is port 80 with the API at
>>> So perhaps only use the http://184.108.40.206/placement and disable the
>>> virtualhost that listens on 8778?
>>> I'd experiment with this myself but I'm going to be away from a
>>> compute all day. If people think it is a good idea but nobody has a
>>> chance to do it today I'll look into it tomorrow.
>> Oh good catch. Since we register the service catalog with port 80, then
>> there is no reason to consume an application port.
>> Chris, don't worry, I'll play with that today.
> So, after some investigation, I totally understand why we're using
> virtualhosts for running the WSGI apps corresponding to each service,
> since we want to keep the service catalog entries unchanged if the
> operator wants to move from eventlet to mod_wsgi.
> Given that devstack was deploying a service catalog entry pointing to
> HTTP port, should we just assume to drop the use of port 8778 ?
> I'm a bit afraid of any possible impact it could have for operators
> using the placement API with the virtualhost support which also provide
> a WSGI daemon mode compared to the embedded mode that is executing calls
> to :80/placement...
> Thoughts ? I mean, I can do the cut and drop that, but that will
> certainly have impact for other deployers that were reproducing the
> devstack install, like for TripleO :
Yes, we should stop with the magic ports. Part of the reason of
switching over to apache was to alleviate all of that.
More information about the OpenStack-dev