[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