Remove seed on rails server start in development.

[Fryguy]

In a production setting, evmserverd will be resposible for seeding the
database. In a development setting, we should not be seeding when we
start the UI. Developers should instead be encouraged to use bin/update
or call db:seed directly when changes are made. Since most developers
need to call bin/update before starting a rails server, in order to
build the UI assets, this is part of the normal workflow.

This change should eliminate about 1 second at rails server boot in
development.

Some more:

• Seeding the database will change records in the database, and if pointing to someone else's database (say a customer database or a testing database), then we are modifying the target environment, making diagnostics harder by dirtying the source.
• Seeding the database is a blocking operation as it takes a lock on critical tables. While in development this doesn't really matter much, it's better to remove it to avoid that.

[Fryguy]

cc @jrafanie @kbrock

[jrafanie]

cc @h-kataria @himdel I'm not sure if anyone was depending on rails s automatically seeding the primordial tables but if so, they'd need to rake db:migrate db:seed OR bin/update whenever they pull new code

[Fryguy]

cc @himdel @skateman @h-kataria @martinpovolny

I'd like your input here and make sure I'm not making too many assumptions, particularly since this might affect the flow of UI developers.

In my mind this is the way it always should have been (I was actually surprised to find we did any seeding at all when calling rails s)

[h-kataria]

@jrafanie i have always been running seeding manually either by running rake db:migrate db:seed or just running commands in rails console to seed any specific models

[Fryguy]

@jrafanie Marking as WIP cause I'm changing it as discussed above in #19535 (comment) , with tests.

[Fryguy]

@jrafanie Updated. Thoughts?

[jrafanie]

@jrafanie Updated. Thoughts?

This makes sense to me.

I mentioned in chat that I believe the original logic for automatically seeding primordial was added to rails server processes back when bundler might have been the only dependency management we had to do frequently. Back then, the UI workflow was update your code, bundle update, rake the database, and run rails server.

Now that bin/update is required often with javascript library dependency changes, you can't get around seeding properly as bin/update does the seeding for you.

[skateman]

I'm good with this, but we might want to focus on the remaining 9 seconds 😆

[Fryguy]

@skateman I'll update the OP, but there's a few other reasons for this...

• Seeding the database will change records in the database, and if pointing to someone else's database (say a customer database or a testing database), then we are modifying the target environment, making diagnostics harder by dirtying the source.
• Seeding the database is a blocking operation as it takes a lock on critical tables. While in development this doesn't really matter much, it's better to remove it to avoid that.

[jrafanie]

I'm good with this, but we might want to focus on the remaining 9 seconds 😆

@skateman Want to talk routes with me? I can give you all the fun details

[skateman]

Let's do that when I'm in Mahwah!

[himdel]

@Fryguy I'm seeing one potentially big issue... MiqDatabase.seed sets session_secret_token and csrf_secret_token.

If we only do primordial seed once on the appliance, those tokens are not really secure anymore, right? (Unless they are supposed to stay the same during the whole lifetime..)

EDIT: not seeing any other issues 👍

[skateman]

@himdel do we care about that in development?

[himdel]

Not really, but does this only affect development though?

[himdel]

BTW we're also seeding region twice .. Zone.seed calls MiqRegion.seed

[himdel]

This also means changing the GUID file will need a bin/update / db:seed. (I'm fine with that.)

[Fryguy]

BTW we're also seeding region twice .. Zone.seed calls MiqRegion.seed

There are a number of these interdependencies...definitely needs to be fixed / cleaned up.

[Fryguy]

Not really, but does this only affect development though?

Yes this only affects development. In production, evmserverd is doing all of the seeding up front, and then we use forking, which bypasses Vmdb::Initializer.init

[miq-bot]

Checked commit Fryguy@56fab2e with ruby 2.5.5, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
4 files checked, 1 offense detected

app/models/mixins/miq_web_server_worker_mixin.rb

• ❗ - Line 26, Col 7 - Layout/EmptyLineAfterGuardClause - Add empty line after guard clause.

[kbrock]

Can we drop the primordial concept and just say seeded?

[Fryguy]

Can we drop the primordial concept and just say seeded?

Maybe but not in this PR 😉

[jrafanie]

LGTM, I'll merge it tomorrow morning