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

[Thomas Goirand]

On 11/15/2012 10:56 PM, Roland Mas wrote:
> 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.

In such a big organization, installation would be automated anyway. One
way would be to preseed the debconf and dbconfig-common values (FYI, for
dbconfig-common, the way to do it is to add a file in
/etc/dbconfig-common containing the values of dbc_*).

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

But it does *not*! dbconfig-common asks for the admin privileges for the
time to create the db. Once it is done, it flushes it and never
remembers it.

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

Well, this UI exists already in dbconfig-common.

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

Well, the result does *not* work. Try to set debconf in non-interactive
mode, and you'll have db_get ${PKG_NAME}/configure_db set to false, then
it will go in your:
db_input high ${PKG_NAME}/remote_db_* || true
things, which will have no value (because running in non-interactive
mode), and then fail.

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

Are you talking about the "nova-manage db sync" thing? Well, first I
don't think this is a problem to run this script over and over again (I
didn't check, but it should be written in an idempotent way). And if it
was, then this is a call for a new debconf question: "upgrade the db?"
at maximum. Not for a rewrite of dbconfig-common.

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

Have you ever tried to run "nova-manage db sync" multiple times? It does
run as many times as you want...

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

I'm sorry, but I don't know what upgrade problem you are talking about.
If there is one, please care to explain it.

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

I really don't see setting-up the compute database from a compute node
as a problem at all. And that's precisely because you don't know if the
database exists when you install the package that you want
dbconfig-common to check for it, and eventually create the db. Please
don't kill this nice feature which we really want.

Thomas