[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