https://github.com/fruit-testbed/glossary

https://github.com/fruit-testbed/glossary

Last synced: 6 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/fruit-testbed/glossary
• Owner: fruit-testbed
• Created: 2017-07-18T12:14:55.000Z (about 9 years ago)
• Default Branch: master
• Last Pushed: 2017-10-17T17:32:54.000Z (almost 9 years ago)
• Last Synced: 2025-05-21T20:45:28.863Z (about 1 year ago)
• Size: 7.81 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
FRuIT glossary

==============

We need to establish a shared vocabulary so we can talk about the

technical aspects of the project sensibly. Here is a first stab at

some terms we might want to standardise. Feel free to add/edit. This

glossary is formatted for emacs org-mode.

* behind a NAT

  An NATted entity is on a private network and does not have a

  globally reachable IP address. This entity can contact the outside

  world, but other entities cannot initiate contact with this entity. 

* configuration

  This happens to individual nodes. A node is configured

  by a script, which sets up the node's software stack, from the OS up

  to the application layer. The precise details of the script support

  are TBC. Configuration will be managed remotely. 

* deploy task

  A task is deployed on an provisioned entity of configured nodes

* entity

  Either a node, a micro-cluster or a federation.

* federation

  A set of logically connected nodes and/or micro-clusters, reachable

  via a single overlay network. A federation is a dynamic construct

  that is assembled to operate on a compute task, probably using some

  kind of message passing protocol.

* management

  The management software layer is the core of the FRuIT system. It

  supports all the user-facing activities i.e. provisioning,

  configuration, deployment, update and surrender. 

  The management layer is a lightweight dom0 (i.e. not virtualized)

  daemon that runs on each node of the FRuIT system. It responds to

  message style requests to perform appropriate on-node actions. (Are

  these requests SERF style broadcast messages?)

* micro-cluster

  A set of nodes connected on a LAN. At least one node in the

  micro-cluster is a controller node, with an outside internet

  connection and responsibility for orchestrating cluster

  configuration/management. Everything we have built so far

  (Iridis-Pi, Glasgow PiCloud) is a micro-cluster. 

* node

  Probably a single Raspberry Pi board or other single board

  computer. A node has at least one IP

  address, probably corresponding to a physical ethernet connection. A

  node runs a local operating system, most likely a Linux distro. A

  node has at least one CPU core.

* overlay network

  A virtual connection network, using some protocol (perhaps VPN or

  some p2p protocol) that is layered on top of a physical network

  (probably ethernet)

* provisioning

  An end-user requests some number of entities to be allocated, with the

  intention of deploying a task on them. Parameters for provisioning are

  to be determined. cf. AWS instance provisioning via a web interface or

  programmatic API.

* resource sharing

  Using containerization, it should be possible to host multiple tasks

  on a single node. This idea of multi-tenancy or resource sharing is

  a key concept in as-a-service computing. We need to decide whether we

  can give someone 0.5 of a node, or similar. Can we federate at finer

  granularity than dedicated node-level? How quantized are our

  entities? So far, all our nodes have been dedicated to a single

  task --- FRuIT should explore how we can achieve more efficient

  resource sharing.

* surrender

  An entity that has been provisioned can be surrendered, which means

  it is no longer required by that user, and may be redeployed. cf. AWS

  instance termination. Individual nodes may be surrendered one-by-one,

  which means a user can gradually return a provisioned entity

  comprising multiple nodes.

* task

  Users want to run tasks on entities. Precise nature of task needs to

  to be confirmed. Something like a docker container? At the very

  least, a task must be a packaged executable with associated

  metadata. Execution of tasks is the main purpose of the FRuIT system we

  are building. Current tasks on our existing clusters include MPI

  programs, Hadoop jobs, sensor data collection and forwarding.

* unique features of our project

  - federation is a layer higher than standard datacenters.

  - Some of our entities are not globally reachable.

  - We want to do config/update etc in a p2p manner.

  - we run on lightweight nodes, ideally using renewable energy sources

* update

  Software on a configured node is replaced or upgraded by an update operation.

  This might befor security or functionality improvements.

* workflow

  As far as the end-user is concerned, the typical interaction

  sequence with FRuIT is : provision -> configure -> deploy -> update

  (?) -> surrender. This sequence should be supported/automated by our

  FRuIT system. Current state of the art for our testbeds is manual

  provisioning, centralized configuration and deployment, manual

  update and no surrender (other than power down).