FM / clconfigure

/opt/cloudlinux/venv/lib/python3.11/site-packages/clconfigure/

/opt/cloudlinux/venv/lib/python3.11/site-packages/clconfigure

Name	Size	Mode	Actions
cli/	-	0755	rm
spec/	-	0755	rm
__pycache__/	-	0755	rm
awp.py	1805	0644	edit dl rm
cagefs.py	1853	0644	edit dl rm
clpro.py	867	0644	edit dl rm
files.py	904	0644	edit dl rm
limits.py	2867	0644	edit dl rm
linksafe.py	1398	0644	edit dl rm
lve.py	1040	0644	edit dl rm
packages.py	2675	0644	edit dl rm
Readme.md	1645	0644	edit dl rm
services.py	2384	0644	edit dl rm
watcher.py	5144	0644	edit dl rm
__init__.py	2865	0644	edit dl rm

Edit: /opt/cloudlinux/venv/lib/python3.11/site-packages/clconfigure/Readme.md (1645B)

# 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.

# 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.