Difference between revisions of "User:Michael"

Revision as of 14:46, 14 October 2013

CV

Michael Eichenberger, CEO of stepping stone GmbH, has in-depth knowledge in the conception, design and implementation of complex hard- and software systems. He has designed and implemented large infrastructures built upon Open Source Software. In 2004 he founded the company stepping stone GmbH to offer a range of secure and flexible operating system independent services. During the last few years he has been responsible for the architecture and development of the FOSS-Cloud.

Notes

Allerlei

• Modul Installer: Default ist lediglich das stoney clore (self-care) Interface für die Mandanten.
• API und Beschrieb für alle Funktionalitäten -> CAF
• Rollen pro Modul
• Module: Virtualization, Backup, Storage, Mail, ... (jeweils mit LDIFs, PHP-Code, Provisioning Daemons, ...)
• Daemon für: Load-Balancing, Maintenance und Backup
• Catalogue
• Collections (eine Sammlung von VM-Templates) aufnehmen.
• Customer version (the customer has access to the stoney safe web interface)
• Let the reseller change the configuration an maybe the defaults too.

Website

• Highlights: Firewall, Skalierbarkeit, Mandantenfähigkeit, Mehrere Disks, Hotplugging von CPUs, Memory, Disks, ...
• Architektur: Redundanz, Updates, Package Server, ...
• Downloads: ISO, Packete
• Erweiterungen: Backup, Storage, Mail, ...
• Lizenz: Dual-License (ev. mit ProxMox als Beispiel?)
• Geschichte
• Roadmap
• Verkauf von Dienstleistungen wie Support, Weiterentwicklung und ähnliches

Workshop

• sstRoles (neu uid statt sstRole) müssen neu eine UID haben und den Namen nur noch als descripton (ähnlich wie sstGroupName) erhalten.
• Die default Gruppen und default Rollen dürfen keine resellerUID und keine customerUID besitzen. So sind sie für all aktiv.
• Wenn eine sstRole von jemandem angepasst werden soll, wird eine Kopie erstellt und eine Zusweisung an resellerUID und ev. auch an eine customerUID gemacht.
• sstIsActive muss überall gesetzt sein (TRUE oder FALSE).
• Ableitung (parentFlag, parentID) muss zwingend gesetzt sein, damit ich so eine globale Rolle oder Gruppe für einen Kunden oder Reseller auf deaktiv (sstIsActive auf FALSE) setzen kann.
• Per Default sind alle globalen Rollen und Gruppen aktiv.
• Bereiche (Sektionen) ist im Directory noch nicht definiert.

# Default Roller "VM Backup"
ou=roles,dc=foo-cloud,dc=org
uid=1234567,ou=roles,dc=foo-cloud,dc=org
sstRoleName: VM Backup
sstMethod: ou=create,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
sstMethod: ou=delete,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
sstIsActive: TRUE

# Hiermit wir die Default Rolle "VM Backup" durch eine eigene Rolle überschrieben.
ou=roles,dc=foo-cloud,dc=org
uid=1234568,ou=roles,dc=foo-cloud,dc=org
sstRoleName: VM Backup
sstMethod: ou=create,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
sstBelongsToResellerUID: 4000000
sstIsActive: TRUE
sstParentRole: 1234567

# Damit wird die "VM Backup" Rolle nicht mehr angezeigt (und ist dadurch auch nicht mehr nutzbar).
ou=roles,dc=foo-cloud,dc=org
uid=1234569,ou=roles,dc=foo-cloud,dc=org
sstRoleName: VM Backup
sstBelongsToResellerUID: 4000001
sstIsActive: FALSE
sstParentRole: 1234567

ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
ou=create,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
ou=delete,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org

• sstIsActive sollte mindestens bei allen Personen hinzugefügt werden. Eventuell auch bei anderen Services?

API Ziele:

• Jedes Modul liefert zur jeder Funktion (Methode) automatisch eine API (XML, JSON, ...).
• Jedes Modul muss vom GUI her die gleichen Funktionen wie die API benutzen.
• Der vm-manager stellt die API zur Verfügung, der fc-brokerd die Steuer-Logik und er nutzt die API vom vm-manager.

Wir (Danny) bauen einen Beispiel Modul. Online Backup mit Provisionierung (Web durch Danny, Provsionung durch SST)-

Kriegen wir die Anpassungen am Schema und LDAP noch in die Version 1.2.0 einfliessen lassen?

Netzwerk für die globale FOSS-Cloud muss in den globalen Teil des Selfcares kommen.

Offene Frage:

• Wie gehen wir damit um, wenn wir einen Storage und/oder VM-Pool niemandem zuweisen und danach eine VM einem unserer Kunden, respektive einem Kunden eines Resellers zuweisen möchten?
  • Beispiel Konstellation:
    • Service Provider: stepping stone GmbH
    • Wiederverkäufer: LIMBAS GmbH -> Kriegt monatliche Rechung von der stepping stone GmbH, stellt Rechnung an devroom
    • Kunde: devroom
  • Situation Heute: Mitarbeiter der stepping stone GmbH (Service Provider) erstellen VM aus Template für devroom im Auftrag von der LIMBAS GmbH.
  • Ziel: Da ich zur Zeit nur einzelne VMs und/oder Templates verkaufen möchte/kann, soll zukünftig der Wiederverkäufer LIMBAS GmbH und/oder sein Kunde devroom selber VMs und/oder Templates erstellen können. Dies im allgemeinen Storage und/oder VM-Pool. Die Kosten davon werden durch den Verkauf der VMs/Templates getragen. Der Wiederverkäufer und Kunde sollten zukünftig VMs aus dem Katalog beziehen können.
• API müsste neu die Funktionalität CreateVMFromPublicPool erstellen:
  • Neue Attribute:
    • sstAllowResellerUID
    • sstAllowCustomerUID
    • sstAllowPersonUID
  • Bei 0 hat jeder Zugriff, ansonsten multi-valued Attribute mit den jeweiligen UIDs.

Nicht vergessen: Sicherstellen, dass wir Services für Wiederverkäufer und/oder Kunden "unsichtbar" machen können.

Modul:

• Modul-spezifisches Schema: Kann ich *.schema ins slapd.conf einlesen (bedingt natürlich einen Neustart). Hier Umstellung auf LDIF statt Datei. Aufwandschätzung?
• Modul-spezifisches LDIF(-Template): In Abhängigkeit vom Modul-spezifischen Schema
• Modul-spezifische Konfigurations-Datei (falls wirklich nötig, optimalerweise wäre dies alles im LDAP):
• Modul-Code: Der Code besteht im Minimum aus dem Selfcare Code (PHP) und je nach Aufgabe noch aus Provisionierungs-Code (meist Perl oder C++).
• Modul-Installer: Shell basierten Installer, welche obige Punkte provisioniert.

Implementirung neuer Services:

• Ein ganz neuer Service muss vom Superuser (SP) implementiert werden und für die Reseller/Kunden zur Verfügung gestellt werden. Die Implementierung beinhaltet das Installieren des Produktes, die Schemaerweiterung im LDAP und die Provisionierung der Berechtigungen. Produkte welche der Reseller/Kunde noch nicht aboniert hat, sollen abgegraut angezeigt werden.

Netzwerk:

• Global wird vom SP im SCI der Netzwerkrange festgelegt und dem Reseller zugeteilt, welcher wiederum dem Kunden einen Range zuteilt, welcher seinen Range in der FC für die Virtualisierung verwenden kann.

Das Rollenmodell:

• Die Rollen sind im LDAP abgebildet. Was welche Rolle was darf ist im Source Code abgebildet und muss noch ins LDAP.

Arbeitspacket 2

• Superuser wird nicht im GUI zugewiesen (aktuell geschieht dies direkt im OpenLDAP Verzeichnis).
• Die sstRole wird mit UID versehen und das Active Flag wird benutzt, wenn der Reseller die Rolle nicht verwenden will. Zudem braucht es ein Parent flag, damit wenn der Name verändert wird, abgeleitet werden kann, woher die Rolle kommt. Die Schemaerweiterung soll noch in die Version 1.2.0.

API:

• Das API wird in PHP geschrieben und kann über web-url's aufgerufen (REST/SOAP).