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

[Roland Mas]

Thomas Goirand, 2012-11-15 21:42:54 +0800 :

> 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. 

Then you believe wrong.  There are places, particularly in large
companies where cloud things are likely to be used, where even the
admins of one service don't know the admin password for the database
server because the database server is administered by different people.
And even when it's possible, it's not a good idea to do it: the compute
node only needs access to one particular database, there's no reason it
should have full access to the whole database server (with possibly
unrelated databases on it).

> 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.

  Exactly.  So you need the remote db to be setup externally, and what I
did is just a way to help the admin of the compute node in configuring
the node by providing a UI to type the required parameters.  (That's
exactly the same as what dbconfig-common policy says to do, by the way:
if we're not setting up the DB, then assume the local admin will take
care of that.)  Now if you can coax dbconfig-common into providing this
UI, then fine, my change can be rewritten to use this.  I believe this
is going to need changes *in* dbconfig-common, but I may be wrong.  In
any case, as long as the results still work, I don't really care.

>> 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.

  Apart from the "don't spread the root password everywhere" problem, it
is a problem because it's going to try to upgrade the DB.  Read that
again: each node will try to upgrade the DB on package upgrade whenever
a DB schema upgrade is needed.  Only the first one will succeed, the
others will all fail, because you can't add the same table/column twice.

>>> 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?

  Not only because of that.  Also because of the upgrade problem, and
also because it's not the job of the compute node to setup a remote
database, and also because you can't be sure that the database exists
when you install the package, and so on.

Roland.
-- 
Roland Mas

C r  ' s  d   a  u    e   e    ll r   a  u i r .  
  -- Signatures à collectionner, série n°1, partie 1/3.