User:Michael - Revision history

Michael: /* Notes */

2013-10-14T13:47:03Z

Notes

← Older revision		Revision as of 15:47, 14 October 2013
Line 73:		Line 73:
	* Der vm-manager stellt die API zur Verfügung, der fc-brokerd die Steuer-Logik und er nutzt die API vom vm-manager.		* 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 stoney cloud muss in den globalen Teil des Selfcares kommen.

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

Michael: /* Notes */

2013-10-14T13:46:23Z

Notes

← Older revision		Revision as of 15:46, 14 October 2013
Line 24:		Line 24:
	* Verkauf von Dienstleistungen wie Support, Weiterentwicklung und ähnliches		* Verkauf von Dienstleistungen wie Support, Weiterentwicklung und ähnliches

	sstRoles (neu uid statt sstRole) müssen neu eine UID haben und den Namen nur noch als descripton (ähnlich wie sstGroupName) erhalten.		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.		* 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.		* 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).
	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.
	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.		* <span style="color:red">Bereiche (Sektionen) ist im Directory noch nicht definiert.</span>

	Per Default sind alle globalen Rollen und Gruppen aktiv.

	<span style="color:red">Bereiche (Sektionen) ist im Directory noch nicht definiert.</span>

	<pre>		<pre>
Line 70:		Line 66:
	</pre>		</pre>

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

	~~Die Default Personen sollen als Sprache nur noch en (statt en-GB).~~

	API Ziele:		API Ziele:

Michael: /* Notes */

2013-10-14T13:45:16Z

Notes

← Older revision		Revision as of 15:45, 14 October 2013
Line 23:		Line 23:
	* Roadmap		* Roadmap
	* Verkauf von Dienstleistungen wie Support, Weiterentwicklung und ähnliches		* Verkauf von Dienstleistungen wie Support, Weiterentwicklung und ähnliches

			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?

			Die Default Personen sollen als Sprache nur noch en (statt en-GB).

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

Michael at 12:28, 14 October 2013

2013-10-14T12:28:44Z

← Older revision		Revision as of 14:28, 14 October 2013
Line 1:		Line 1:
	Michael Eichenberger, CEO, stepping stone GmbH		== 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.

	~~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~~.		== 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

Michael at 17:32, 26 May 2013

2013-05-26T17:32:42Z

← Older revision		Revision as of 19:32, 26 May 2013
Line 1:		Line 1:
			Michael Eichenberger, CEO, stepping stone GmbH

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

Michael: 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..."

2013-05-26T17:32:17Z

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

New page

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.