Modularisation

From stoney cloud
Revision as of 09:52, 24 December 2013 by Michael (Talk | contribs)


Jump to: navigation, search

Requirements

Core

  • User, Customer, Reseller
  • Roles and rights
  • Billing
  • Forgot Password
  • ...
  • Each reseller (and maybe the customer) entry needs a default flag, which tells us, if a customer or person is allowed to log in (maybe we need two flags). Use sstUseSelfcare. This must be set for every single person.

Modules: Service/Product specific:

  • Online Backup (stoney backup)
  • Mail Hosting (stoney mail)
  • VM-Manager (stoney conductor)
  • VM-Manager light (stoney vm): Start, stop, access a VM.

GitHub:

  • Form follows function: we choose the functionality name (so we are backwards compatible)

Module Naming

The names of the modules are derived from the service functionality. They are different from the marketing names. These marketing names should be configurable per reseller. Needs a schema modification.

Self-Service Modules

  • self-service-backup (on-line backup module, marketing name is stoney backup)
  • self-service-storage (on-line storage module, marketing name is stoney box)
  • self-service-web
  • (self-service-database) -> may be part of self-service-web
  • self-service-dns (currently API code only)

Service Modules

  • prov-web-apache
  • prov-database-mariadb
  • prov-database-mysql
  • prov-database-postgresql
  • prov-dns-powerdns
  • prov-backup-kvm
  • prov-backup-rsnapshot

GitHub

Proposed directory structure on GitHub.

Directory Structure Self-Service Module

/data             # 
/data/ldif        # LDAP: load.ldif
/api              # API (PHP): api.php
/api/...          # Structure from CWI according to best practice from the Yii-Framework (a separation of configuration and code would be nice).
/api/...          # It would be nice, if the configuration files could be outside the web root (htdocs), so that a miss-configuration of 
/api/...          # the web server does not lead to password leaks.
/web              # Web Interface (HTML/JS/CSS, uses API): gui.js
/web/...          # 
/cli              # CLI (Python, Perl, PHP, Bash with curl ... uses API): api.sh
/cli/...          # 
/test             # Tests (GUI, Unit-Tests, ...): test.xml
/test/...         # 

It would be nice to be able to install new modules without the need to modify the main configuration file. Maybe with single configuration files per module? Or do you have other suggestions?

  • Use memcached?
  • Use a file with one include per module?

Directory Structure Service Module

Example for service-backup-rsnapshot:

/bin                                    # Helper Scripts, like notifications (quota, backup failed, rsnapshot, ...): helper.pl
/etc                                    # Configuration
/etc/Provsioning                        #
/etc/Provsioning/Backup                 #
/etc/Provsioning/Backup                 #
/lib                                    # Provisioning Perl-Modules for a dedicated Service: KVM.pm or rsnapshot.pm
/lib/perl                               #
/lib/perl/Provisioning                  #
/lib/perl/Provisioning/Backup           #
/lib/perl/Provisioning/Backup/Rsnapshot # 
/libexec                                #
/test                                   # Tests (CLI, Unit-Tests, ...): test.sh