Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[enh] Decouple the regen-conf mechanism from services #653
This is a rewriting of #480 because the original PR got stale after too many changes affecting the codebase as a whole (operation logs, error handling, ...)
N.B. : I intend to merge this for the 3.5 release ... Otherwise it's gonna be the same story all over again :/
Original problem :
Regen-conf is currently heavily coupled to the notion of services, and this is problematic / annoying for many reasons :
Decouple the regen-conf mechanism from the concept of services. To do this, the regen-conf related code was moved in a regenconf.py and file hashes are now stored in a regenconf.yml, independently from services.yml.
Of course that's a delicate operation since the regen-conf is one of the core feature of the core :o and a migration is required to properly handle this ... (which is why I ended up working on stretch-unstable to add a 6th migration)
The API also gets changed from
Nevertheless, after this we'll be able to safely add simple conf-regen hooks for new files without all the weird "pseudo-service" thing.
Still needs some heavy testing to make sure this doesn't break anything, but should be relatively stable so can be reviewed
How to test
Pull this branch ... the first time you run a regen-conf, it should automatically migrate. Though we also need to test postinstall and a "real-life upgrade" (which triggers the postinst script and so on)
referenced this pull request
Feb 18, 2019
I'm not 100% sure but shouldn't we ship a default regenconf.yaml file like we do for service for new installations? It won't be created since we don't run migrations on installation.
Or those this magic code is going to create it? 0ebbb83#diff-3cee47e1d870699f286cf66e3a4e04d9R67
Psycojoker left a comment
It's quite hard to review this PR as a whole since it's very big but I'm totally for this modification so we can move forward with it with more testing and so on.
(except if we did need a default "regenconf.yaml" ^^')
Ah yes indeed, we should probably do something explicitly during the postinstall. I forgot to look into this but I doubt that just 0ebbb83 will take care of it
Alrighty, ran a few tests and fixed a few things. Both the migration and fresh postinstall seem to work fine and behave as expected so it seems ready for testing.
As discussed in meetings a few weeks ago, I'm merging this as we're at the beginning of 3.6 so we'll have time to fully validate this in testing until the stable release