[Openstack-devel] Splitting the nova package (and possibly others)?

[Thomas Goirand]

On 11/15/2012 05:05 PM, Roland Mas wrote:
> Thomas Goirand, 2012-11-15 14:53:53 +0800 :
> 
>> On 11/14/2012 10:14 PM, Roland Mas wrote:
>>>   Hi all,
>>>
>>>   I'm still working on getting the HOWTO to lead to a working multi-node
>>> setup, and I think we have a problem with (at least) nova regarding the
>>> database configuration.
>>>
>>>   The recent work led to the nova-common package creating, configuring
>>> and populating the novadb database locally.  This works nice for the
>>> "management" node where everything gets installed.  However, for
>>> supplementary "compute" nodes (forgive me if I haven't got the
>>> terminology exactly right), the various nova-* packages should be
>>> installed but use the remote database instead.  The current nova-common
>>> package asks the user whether to configure the database with the
>>> dbconfig-common framework; if the user says yes, we're in business and
>>> the database gets configured locally.
>>
>> Can't dbconfig-common configure a db hosted on another host?
>> If dbconfig-common doesn't, I think we should add such feature in it.
> 
>   Apparently it can be configured to use a database server on another
> host, but it'll try to create and upgrade the database there, and it
> requires the administrative password of the remote host, which I'm not
> comfortable with giving (and many people won't even be able to give
> it).

Why that? If you setup a cloud, I believe you do know the admin password
of the remote db. Also, you can't be sure that the db already exists and
is up and running, you're only double-guessing it, because that's the
logical way to do it, but someone might just decide to setup the mysql
server, then few compute host, then the control host.

> There doesn't seem to be a way to tell it "don't bother about
> creating/upgrading/maintaining the database, just use what's there".

Well, why is that a problem? If the db exists, it wont touch it. If it
doesn't, it will attempt to create it. I don't see this as a problem. If
it is, then you can always fallback to not creating the db, and
configuring it by hand in the config file. That's fine for me.

>> That's the goal yes: let the admin decide and configure the db himself.
>> I don't see why this is a problem.
> 
> Because then each compute node has their own unrelated database and
> they don't communicate, while the proper setup seems to be that they all
> use the same database (presumably on the proxy node).

Right, there's a unique db for compute, AFAIK. And then? Why do you
think it is a problem to let dbconfig-common create the db if it doesn't
see one? Only because of giving the admin password?

Thomas