Edit this page on GitHub

Home > admin > Administrator Key Concepts

Key Concepts

OneOps is a multi-cloud application orchestrator. It lets you design your application in a cloud agnostic way (by abstracting multiple cloud providers) and manages your application’s design, deployments, operations & monitoring. Check out the list of supported cloud providers.

Architecture Overview

OneOps includes a self service portal for users to administer the applications, has a back end automation engine to support complete application life cycle management.

OneOps has a back end loop to monitor resources and can trigger auto-repairs, auto-scales or notifications

System Architecture

The diagram below depicts a detailed system architecture .

Web App aka display

  • Self service portal for managing applications, clouds, organization,services.
  • Rest based API’s to do almost anything which can be done on UI.
  • Can be integrated with sign on from AD

  • source


Command line ruby gem for managing almost all aspects of OneOps.

User DB

User schema to manage users, organization.


Its a ruby based gem which is responsible for loading packs.

CMS API aka adapter

Java based rest api to manage model, assemblies, environment.


Transistor is core web application responsible for creating design, deployment plan, comparing whats deployed to whats intended conforming to pack, user changes to configuration on design or Transistor..


DAQ provides rest apis to get data collected via collectors. Used for graphing monitor details in UI.


Antenna is responsible for persisiting/serving OneOps notifications into Cassandra db and distribute them to the configured Notification Sinks.

Configuration Management Database

  • System of records for all assemblies,enviroments,deployments.

  • source

Transmitter (Publisher)

This component tracks the CMS changes and post the events on the messaging bus.


We store metrics collected from back end into Cassandra

Elastic search is used to store notifications generated from OneOps and deployment logs are stored.

All cms,controller events and notifications are fed into elastic search which helps in implementing

  • Policy
  • Cost
  • Deployment/Release histories.

  • source

Message Bus

OneOps uses apache active mq as messaging layer for internal internal communication between components.


Sensor consumes metrics coming from collector and generate events if thresholds violations are detected and generate Ops events. Esper based CEP to detect monitor thresholds violations


Its an OneOps event processor to trigger auto-healing, auto-replace,or generate notifications.


Its a Logstash collector which collect metrics from managed instances in OneOps.


Its an activiti based workflow engine responsible for distributing OneOps work orders and action orders.


The Inductor consumes WorkOrders or ActionOrders from a queue by zone, executes them and posts a result message back to the controller. It is written in Java and uses a Spring Listener Container and Apache Commons Exec for process execution.

Inductor can be installed via oneops-admin gem.


A WorkOrder is a collection of managed objects that are used to add, update or delete a component.


An ActionOrder is almost identical to a workorder, but instead of an rfcCi, it has only a CI. An ActionOrder is dispatched by the controller to run some action such as: reboot, repair, snapshot, restore, etc.