cmusatyalab / sinfonia

Manage discovery of cloudlets and deployment of backends for edge-native applications

Sinfonia

Manages discovery of nearby cloudlets and deployment of backends for edge-native applications.

Tier 1 is located in the cloud, Tier 2 is at various cloudlets where backends could be deployed and Tier 3 is the mobile client application.

Tier 1 collects recent metrics from Tier 2 cloudlets and uses these in combination with Tier 3 application / backend specific requirements to pick one or more Tier 2 candidates for deployment.

Deployment States

• Initializing

  • create kilo peer and deployment namespace
  • label namespace with application uuid + client pubkey
  • start application with helm
  • transition to Deployed

• Deployed

  • deployment requests bump expiration time
  • job runner is responsible for transition to Expiring
    • delete kilo peer
    • stop application with helm

• Expiring

  • deployment request transitions back to Deployed
    • (re)create kilo peer
    • (re)start application with helm
  • job runner will transition to Expired
    • delete application, deployment namespace

• Expired

  • reclaimed all state and resources
  • new deployment requests transition to Initializing

Development workflows

Tier 1

When developing/debugging Tier1 interactions it is often simplest to create a local cloudlets.yaml config file that contains static data for one or more Tier2 instances and then start a local tier1 instance with poetry run sinfonia-tier1 -c cloudlets.yaml.

name: Orchestrator@CMU
endpoint: http://cloudlet.elijah.cs.cmu.edu/api/v1/deploy
local_networks:
  - 128.2.0.0/16
  - 128.237.0.0/16
location: [40.4439, -79.9444]
accepted_clients:
  - 0.0.0.0/0
resources:
  cpu_ratio: 0.1
  mem_ratio: 0.5
  gpu_ratio: 0.0
  net_tx_rate: 11000
  net_rx_rate: 1000
---
name: Orchestrator@Home
endpoint: http://localhost:5000/api/v1/deploy
location: [40.4465, -79.9032]
local_networks:
  - 192.168.0.0/16
accepted_clients:
  - 192.168.0.0/16

Versioning

There are two different versions in play,

• the main application version is used to tag releases and docker containers
• the Helm chart version.

The Helm chart version uses strict semver and should always be equal or larger than the main application version. It is bumped whenever the Helm chart changes, which includes anytime a new release is made.

The main application version uses semantic versioning for all releases. After publishing the application version becomes current_version.post.dev0. However the appVersion in the Helm chart remains at the last tagged release so keep in mind that any development changes to the Helm chart will be using the last released application Docker container and not the version of the source code that is currently under development.

sinfonia's Issues

Avoid invalid k8s labels on some wireguard keys

I had a public key that started with "+" which resulted in an invalid kubernetes label as labels must start with an alphanumeric character.
Maybe prefix the key-derived labels with "wg-"?

Can the document be more detailed？Please！

Can you write the document in more detail? I want to run this system on the virtual machine, but I don't know the running order of the files.

Make it easier to run Tier2 outside of a kubernetes cluster

Right now we need to have kubectl/helm access to the cluster, but also expose the prometheus endpoint with a combination of kubectl port-forward and overriding the prometheus endpoint url (--prometheus) to point at the forwarded port.

Having some startup tests to see if kubectl/helm and the prometheus endpoint are accessible and then either failing or automatically setting up the required port forward would make it a lot easier for developers who are working on Tier2 from their development environment.