Difference between revisions of "User:Michael"
From stoney cloud
(Created page with "Michael Eichenberger has in-depth knowledge in the conception, design and implementation of complex hard- and software systems. He has designed and implemented large infrastru...") |
(→Notes) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | Michael Eichenberger 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. | + | == 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. | ||
+ | * <span style="color:red">Bereiche (Sektionen) ist im Directory noch nicht definiert.</span> | ||
+ | |||
+ | <pre> | ||
+ | # 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 | ||
+ | </pre> | ||
+ | <pre> | ||
+ | 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 | ||
+ | </pre> | ||
+ | |||
+ | * 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. | ||
+ | |||
+ | |||
+ | * Netzwerk für die globale stoney 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. <span style="color:red">Aufwandschätzung? </span> | ||
+ | * 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. <span style="color:red">Die Schemaerweiterung soll noch in die Version 1.2.0.</span> | ||
+ | API: | ||
+ | * Das API wird in PHP geschrieben und kann über web-url's aufgerufen (REST/SOAP). |
Latest revision as of 14:47, 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.
- Netzwerk für die globale stoney 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.
- Beispiel Konstellation:
- 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.
- Neue Attribute:
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).