Move django-based uncloud to top-level

doc/README-how-to-configure-remote-uncloud-clients.org

@@ -0,0 +1,28 @@
+* 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