Page MenuHomePhorge

Deployment configs
ClosedPublic

Authored by mollekopf on Oct 11 2022, 12:07 AM.
Tags
  • Restricted Project
Referenced Files
Unknown Object (File)
Tue, Mar 5, 7:32 PM
Unknown Object (File)
Tue, Mar 5, 12:20 AM
Unknown Object (File)
Sat, Mar 2, 5:47 AM
Unknown Object (File)
Sat, Mar 2, 5:47 AM
Unknown Object (File)
Sat, Mar 2, 5:47 AM
Unknown Object (File)
Fri, Mar 1, 10:43 PM
Unknown Object (File)
Fri, Mar 1, 10:43 PM
Unknown Object (File)
Fri, Mar 1, 10:43 PM
Subscribers

Details

Summary

A bin/configure script copies everything deployment specific in the right locations.

Notes

  • We copy because symlinks don't work in docker containers where we sometimes only mount src/
  • Artisan commands + config could be included, but aren't atm.
  • The theme can be included via config/theme
  • The provided config works for the docker-compose localhost setup, I have another config for a localhost development setup via 127.0.0.1 where kolab4 runs on the host.
  • Most migrations where relatively straightforward to separate between seed/and regular migration, only 2022_05_13_100000_permissions_and_room_subscriptions.php was a bit more involved because it changes the schema, migrates existing data over, and then drops the old data. This is now solved by first running a seed-migration that create the new seed entry (deployment specific), and then run the schema change that generically moves existing data over.

Diff Detail

Repository
rK kolab
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 40286
Build 16313: arc lint + arc unit

Event Timeline

mollekopf created this revision.
mollekopf added a reviewer: Restricted Project.Oct 11 2022, 12:18 AM
mollekopf added a project: Restricted Project.

Deployment configs as a filesystem overlay

The configure.sh script does what .s2i/bin/assemble does, in that it copies the overlay over the repository.
For the default setup we provide config.local, for a production environment we use one of our theme repositories (after resturcturing like we did for kolabnow).

This migration thing is a mess and will be problematic in the future. I however have no better idea. We'll have to be very careful in the future. And this makes managing Kolab4 installation (and updates), if you are not Apheleia IT, very difficult.

I have one point that would have to be verified. You created some new migration files. Won't they all be executed when we deploy this change? I'm afraid they will, because the system will not find them in the migrations table, even though they have an old timestamp in the filename.

Specifically the problem might be with src/database/migrations/2022_05_13_090000_permissions_and_room_subscriptions.php. It probably should check if the SKUs already exist and not try to add them again if so. There's another problem with this migration file. It is not self-contained, i.e. it does not remove 'meet' SKU in up(), but does add it in down().

This migration thing is a mess and will be problematic in the future. I however have no better idea. We'll have to be very careful in the future. And this makes managing Kolab4 installation (and updates), if you are not Apheleia IT, very difficult.

I don't disagree ;-)

I have one point that would have to be verified. You created some new migration files. Won't they all be executed when we deploy this change? I'm afraid they will, because the system will not find them in the migrations table, even though they have an old timestamp in the filename.

I think you are correct, we either need to keep the old names or make sure no harm is done by running the migration again.

Specifically the problem might be with src/database/migrations/2022_05_13_090000_permissions_and_room_subscriptions.php. It probably should check if the SKUs already exist and not try to add them again if so. There's another problem with this migration file. It is not self-contained, i.e. it does not remove 'meet' SKU in up(), but does add it in down().

Specifically the problem might be with src/database/migrations/2022_05_13_090000_permissions_and_room_subscriptions.php. It probably should check if the SKUs already exist and not try to add them again if so. There's another problem with this migration file. It is not self-contained, i.e. it does not remove 'meet' SKU in up(), but does add it in down().

This should actually be fine.

2022_05_13_090000_permissions_and_room_subscriptions is part of the "local" config, and as such will not be deployed to kolabnow.
The problematic part is here: https://bifrost.kolabsystems.com/D3235, I suppose there we should simply remove those migrations as they serve no purpose there.

Stripping all the secrets will require some additional setup-procedure to generate them, so I'm not going to do that in this patch. The situation has not actually gotten worse because I just concatenated src/env.example and ansible/env.local into ansible/env.

Cleaned up .env files & follow symbolic links in configure.sh

This revision was not accepted when it landed; it landed in state Needs Review.Nov 16 2022, 4:27 PM
Closed by commit rKe5c1e3164a83: Deployment configs (authored by mollekopf). · Explain Why
This revision was automatically updated to reflect the committed changes.