Ubuntu packaging should create DB automatically

Bug #705073 reported by Thierry Carrez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
High
Unassigned
nova (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Looks like we now need to run manually "nova-manage db sync" to initially create the database. Ideally that would automatically be taken care of by the Ubuntu packaging.

Tags: ubuntu
Revision history for this message
Vish Ishaya (vishvananda) wrote : Re: [Bug 705073] [NEW] Ubuntu packaging should create DB automatically

I'm not sure if this is the right solution. We currently require users to create admin users manually and get images manually. It isn't a huge burden to have them initialize the database as well, and it might prevent some misconfiguration. The current approach we are using for testing at anso is to have the packaging not start the services by default (via a setting /etc/default/nova-common), so a user would be responsible for creating the db and then enabling and running the services. This is a bit of extra work, but it ensures services aren't trampling on each other and creating databases silently.

Vish

On Jan 19, 2011, at 11:25 AM, Thierry Carrez wrote:

> Public bug reported:
>
> Looks like we now need to run manually "nova-manage db sync" to
> initially create the database. Ideally that would automatically be taken
> care of by the Ubuntu packaging.
>
> ** Affects: nova
> Importance: Undecided
> Status: New
>
> ** Affects: nova (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Also affects: nova (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Nova Bug
> Team, which is subscribed to OpenStack Compute (nova).
> https://bugs.launchpad.net/bugs/705073
>
> Title:
> Ubuntu packaging should create DB automatically
>
> Status in OpenStack Compute (Nova):
> New
> Status in “nova” package in Ubuntu:
> New
>
> Bug description:
> Looks like we now need to run manually "nova-manage db sync" to
> initially create the database. Ideally that would automatically be
> taken care of by the Ubuntu packaging.
>
>

Revision history for this message
Thierry Carrez (ttx) wrote :

Currently the packaging starts up the services at install-time, which leads to tons of error messages in logs. You are right that one way to fix it is to *not* start services at install-time and document the need to initialize the DB. That can be done using some START=0 in /etc/default/nova that the upstart jobs would source.

That's not the Debian way though: if possible, we should just initialize a local DB (in the debian maintainer scripts in packaging) and start the services.

In all cases, we need to change the way it currently works :)

Changed in nova:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Ricardo Carrillo Cruz (rcarrillocruz) wrote :

How about changing this to a documentation bug? Pointing out in the wiki/docs that we need to create those tables as a first step would suffice.
Also, it'd be nice if we added a command to nova.sh tool to create them, something like "./nova.sh db-sync" .
Thoughts?

Revision history for this message
Thierry Carrez (ttx) wrote :

[ sidenote: we also need to decide where we put bugs that affect Ubuntu packaging of Nova. It's not really a nova bug (and most nova-core devs can't fix it), but it's not a bug in Ubuntu either, since they don't carry the package in official archives. A separate project sounds a bit overkill... So far I've been opening two tasks, but maybe we should just keep it in Nova with a specific official tag. ]

tags: added: ubuntu
Revision history for this message
Ricardo Carrillo Cruz (rcarrillocruz) wrote :

Oh, and ofc, nova.sh should also not drop the database every time is launched, otherwise the tables created "nova-manage db sync" will disappear.

Revision history for this message
Soren Hansen (soren) wrote :

2011/1/19 Vish Ishaya <email address hidden>:
> I'm not sure if this is the right solution.  We currently require users
> to create admin users manually and get images manually.  It isn't a huge
> burden to have them initialize the database as well,

Comments about slippery slopes aside, the difference here is that the
daemons will fail to start and respawn at a very high rate until the
DB is created. I don't really see the danger in creating the database
in the packaging on the initial install. Packages should generally
come with a usable, safe default config and be enabled by default. The
default config doesn't interfere with existing system services or the
surrounding network.

--
Soren Hansen <email address hidden>
Systems Architect, The Rackspace Cloud
Ubuntu Developer

Revision history for this message
Jay Pipes (jaypipes) wrote :

On Thu, Jan 20, 2011 at 5:32 AM, Soren Hansen <email address hidden> wrote:
> 2011/1/19 Vish Ishaya <email address hidden>:
>> I'm not sure if this is the right solution.  We currently require users
>> to create admin users manually and get images manually.  It isn't a huge
>> burden to have them initialize the database as well,
>
> Comments about slippery slopes aside, the difference here is that the
> daemons will fail to start and  respawn at a very high rate until the
> DB is created. I don't really see the danger in creating the database
> in the packaging on the initial install. Packages should generally
> come with a usable, safe default config and be enabled by default. The
> default config doesn't interfere with existing system services or the
> surrounding network.

As discussed with Vish yesterday on IRC, I share Soren's opinion on this one.

-jay

Changed in nova (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Todd Willey (xtoddx) wrote :

I'm confused about how this would work for a multi-node setup. Which package would create the database, and how would you be sure it wasn't installed on every node? Would there be a debconf flag that would tell it to not install the database for some nodes?

Revision history for this message
Jay Pipes (jaypipes) wrote : Re: [Bug 705073] Re: Ubuntu packaging should create DB automatically

I would assume that it would work the same way as any other package
that can be installed on multiple nodes:

* Install the database on the node as if the installation is only on this node
* Admin goes and edits the configuration file to point, say, the
database to a central location
* Admin restarts services

-jay

On Thu, Jan 20, 2011 at 2:56 PM, Todd Willey <email address hidden> wrote:
> I'm confused about how this would work for a multi-node setup.  Which
> package would create the database, and how would you be sure it wasn't
> installed on every node?  Would there be a debconf flag that would tell
> it to not install the database for some nodes?
>
> --
> You received this bug notification because you are a member of Nova Bug
> Team, which is subscribed to OpenStack Compute (nova).
> https://bugs.launchpad.net/bugs/705073
>
> Title:
>  Ubuntu packaging should create DB automatically
>

Revision history for this message
Soren Hansen (soren) wrote :

I've added a snippet to nova-common's postinst that creates the database if it's a fresh install.
I haven't sorted out upgrades yet, but I expect it'll involve checking if there's an sql_connection set in nova.conf. If so, show a help screen explaining that a db sync is needed and that it has to be synced between the components that share the data store. If no custom sql_connection is set, just do the upgrade.

I need to add a way to check if an upgrade is due, though. I only want to be showing the help text if there's actually an upgrade that needs to be done.

Revision history for this message
Jay Pipes (jaypipes) wrote :

Soren, that sounds like a reasonable solution to me.

Thierry Carrez (ttx)
Changed in nova:
status: Confirmed → Fix Committed
Changed in nova (Ubuntu):
status: Triaged → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: none → 2011.1
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.