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	1797	0644	edit dl rm
cagefs.py	1853	0644	edit dl rm
clpro.py	868	0644	edit dl rm
files.py	933	0644	edit dl rm
limits.py	2924	0644	edit dl rm
linksafe.py	1797	0644	edit dl rm
lve.py	965	0644	edit dl rm
packages.py	3343	0644	edit dl rm
Readme.md	1645	0644	edit dl rm
services.py	2345	0644	edit dl rm
watcher.py	5057	0644	edit dl rm
__init__.py	3191	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.