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

[Roland Mas]

Thomas Goirand, 2012-11-15 23:12:24 +0800 :

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

It *may* be automated.  This is not an assumption you can make.  I also
assert that there's a fair chance that the automation uses Debconf
preseeding, which means that providing more functionality with Debconf
would actually be useful.

  For the rest, I did some fact-checking, and it appears that:
- dbconfig-common is indeed able to create remote databases; however,
  that is hidden behind a low-priority Debconf question, so most users
  won't even see that;
- apparently it cannot be told to just *use* existing remote databases;
- it always tries to create the db.

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

  It does.  Really, truly, giving the database server password to some
app/host/person does mean giving them full access to the database
server, even if only temporarily.  I know plenty of places where this
isn't going to happen (and that includes my own admittedly very small
network of servers and VMs).

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

  I'm not sure it asks for it on every package upgrade, but even if it
only asks for it on the initial installation, that would be once too
many.  Note that there are many database servers (including the default
PostgreSQL installation in Debian) where the database admin can't even
connect remotely.

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

  Not really.  What exists in dbconfig-common is UI to create a remote
database, not a UI to use an existing remote one.  It'll always try to
create it with the database admin account, which means it needs the
admin credentials.

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

  Actually, it does.  I checked before pushing last week, and I just
checked again, and it does 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.

  Fail how?  The installation succeeds.  It doesn't configure a
database, apart from creating an empty SQLite one.  In other words, it
does exactly what it did before my changes ("let the admin handle the
database part").  Except we now also have the ability to use a remote
database, either with interactive prompts or with preseeding, which we
didn't have before.

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

  It is not the compute node's role to handle database upgrades.  We're
lucky that the upgrade script is idempotent in this case, but I don't
think it's wise to rely on that luck.

  It is also generally not a good idea for a leaf node to handle
database upgrades.  Such things should be run on the central node,
because that prevents leaf nodes from breaking the whole cluster.  Think
of it as an API: you don't want users of the API to change it, you want
the library to change it (and then upgrade the users).

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

  I didn't kill anything.  It's still possible to use dbconfig-common's
ability to create a remote database, since my code lives entirely in the
code path where configure_db is false (ie, when dbconfig-common is *not*
involved).

  To summarize: contrary to what you claim, my changes:
- work (yes, I do test);
- made it possible to *use* a remote database (as opposed to creating
  it), which wasn't possible before;
- didn't remove anything;
- didn't break anything.

  I'm not saying the changeset is perfect, and maybe it can be made
better.  But the current code is actually working and actually useful,
so I don't understand your objections to it.

Roland.
-- 
Roland Mas

prw-r--r--    1 root     root            0 Jan  1  1970 This-is-not-a-pipe|