Meeting in Nice, 30 and 31 May 2011
Participants
- UPD: Pietro Abate, Roberto Di Cosmo, Ralf Treinen, Stefano Zacchiroli
- Mandriva: Stephane Lauriere, Jean Parpaillon
- Focus: Gianluigi Zavattaro, Davide Sangiorgi, Maurizio Gabbrielli, Jacopo Mauro, Ornela Dardha, Michael Lienhardt, Cosimo Laneve
- I3S: Jean-Charles Régin, Michel Rueher, Claude Michel, Arnaud Malapert, Mohammed Rezgui
Location
Room Y 106 - Byron Blanc - ground floor of Byron building
INRIA Sophia-Antipolis
2004 route des Lucioles - BP 93
06902 Sophia Antipolis
FOCUS secretary: Nathalie Woodward
GIGIO's mobile: +39 333 8648442
Agenda
| 1st day, 30 May 2011 | 2nd day, 31st May 2011 |
|---|---|
9h00-9h30 Arrival of the participants 12h15-14h Lunch break 14h-14h45 I3S | 9h15-11h15 Discussion and collaboration 13h00-14h45 Lunch break 14h45-16h00 Wrap-up of the discussion |
May 30
See also:
Introduction
IaaS provides a virtual infrastructure but the software deployment, (re)configuration, maintenance remains to be achieved by the admin. On the other hand, there is a need for scale up/scale down. This dynamicity may require to:
- create a new VM
- create a new service
- install a new package
- move a piece of application from one side to another one
- etc.
What is missing: a high-level automatic engine for reconfiguring a Cloud.
| Input | Solver | Output |
|---|---|---|
The engine takes the following input: a request for reconfiguring. This request may come from a sysadmin or from high-level Cloud controller. The following information is required describing the current status:
| Solvers/Planners are needed for finding a solution to the reconfiguration request, given the current system description. | A deployment plan. |
Example:
| Input | Output |
|---|---|
| Allocate 23 extra Tomcat servers and make sure these servers are not allocated to servers where Apache is already running. |
|
Things have moved since the infancy of the project, in IaaS and PaaS, in particular:
- IaaS: OpenStack (replacing Eucalyptus)
- PaaS:
- Industry oriented: VMware Cloud (VMC) (CloudFoundry), Ensemble (see Ubuntu). The VMC provides a low-level deployment language. Ensemble (not much documentation) is "a high level next generation 'service orchestration' framework. It aims at being APT for the cloud" https://wiki.ubuntu.com/Ensemble. Ensemble contains hacks and does not allow to manage multiple services on a single (virtual) machine.
- Research oriented: Fractal (VAMP paper)
CompatibleOne state of the art
Slides:
No cloud engine deals with what's inside a VM: distributions, packages, services.
A high-level Cloud taxonomy has been drafted by Nexedi: http://www.slapos.org/P-VIFIB-Default.Category.Configuration/view.
SNMP is not limited to hardware or network. SNMP does not contain yet a MIB describing packages but a MIB covering software components was proposed by Jean within the CompatibleOne project. THe "Host Resources" MIB could be extended for this purpose.
First ideas on a Cloud description model
Puppet declarative language
Scope: Puppet describes as a closed world the configuration of a single machine. mcollective aims at helping managing pools of VMs, under the management of the PuppetLabs company.
- Resource types: packages, services, files
- Relationships: two kinds of relationships between resources: notify and require. Notify is an extension of the require relationship. If a resource is modified during the lifecycle of the system, an action will be performed. The 'notify' relationship introduces temporal constraints (note: see also the pre-depend and break relationships in Debian).
Puppet does not provide a syntax for disjunctions (ensure package A or B is installed). There is no generic predicates on versions: only specific versions.
Once the configuration is described, Puppet can deploy it. Puppet can check the current state, compute the desired state, then the actions to be executed on the current state to move it to the target state.
Flip-flop effect in case of package conflicts -> no deterministic configuration in the target state. Knowledge about conflicts is needed for taking the right configuration decision.
Roberto: real requests can easily lead to such conflicts. e.g exim / postfix conflict
zack: Puppet is a programming language for system administrators. The validation step of the plan could be delegated to an external software before getting deployed.
Roberto: Extra details could be added, to be passed to the solvers. You produce a plan and Aeolus converts it to a recipe that is compatible with the Puppet language.
Roberto: There is a need for more high-level actions: connect/disconnect, bind/unbind (e.g: bind an application to a specific database).
Scope: Puppet describes as a closed world the configuration of a single machine. mcollective aims at helping managing pools of VMs, under the management of the PuppetLabs company.
- Resource types: packages, services, files
- Relationships: two kinds of relationships between resources: notify and require. Notify is an extension of the require relationship. If a resource is modified during the lifecycle of the system, an action will be performed. The 'notify' relationship introduces temporal constraints (note: see also the pre-depend and break relationships in Debian).
Puppet does not provide a syntax for disjunctions (ensure package A or B is installed). There is no generic predicates on versions: only specific versions.
Once the configuration is described, Puppet can deploy it. Puppet can check the current state, compute the desired state, then the actions to be executed on the current state to move it to the target state.
Flip-flop effect in case of package conflicts -> no deterministic configuration in the target state. Knowledge about conflicts is needed for taking the right configuration decision.
Roberto: real requests can easily lead to such conflicts. e.g exim / postfix conflict
zack: Puppet is a programming language for system administrators. The validation step of the plan could be delegated to an external software before getting deployed.
Roberto: Extra details could be added, to be passed to the solvers. You produce a plan and Aeolus converts it to a recipe that is compatible with the Puppet language.
Roberto: There is a need for more high-level actions: connect/disconnect, bind/unbind (e.g: bind an application to a specific database).
Possibility to introduce a new relationship: "imply", which means that the implied action should be performed after the requested action, while the required action should be performed before the requested action.
Davide: representation of the automata using Petri nets?
May 31
Arnaud Malapert: survey of solver technology for Aeolus
Overview of Constraint Programming, Mixed Integer Linear Programming and various open source tools available for each of them.
Related problems: d-dimensional bin packing as a common tool to model pcking of services on VMs or VMs on hosts.