Project meeting in Grenoble, 2007

From SELFMAN Wiki

This project meeting discussed various deliverables and progress of the partners.

D1.2: [UCL|INRIA|KTH] - define basic actuator and sensor services: - SON monitoring: global monitoring -> notification service (input from INRIA) (input from UCL:P2PS belief propagation) - ACTUATION: installation API, turns nodes into hosts for installing components. (pseudo reliable broadcast) (KTH|UCL) - leverage Grid4All contribution (identity, etc.) (KTH|INRIA)

D1.3b: [NUS] - wrap-up D1.3a and refer to T4.4 - explain and motivate the WP4 approach for self-protection T1.3 - to add security into APis - integrating/use small-world SONs

D1.4: [KTH] - J2EE turns into Java - provide TBN prototype in Java

D1.5: [UCL] - provide P2PS prototype in Oz

D2.1b: [INRIA|KTH] - describe the computational model starting from Fractal - additional elements specifying execution structure: - TBN - Oz/K - map semantic aspects between Fractal and TBN (Fractal + precise execution model events (Java + Oz)) - sort out terminology aspects

D2.1c: [KTH] - implementation of D2.1b - match implementations between TBN and Fractal/Julia - Julia integrated with TBN implementation

D2.2a: [nobody] - we acknowledged coments and we'll feed them into D2.2c

D2.2b: [INRIA|FT|everyone else] - describe set of facilities: Probes + configuration commands + installation (as sensors and actuators) - explain that components are basic blocks for sensors and actuators - document patterns of control for the 3 applications -> basic layer with comp model, tool and also design patterns for self-managing stuff (indentify commonalities between 3 apps)

D2.3b: [INRIA|UCL|KTH] - direct operational semantics for TBN maybe by translation to Oz/K - direct operational semantics for Oz/K v2

D3.1b: [ZIB|KTH] - report the new algorithm for transaction

D3.2a: [ZIB|KTH] - deliver the implementation prototype of storage servers

D3.3a: [ZIB|KTH] - deliver the prototype implementation of SIMPLE queries

D4.1a: [UCL|INRIA|FT] - issues with Overlay reconfiguration: push + pull model (INRIA: Oz library for writing deployment workflows) - benchmarking: scenarios: patches, upgrades - configuration aspects of apps: bootstrapping, upgrading - make a good case that tools do what we claim (FT: transactional reconfiguration)

D4.2a: [KTH|INRIA] - overlay self-healing - self-healing scenarios from specific applications - recovery oriented policy at component and node level as configuration basic mechanisms

D4.3a: [ZIB|INRIA] - demonstrate/identify patterns for load balancing for the 3 apps - peak load management at the cluster level (INRIA): extend that to an overlay - load management aspects in the overlay | load balancing questions

D4.4a: [NUS] - approach for dealing with overlay routing attacks using other networks (SmallWorld) - dealing with free riding?

D5.2a: [Stakk|ZIB] - Design specification for the 2 applications (Wiki, PeerTV)

D5.2b: [ZIB] - change title (Wiki prototype)

D5.3: [Stakk] - change title (PeerTV prototype)

D5.4: - FT asks Stakk whether they can use CLIF