User Tools

Site Tools


General Goals


Several stakeholders should become users of Clouds in Community Networks.

  • Community Network Users
  • Municipalities
  • Education institutions
  • SMEs

Success Stories

The following scenarios are to going to be developed:

  1. SMEs: Usage of the Commnity Cloud for hosting, e.g. storage for IoT applications, usage of computational service for system development.
  2. Community network users: Using application services (e.g. owncloud, Tahoe, streaming)
  3. Municipalities: explore hybrid cloud approach, e.g. for storage/backup for IoT
  4. Education: use Commnity Cloud as infrastructure for perform educational tasks

Significant contributions

The value of the Community Cloud comes from its usage.

All contributions that lead to usage by stakeholders are significant.

Architecture Overview

Typical cloud architecture. Three layers: Infrastructure, Platform, Services



  • “CONFINE-Clommunity” device

Servers from the project

  • Metrics: number
    • exact number

Servers from 3rd parties

  • Metrics: number
    • DB
    • estimation (exact number from known cases ⇒ extrapolation)



  • tech solution: LDAP
    • already in use in
    • all new services should be compatible with it
    • adaptation to fulfil resulting new requirements
  • metrics: number of users (validations/day, others?)


  • current tech solution: Proxmox
    • manually admin:
      • + already working, gives input regarding: real demand, kind of needs, scale, usage (abuses?)
      • - manual maintanence :(
    • TODO: research on LDAP integration (potential extensions)
  • future solution: automatisation (using proxmox?)
    • only if input from current situation justifies this step








  • tech solution: PeerStreamer
    • * currently under investigation


  • Could be a very successful service because it is frequent need in to broadcast events, etc.
  • tech solution: ?????????

Additional contributions web platform improvement

  • New device
  • Sort Services section
    • * split the single current list (currently ~1600 services declared, ~1000 operative) into services
    • * implement selection criteria (e.g. up/down, close_to_node_X)

Old stuff ====== research_approach ====== Original file

====== RESEARCH APPROACH ====== ====== Overview ====== Clommunity consortium is composed by academic/research institutions and community networks. Despite this cross-fertilization is expected to very productive, coping with such different skills, organization systems, etc. is an additional challenge for the project. This document is a working tool (so it is expected to change over the time) that is aimed at facilitate this cooperation. Following sections are project phases ===== Consortium partners ===== * Academic/research institutions (AIs) * Universitat Politècnica de Cataluna (UPC) [project leader] * Swedish Institute of Computer Science (SICS) * Royal Institute of Technology (KTH) * International Centre for Theoretical Physics (ICTP) * Community networks (CNs) * Fundació Privada per a la Xarxa Oberta, Lliure i Neutral ( ====== Knowledge transfer (KT) ====== Partners: UPC, SICS, KTH, guifi Duration: ???

===== Rationale ===== AIs have good knowledge of standard cloud SoA ⇒ AIs teach main cloud aspects to CNs CNs have a good knowledge of CNs SoA ⇒ CNs teach CNs main aspects to AIs ===== Tasks ===== * AIs → CNs : Cloud * CNs -AIs : CNs ===== Further information ===== ==== CNs inputs (/requirements) ====

=== === * the best strategy to introduce a new product into (software or hardware or both) the community is offering and easier solution than the existing one (other aspects such being technically better, etc. are irrelevant) * e.g. offer a platform including the current distro's services easier (as a whole) to install and/or with better upgrades, etc. ====== Problem definition ====== Partners: UPC, SICS, KTH, guifi Duration: ???

===== Rationale ===== CNs do no fulfill standard cloud assumptions: * weak links (unstable, small bandwidth) * small individual computing capacity (not always available, small CPU, small RAM, small storage) * very spread (many small devices). General approach: * step 1: design (architecture), develop, and implement(prototype) a CNs cloud platform * step 2: port some of (better all) the current CNs applications to the platform * step 3: deploy few clommunity boxes and test for a long period (2 weeks?). Iterate to step 1/2 if necessary * step 4: deploy clommunity boxes to the community (can be done in three iterations: it1, boxes are 100% funded, it2, boxes are funded 50%, it3, no funding any more) * Success indicator: number of it1/2/3 boxes deployed, number of ISO downloads ===== Tasks ===== * Identify CNs cloud characteristics vs. standard cloud * How does the previous differences effect standard cloud * Identify CNs current applications * Adaptation to the could approach * Changes to the applications needed * Expected benefits * Can the cloud approach equals at least the current performance? * Changes needed for standard cloud → community cloud * Identify potential new applications (just possible thx to CNs cloud) ===== Further information =====

==== CNs cloud vs. standard cloud ==== Cloud logical diagram: 3-. Application 2-. Platform → key layer; User and services localization and identification → key features 1-. Infrastructure

==== CNs current applications ==== === === * “standard”: proxy (with LDAP and federation system), DNS, monitoring (graphs) * server ISO: ====== Testbed deployment ====== Partners: guifi Duration: ??? ====== Software devolpment ====== Partners: UPC, SICS, KTH Duration: ??? ===== Platform develoment ===== ===== Existing applications port ===== ===== New applications =====

====== Experimentation and Evalutaion ====== ====== Dissemination ======

research_approach/start.txt · Last modified: 2015/01/21 17:25 by felix