ok
Direktori : /opt/cloudlinux/venv/lib64/python3.11/site-packages/clconfigure/ |
Current File : //opt/cloudlinux/venv/lib64/python3.11/site-packages/clconfigure/Readme.md |
# Overview This is a short overview of what is going on in this tool. ## Idea cloudlinux-reconfigure automatically updates system configuration according to "specification" of different editions. Right now "specifications" are defined in `spec/` package as python scripts with the only method `provision(...)`. There are some limitations that developers should stick to: - `provision` method *must* be able to configure server no matter what edition was installed previously. This means, e.g. if we make transition between `Admin` and `Solo` the latter is responsible for erasing `cloudlinux-admin-meta` package before installation of the `cloudlinux-solo-meta` ## Future Here are couple notes for the future ### Provisioning responsibilities Maybe we can add additional `deprovision` method which will be responsible for the cleanup of the edition that we are leaving. This will shift the responsibility e.g. of removing meta packages to the module which performed provisioning previously. On the other hand, it will increase migration time. ### Project structure We can consider grouping actions not by the `edition`, but by the `project`, e.g. ``` spec/ accelerate_wp/ provision(edition, ...) deprovision(edition, ...) cagefs/ provision(edition, ...) deprovision(edition, ...) lve-utils/ provision(edition, ...) deprovision(edition, ...) ``` ### Ansible? We can use ansible playbooks instead of python to describe provisioning. User-friendly playbooks with wide possibilities and also options like dry-run which allow us to draw nice-looking progress for user.