[PATCH conductor] BZ#806001 - Create default admin via database seeds

Scott Seago sseago at redhat.com
Fri Jun 22 05:01:37 UTC 2012


On 06/21/2012 02:34 PM, Jason Guiditta wrote:
> On 20/06/12 18:09 -0400, John Eckersberg wrote:
>> Previously, the default admin user was created by aeolus-configure,
>> but this approach was confusing for users.  By creating the admin as
>> part of the database seeds, we are guaranteed to always have a usable
>> admin user at first login.  The expecation is for administrative users
>> to be managed via the web UI (or API), not via configure.
>> ---
>> src/db/seeds.rb |   14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>
> I have not tested this, but looks reasonable on quick viewing (this is
> not an ack or nack btw).  However, I am wondering if this could/shoudl
> be added $elsewhere, like scott did with the new roles, which I
> believe gets called via our rake dc:upgrade script.  I guess it might
> be safe for an existing installation, and I wil roll with that if you
> think it is, just wanted to make sure we thought of that case before
> introducing new seed data.
>
> -j
This isn't relevant to the current patch, as that's been 
reverted/abandoned, but I wanted to clarify one thing. You're referring 
to my recent patch that changed a couple role definitions. Since role 
defs are defined in seeds.rb, my patch _did_ include a change to 
seeds.rb. Of course, seeds.rb is only executed on a new db load, so the 
issue was that only changing seeds.rb works for new installs, but 
upgrades to existing installations don't get the change. Therefore role 
updates needed to show up in two places:
1) in seeds.rb, since that's the canonical place (at least for now) for 
this data to be loaded from, so not putting it there would break new 
installs
2) somewhere else that gets executed only on upgrade. It could have been 
a migration, but we decided not to do that, since there's no actual 
schema change involved. Therefore we decided to create a new mechanism 
-- a 'dc:upgrade' task to be run after migrations on an existing 
installation to do various other upgrade-oriented work that doesn't 
involve migrations/schema changes.

This patch (if we were sticking with that plan) handles 1) already. We 
wouldn't need to handle 2), since if we're upgrading an existing 
installation, the admin user will have already been created, so it 
wouldn't matter that the default 'load new admin' procedure had changed.

Scott




More information about the aeolus-devel mailing list