== Overview ==
As the stoney cloud actually tries to act as a collection of all aspects of a high availability cloud infrastructure, we have roughly three main sections:
* '''Infrastructure''': The basis of the whole ecosystem (Build Server, Binary Package Server, Mirror Server, Puppet Server, Operating System).
* '''stoney cloud''': The actual cloud with an easy to use multi-tenant web based interface.
* '''Self-Service Modules''': Modules that expand the functionality of the stoney cloud.
To make the base installation of the stoney cloud as small and simple as possible, everything is as modularised as possible.
== Requirements ==
Core=== Infrastructure ===* User, Customer, Reseller* Roles The article [[Gentoo Infrastructure]] describes how use gentoo as an infrastructure backbone for creating a complete 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 <code>sstUseSelfcare</code>. This must be set for every single personmodern IT architecture.
Modules=== stoney cloud ===The main framework called [[: Service/Product specificCategory:stoney core|stoney core]] is responsible for shared functionality.* Online Backup (The basic installation and configuration of the initial stoney backupcloud components (OpenLDAP server, Apache web server, GlusterFS, ...).* Mail Hosting (stoney mail)Reseller, customer and user management.* VM-Manager (stoney conductor)Roles and rights management.* VM-Manager light (stoney vm): Start, stop, access a VMBilling functionality.* Searching functionality.* A consistent look and feel between modules.* Internationalization.
GitHubThis functionality is accessible via:* Form follows functionA [[: we choose Category:REST_API|REST API]], which serves as the functionality name (so we are backwards compatible)data and business logic abstraction layer and uses JSON as the primary data interchange format.
== Module Naming ==This [[:Category:REST_API|REST API]] is currenty accessible via:The names of the modules are derived from the service functionality* A '''c'''ommand '''l'''ine '''i'''nterface. They are different from the marketing names* An Ajax based web interface. These marketing names should be configurable per reseller. Needs * Any scripting language which supports a schema modificationREST API and JSON.
=== Self-Service Modules ===
* selfThe [[:Category:Self-serviceService Modules|Self-backup Service Modules]] expand the initial stoney cloud functionality. Some examples:* [[:Category:stoney conductor|stoney conductor]]: A cloud and virtual machine management tool (on-line backup modulestorage, marketing name is network, cpu, memory, virtual machines, backups, snapshots, ...).* [[:Category:stoney backupvm|stoney backupvm]]: A simplified sub set of the [[:Category:stoney conductor|stoney conductor]] functionality (start, stop, access a virtual machine).* self-service-storage ([[:Category:stoney backup|stoney backup]]: An on-line storage modulebackup service for desktops, marketing name is servers and virtual machines.* [[:Category:stoney boxmail|stoney boxmail]]: A mail service with optional collaboration functionality (based on Open-Xchange).* self-service-web[[:Category:stoney monitor|stoney monitor]]: Monitoring (with Zabbix).* [[:Category:stoney orchestra|stoney orchestra]]: Configuration Management (self-service-databasewith Puppet) .* [[:Category:stoney box|stoney box]]: An on-> may be part of self-line storage service-web(Webbrowser access via HTTPS, WebDAV via HTTPS and synchronisation to multiple devices).* self-[[:Category:stoney web|stoney web]]: Web & Database hosting service-dns (currently API code onlybased on Apache and MariaDB).
=== Provisioning Self-Service Modules Naming ===* prov-web-apache* prov-database-mariadb* prov-database-mysql* prov-database-postgresql* prov-dns-powerdns* prov-backup-kvm* prov-backup-rsnapshotThe names of the modules are derived from the service functionality. These can be different from the marketing names. These marketing names must configurable per reseller and per customer.
== GitHub ==
Proposed directory structure The [[Release Management]] page gives you a nice overview about Release Cycles, Versioning and Development Procedure. The chapter [[Release_Management#Source_Code_Organization |Source Code Organization]] describes nicely, where the code is located on [https://github.com/stoney-cloud/ GitHub].
=== Directory Structure Self-Service Module ===The following directory structure is proposed:
<pre>
/data api # /data/ldif # LDAP: loadREST Application Programming Interface.ldif/api cli # 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 niceA command Line Interface, if which uses the configuration files could be outside the web root (htdocs), so that a miss-configuration of /api/... # the web server does not lead REST API to password leaksread or write data./web helpers # Web Interface (HTML/JS/CSSHelper scripts and programmes, uses API): gui.js/web/... # /cli # CLI like notifications (Pythonquota, Perlbackup failed, PHPrsnapshot, Bash with curl ... uses API): api.sh/cli/provisioning # Scripts and programmes to provision services... # /test web # Tests (GUI, Unit-Tests, ...): testAjax based web interface.xml/test/README... md # A simple readme file containing an overview and how to install as the absolute minimum.
</pre>
It would be nice to be able Every sub folder must contain (where applicable):* A simple readme file containing an overview and how to install new modules without as the need absolute minimum.* Structure according to modify best practice of the main programming language or framework (a separation of configuration fileand code would be nice). Maybe with single configuration files per module? Or do you have other suggestions?* Use [http://wwwTests (Unit-Tests, Test-Cases, Test-Data, .memcached.org/ memcached]?.).* Use a file with one include per module?Documentation.
=== Directory Structure Provisioning Module provisioning ===Example for prov-backup-rsnapshot:The following shows how a '''provisioning''' directory structure could look like.
<pre>
/bin helpers # Helper Scriptsscripts and programmes, like notifications (quota, backup failed, rsnapshot, ...): helper.pl/etc helpers/bin # ConfigurationBinary / executable scripts and programmes./etc/Provsioning #helpers/etc/Provsioning/Backup #Configuration files and directories./etchelpers/Provsioning/Backup data #/lib # Provisioning Perl-Modules Data used for a dedicated Service: KVMthe helpers.pm or rsnapshot.pm/libhelpers/perl #data/lib/perl/Provisioning data.ldif #The actual data, in this case a ldif file./lib/perl/Provisioning/Backup #/lib/perl/Provisioning/Backup/Rsnapshot # /libexec #helpers/test # Tests (CLI, Unit-Tests, ...): test.sh/helpers/README.md # A simple readme file containing an overview and how to install as the absolute minimum.
</pre>
[[Category:Development]][[Category:Documentation]]