29 lines
1.7 KiB
Org Mode
29 lines
1.7 KiB
Org Mode
* What is a remote uncloud client?
|
|
** Systems that configure themselves for the use with uncloud
|
|
** Examples are VMHosts, VPN Servers, cdist control server, etc.
|
|
* Which access do these clients need?
|
|
** They need read / write access to the database
|
|
* Possible methods
|
|
** Overview
|
|
| | pros | cons |
|
|
| SSL based | Once setup, can access all django parts natively, locally | X.509 infrastructure |
|
|
| SSH -L tunnel | All nodes can use [::1]:5432 | SSH setup can be fragile |
|
|
| ssh djangohost manage.py | All DB ops locally | Code is only executed on django host |
|
|
| https + token | Rest alike / consistent access | Code is only executed on django host |
|
|
| from_django | Everything is on the django host | main host can become bottleneck |
|
|
** remote vs. local Django code execution
|
|
- If manage.py is executed locally (= on the client), it can
|
|
check/modify local configs
|
|
- However local execution requires a pyvenv + packages + db access
|
|
- Local execution also *could* make use of postgresql notify for
|
|
triggering actions (which is quite neat)
|
|
- Remote execution (= on the primary django host) can acess the db
|
|
via unix socket
|
|
- However remote execution cannot check local state
|
|
** from_django
|
|
- might reuse existing methods like celery
|
|
- reduces the amount of things to be installed on the client to
|
|
almost zero
|
|
- follows the opennebula model
|
|
- has a single point of failurebin
|