[openstack-dev] [common] moving manager.py and service.py into common

Jay Pipes jaypipes at gmail.com
Tue Aug 7 19:42:50 UTC 2012


On 08/07/2012 03:06 AM, Mark McLoughlin wrote:
> On Fri, 2012-07-27 at 11:22 -0400, Jay Pipes wrote:
> 
>> I'd also love to see standardization around the binding of services to
>> sockets. In Nova-land, each service has its own nova.conf value -- for
>> example, there is a host/port pair for each of nova-os-api,
>> nova-ec2-api, nova-metadata-api, etc: (see [1])
>>
>> osapi_compute_listen=0.0.0.0
>> osapi_compute_listen_port=8774
>> ec2_listen=0.0.0.0
>> ec2_listen_port=8773
>> metadata_listen=0.0.0.0
>> metadata_listen_port=8775
>>
>> There are also nova.conf options that duplicate the above (not sure if
>> these even are used any more...):
>>
>> ec2_host=$my_ip
>> ec2_port=8773
>> metadata_host=$my_ip
>> metadata_port=8775
>>
>> as well as this pair for the nova-objectstore service:
>>
>> s3_host=$my_ip
>> s3_port=3333
>>
>> In every other core project -- Glance, Swift, Keystone, Cinder and
>> Quantum -- only the following options are used:
>>
>> bind_host=0.0.0.0
>> bind_port=XXXX
> 
> Not quite :)
> 
> Cinder follows Nova's lead because it copied and pasted Nova's code.

Ah, my bad. When grepping for bind_host/port, I noticed it pop up in
Cinder's source but didn't notice it was just in openstack common and
not used. Shame :(

> Quantum has followed Glance's lead because it copied and pasted Glance's
> code.
> 
> Keystone has bind_host and public_port/admin_port.

ack. Halfway standardized :)

> Swift is quite similar to Glance, yes - bind_ip and bind_port.
> 
>> and each service has its own paste deploy INI file and configuration
>> file containing the bind_host/bind_port options for the particular service.
>>
>> I would love it if Nova could standardize on using bind_host/bind_port
>> for all of its services that listen on TCP sockets as well. That way, we
>> can put the get_socket() call that originated in Swift and exists in
>> Glance as well, into a openstack.common.wsgi module.
> 
> I don't think it's unreasonable for a single process to expose multiple
> APIs bound to different ports. That, at least, means that you need to
> support configuring multiple ports in the one file.
> 
> We could use sections for this e.g.
> 
>   [DEFAULT]
>   bind_host = 127.0.0.1
> 
>   [osapi_compute]
>   bind_port = 8774
> 
>   [osapi_compute]
>   bind_port = 8776
> 
>   [ec2]
>   bind_port = 8773
> 
>   [metadata]
>   bind_port = 8775
> 
> i.e. we'd try bind_host/bind_port in a section corresponding to the
> service name and fall back to bind_host/bind_port in DEFAULT if not set.

That would work for me :) I think that's nice and clean.

Best,
-jay



More information about the OpenStack-dev mailing list