Changes

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* ..modern 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 safecloud 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.

=== Selfcare Module Self-Service Modules ===* selfcareThe [[:Category:Self-backup (onService Modules|Self-line backup module, marketing name is Service Modules]] expand the initial stoney safe)cloud functionality. Some examples:* selfcare-[[:Category:stoney conductor|stoney conductor]]: A cloud and virtual machine management tool (storage , network, cpu, memory, virtual machines, backups, snapshots, ...).* [[:Category:stoney vm|stoney vm]]: A simplified sub set of the [[:Category:stoney conductor|stoney conductor]] functionality (start, stop, access a virtual machine).* [[:Category:stoney backup|stoney backup]]: An on-line storage modulebackup service for desktops, marketing name is servers and virtual machines.* [[:Category:stoney boxmail|stoney mail]]: A mail service with optional collaboration functionality (based on Open-Xchange).* selfcare-web[[:Category:stoney monitor|stoney monitor]]: Monitoring (with Zabbix).* [[:Category:stoney orchestra|stoney orchestra]]: Configuration Management (selfcare-databasewith Puppet) -> may be part of web-web.* selfcare[[:Category:stoney box|stoney box]]: An on-dns line storage service (currently API code onlyWebbrowser access via HTTPS, WebDAV via HTTPS and synchronisation to multiple devices).* [[:Category:stoney web|stoney web]]: Web & Database hosting service (based on Apache and MariaDB).

=== Self-Service Modules Naming ===* The names of the modules are derived from the servicefunctionality. These can be different from the marketing names. These marketing names must configurable per reseller and per customer. Naming Convention for Provisioning modules belonging to a Self-webService module:* prov-<SERVICE>-apache<TYPE>* service* prov-databasemail-mariadbox* service* prov-databasebackup-mysqlkvm* service* prov-databasebackup-postgresqlrsnapshot* service* prov-dnsmonitoring-powerdnszabbix* service* prov-backupconfiguration-kvmmanagement-puppet === Self-Service Modules Installation ===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?* serviceUse [http://www.memcached.org/ memcached]?* Use a file with one include per module? === Self-backupService Modules Splitting ===The [[:Category:Self-Service Modules|Self-Service Modules]] are split into different parts, based on their functionality:* '''api''': REST Application Programming Interface.* '''cli''': A command Line Interface, which uses the REST API to read or write data.* '''docs''': The self-service module documentation.* '''helpers''': Helper scripts and programmes, like notifications (quota, backup failed, rsnapshot, ...).* '''prov-<SERVICE>-<TYPE>''': Scripts and programmes to provision services.* '''web''': Ajax based web interface. Where nothing else is defined, the following rules apply:* All source code is hosted on [https://github.com/stoney-cloud GitHub]. See the the [[#GitHub | GitHub]] chapter below for more information.* Version control via Git, according to [http://nvie.com/posts/a-successful-git-branching-model/ Git flow]. TBD.* Bug & Enhancement Tracking via GitHub (reproduction of the sprints on GitHub).* PHP Coding-Standards according to [http://symfony.com/doc/current/contributing/code/standards.html Symfony Coding Standards], otherwise fall-back to [http://www.php-fig.org/psr/psr-2/ PSR-2].* Unit Tests according [http://phpunit.de/ PHPUnit] (like to [http://symfony.com/doc/current/book/testing.html Symfony]).* Versions schema according [http://semver.org/ Semantic Versioning]. TBD* Programming languages:** '''api''': Symfony.** '''cli''': Bash or Perl.** '''helpers''': Bash or Perl. Other languages possible.** '''prov-<SERVICE>-<TYPE>''': Perl** '''web''': JavaScript Framework AngularJS (with HTML5).

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].

/data api # REST Application Programming Interface./cli # A command Line Interface, which uses the REST API to read or write data/ldif # LDAP: load.ldif/api docs # API (PHP): apiThe self-service module documentation.php/api/... examples # Structure from CWI according to best practice from the Yii-Framework (a separation Example scripts for proof of configuration concept and code would be nice)similar scripts./api/... helpers # It would be niceHelper scripts and programmes, if the configuration files could be outside the web root like notifications (htdocs)quota, backup failed, rsnapshot, so that a miss-configuration of /api/... # the web server does not lead to password leaks)./web provisioning # Web Interface (HTML/JS/CSS, uses API): guiScripts and programmes to provision services.js/web/... schema # /cli # CLI (PythonDescription, Perl, PHP, Bash with curl ... uses validation specification and documentation of the REST API): api.sh/cli/web # Ajax based web interface... # /test LICENSE # Tests (GUI, UnitThe license the self-Tests, service module is released under...): test.xml/test/README.md # A simple readme file containing an overview and how to install as the absolute minimum.. #

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:A test directory (Unit-Tests, Test-Cases, Test-Data, ...).* Documentation. === helpers ===The following shows how a '''helpers''' directory structure could look like.<pre>/helpers # Helper scripts and programmes, like notifications (quota, backup failed, rsnapshot, ...)./helpers/bin # Binary /wwwexecutable scripts and programmes.memcached/helpers/etc # Configuration files and directories.org/ memcached]?helpers/data # Data used for the helpers.* Use /helpers/data/data.ldif # The actual data, in this case a ldif file with one include per ./helpers/test # Tests (CLI, Unit-Tests, ...)./helpers/README.md # A simple readme file containing an overview and how to install as the absolute minimum.</pre> === schema ===The following shows how a '''schema''' directory structure could look like.<pre>/schema # Description, validation specification and documentation of the REST API./schema/core.schema.json # Every module?has a master file, which includes all json files (the name is derived from the Git Repo module name)/schema/base.schema.json # Type definitions./schema/reseller.schema.json # Per resource on file./schema/people.schema.json # /schema/README.md # Information how the schema file(s) can be used and how the documentation can be extracted.</pre>

=== Directory Structure Service Module prov-<SERVICE>-<TYPE> ===Example for serviceThe following shows how a '''prov-<SERVICE>-<TYPE>''' directory structure could look like. The following example is done with '''prov-backup-rsnapshot:'''.

/bin prov-backup-rsnapshot # Helper Scripts, like notifications (quota, and programmes to provision services./prov-backup failed, -rsnapshot, ...): helper/bin # Binary / executable scripts and programmes.pl/prov-backup-rsnapshot/etc # Configurationfiles and directories./prov-backup-rsnapshot/etc/Provsioning #/etc/Provsioning/Backup #prov-backup-rsnapshot/etc/Provsioning/Backup #/prov-backup-rsnapshot/lib # Provisioning Perl-Modules for a dedicated Service: (for example KVM.pm or rsnapshot.pm)/prov-backup-rsnapshot/lib/perl #/prov-backup-rsnapshot/lib/perl/Provisioning #/prov-backup-rsnapshot/lib/perl/Provisioning/Backup #/prov-backup-rsnapshot/lib/perl/Provisioning/Backup/Rsnapshot # /prov-backup-rsnapshot/libexec #/prov-backup-rsnapshot/test # Tests (CLI, Unit-Tests, ...): test.sh/prov-backup-rsnapshot/README.md # A simple readme file containing an overview and how to install as the absolute minimum.

[[Category:Development]][[Category:Documentation]]