OneOps API Documentation

Note: all calls will use the api token - see Get Auth Token:

• Top Level
  • GET list of manifest (transition) Lb components
  • GET a list of bom (operations) Lb components
  • GET a list of bom Fqdn components
  • GET a list of all bom Computes
  • GET a list of all environments
• Account Profile
  • GET Auth Token
  • GET all organizations
• Organization
  • GET clouds
  • GET cloud by name
  • POST cloud by name
  • GET Supported locations
  • GET Supported Services
  • GET Cloud Service By Name
  • POST New Service
  • PUT Update to Service
  • GET Compute report
• Assembly
  • GET List of assemblies for organization
  • GET Assembly by name
  • POST A new assembly
  • PUT an updated assembly
  • DELETE An assembly by name
• Platform
  • GET List of platforms
  • GET Platform by name
  • POST a platform
  • PUT and updated design component attribute
  • PUT an updated design platform variable
  • DELETE a Platform
• Environment
  • GET Transition by name
  • POST a new transition
  • PUT Cloud configuration for environment platform
• Commit & Deploy
  • POST a commit to an environment
  • GET Latest release id
  • POST A new deploy
  • GET deployment status
  • PUT Disable environment
  • GET Pull Latest
  • DELETE Environment
  • POST Discard a release by ID
• Operations
  • PUT Replace Component Instance
  • GET All available actions
  • GET Instance ids
  • POST Request to execute action
  • GET status
  • GET Computes for a Platform

Top Level

GET list of manifest (transition) Lb components

https://<your-server>/services/organization/search.json?ns_path=/services&class_name=manifest.Lb

GET a list of bom (operations) Lb components

https://<your-server>/services/organization/search.json?ns_path=/services&class_name=bom.Lb

GET a list of bom Fqdn components

https://<your-server>/services/organization/search.json?ns_path=/services&class_name=bom.Fqdn

GET a list of all bom Computes

https://<your-server>/services/organization/search.json?ns_path=/services&class_name=bom.Compute

GET a Compute by IP Address

https://<your-server>/<ORGANIZATION-NAME>/organization/search.json?source=es&query=ciAttributes.private_ip:<IP>

GET a list of all environments

https://<your-server>/services/organization/search.json?ns_path=/services&package=manifest&class_name=manifest.Environment Add: attr_name=<name> and attr_value=<value>

Account Profile

GET Auth Token via UI in your browswer (not via curl or api)

https://<your-server>/account/profile#authentication

Sample curl using the auth-token:

curl -i -u <AUTH-TOKEN>: -H "Content-Type:application/json" -H "Accept:application/json" -X GET -v https://<your-server>/account/organizations

Organization

GET all organizations

https://<your-server>/account/organizations

GET clouds

https://<your-server>/<ORGANIZATION-NAME>/clouds

GET cloud by name

https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>

POST cloud by name

https://<your-server>/<ORGANIZATION-NAME>/clouds

GET Supported locations

https://<your-server>/<ORGANIZATION-NAME>/clouds/locations.json

GET Supported Services

https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>/services/available.json

GET Cloud Service By Name

https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>/services/<SERVICE-NAME>

POST New Service

First fetch the new service body content using:

https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>/services/<SERVICE-NAME>/new.json

Then:

POST: https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>/services/
Body: Take the response from new call and update all necessary fields/attributes to create body

PUT Update to Service

First fetch the new service body content using:

https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>/services/<SERVICE-NAME>

Then:

PUT https://<your-server>/<ORGANIZATION-NAME>/clouds/<CLOUD-NAME>/services/<SERVICE-NAME>
Body: Take the response from get call and update all necessary fields/attributes to create body

GET Compute report

https://<your-server>/<ORGANIZATION-NAME>/reports/compute.json

The response has two major sections:

• One describes metrics metadata.
• One has the data itself in hierarchal form.
• A third describes scope. Because scope is different for different reports, if you want to run the report by cloud rather than by assembly, you pass extra param in the url. For example:

https://<your-server>/<ORGANIZATION-NAME>/reports/compute.json?grouping=cloud

Assembly

GET List of assemblies for organization

https://<your-server>/<ORGANIZATION-NAME>/assemblies

GET Assembly by name

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>

POST A new assembly

https://<your-server>/<ORGANIZATION-NAME>/assemblies

Body:
{
    "cms_ci": {
        "comments": "<COMMENT>",
        "ciName": "<ASSEMBL-NAME>",
        "ciAttributes": {
            "description": "<description>",
            "owner": "<EMAIL ADDRESS>"
        }
    }
}

PUT an updated assembly

TBD

DELETE An assembly by name

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>

Platform

GET List of platforms

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/design/platforms

GET Platform by name

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/design/platforms/<PLATFORM-NAME>

POST a platform

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/design/platforms

Body:
{
    "cms_dj_ci": {
        "comments": "<my comment>",
        "ciName": "<PLATFORM-NAME>",
        "ciAttributes": {
            "source": "<PACKSOURCE>",
            "description": "<description>",
            "major_version": "<MAJOR-VERSION>",
            "pack": "<pack>",
            "version": "<VERSION>"
        }
    }
}

PUT and updated design component attribute

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/design/platforms/<PLATFORM-NAME>/components

Body:
{
    "cms_dj_ci": {
        "createdBy": "klohia",
        "execOrder": 0,
        "ciName": "user-app",
        "ciId": "12752422",
        "nsPath": "/testing/testassm/_design/t1",
        "ciClassName": "catalog.User",
        "ciAttributes": {
            "username": "app",
            "system_account": "true",
            "description": "App User",
            "login_shell": "/bin/bash",
            "home_directory": "/app",
            "authorized_keys": "<SSH-KEY>",
            "ulimit": "16384",
            "sudoer": "true"
        }
    }
}

Attributes of component are very specific to each component.

PUT an updated design platform variable

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/design/platforms/<PLATFORM-NAME>/variables

Body:
{
    "cms_dj_ci": {
        "comments": "",
        "impl": "oo::chef-11.4.0",
        "createdBy": "klohia",
        "execOrder": 0,
        "ciName": "appVersion",
        "ciId": "12752469",
        "nsPath": "/testing/testassm/_design/t1",
        "ciGoid": "12752412-1873-12752469",
        "ciClassName": "catalog.Localvar",
        "ciAttributes": {
            "value": "1.0"
        }
    }
}

DELETE a Platform

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/design/platforms/<PLATFORM-NAME>

Environment

GET Transition by name

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>

POST a new transition

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>

Body:
{
    "clouds": {"<CLOUD_CID>":"<Priority>",
            "<CLOUD_CID>":"<Priority>"
    },
    "platform_availability": {
        "<PLATFORM-DESIGN-ID>": "redundant"
    },
    "cms_ci": {
        "ciName": "<ENVIRONMENT-NAME>",
        "nsPath": "<ORGANIZATION-NAME>/<ASSEMBLY-NAME>",
        "ciAttributes": {
            "autorepair": "true",
            "monitoring": "true",
            "description": "<DESCRIPTION>",
            "dpmtdelay": "60",
            "subdomain": "<ENVIRONMENT-NAME>.<ASSEMBLY-NAME>.<ORGANIZATION-NAME>",
            "codpmt": "false",
            "debug": "false",
            "global_dns": "true",
            "autoscale": "true",
            "availability": "redundant/single"
        }
    }
}

PUT Cloud configuration for environment platform

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/platforms/<PLATFORM_NAME>/cloud_configuration

Body:
{
  "cloud_id": "<cloud ci-id>",
  "attributes": {
    "adminstatus": "active OR inactive OR offline",
    "priority": "1 OR 2",
    "pct_scale": ...,
    "dpmt_order": ...
  }
}

All attributes are optional (pass in only what needs to be updated).

Attributes:

• adminstatus - administrative status of cloud
• priority - cloud priority (primary => 1 or secondary => 2)
• pct_scale - scale percentage
• dpmt_order - deployment order

Commit and Deploy

POST a commit to an environment

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/commit

GET Latest release id

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/releases/bom

Previous Path [DEPRECATED]

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/releases/latest

POST A new deploy

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/deployments/

Body:
{
    "cms_deployment": {
        "releaseId": "<LATEST-RELEASE-BOM>",
        "nsPath": "/<ORGANIZATION-NAME>/<ASSEMBLY-NAME>/<ENVIRONMENT-NAME>/bom"
    }
}

GET deployment status

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/deployments/<DEPLOYMENT_ID>/status

PUT Disable environment

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/disable

GET Pull Latest

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>/pull

DELETE Environment

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/transition/<ENVIRONMENT-NAME>

POST Discard a release by ID

https:////assemblies//transition//releases//discard

Operations

PUT Replace Component Instance

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/operations/environments/<ENV_NAME>/platforms/<PLATFORM-NAME>/components/<COMPONENT-NAME>/instances/<INSTANCE_ID>/state

Body:
{ "state" : "replace" }

GET All available actions

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/operations/environments/<ENV_NAME>/platforms/<PLATFORM-NAME>/components/<COMPONENT-NAME>/actions

GET Instance ids

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/operations/environments/<ENV_NAME>/platforms/<PLATFORM-NAME>/components/<COMPONENT-NAME>/instances?instances_state=all

POST Request to execute action

https://<your-server>/<ORGANIZATION-NAME>/operations/procedures

Body:
{
    "cms_procedure": {
        "procedureCiId": "0",
        "procedureName": "<Name>",
        "ciId": "<Component_id>",
        "procedureState": "active",
        "definition": "{"flow":[{"targetIds":["<Instance_id>"],"relationName":"base.RealizedAs","direction":"from","actions":[{"actionName":"<Action-name>","stepNumber":1,"isCritical":true}]}],"name":"<Action-name>"}"
    }
}

For example:

{
    "cms_procedure": {
        "procedureCiId": "0",
        "procedureName": "reboot",
        "ciId": "9277281",
        "procedureState": "active"
        "definition": "{"flow":[{"targetIds":["9277720"],"relationName":"base.RealizedAs","direction":"from","actions":[{"actionName":"reboot","stepNumber":1,"isCritical":true}]}],"name":"reboot"}"
    }
}

GET status

Use procedure_id from previous call:

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<Assembly-name>/operations/environments/<ENV-NAME>/platforms/<Platform-name>/procedures/<Procedure-id>

GET Computes for a Platform

https://<your-server>/<ORGANIZATION-NAME>/assemblies/<ASSEMBLY-NAME>/operations/environments/<ENV-NAME>/platforms/<PLATFORM-NAME>/components/compute/instances.json?instances_state=all

Assemblies API

To add, update and delete assemblies in your organization, use the Assemblies API.

List

Get a list of assemblies in your organization.

GET /assemblies

Response

<%= headers 200 %> <%= json(:assembly) { |h| [h] } %>

Create

Create a new assembly in your organization. The authenticated user must be a user in the organization.

POST /assemblies

Input

cms_ci : Required Hash
ciName
: _Required_ **String**
comments
: _Optional_ **String**
ciAttributes
: _Required_ **Hash**
    description
    : _Optional_ **String**

<%= json %5C :cms_ci => { :ciName => "myassembly", :comments => "These are your comments", :ciAttributes => { :description => "This is your assembly description" } } %>

Response

<%= headers 200 %> <%= json :assembly %>

Get

Retrieve the requested assembly.

GET /assemblies/:assembly

Response

<%= headers 200 %> <%= json :assembly %>

Update

Update the specified assembly with new data.

PUT /assemblies/:assembly

Input

cms_ci : Required Hash
comments
: _Optional_ **String**
ciAttributes
: _Required_ **Hash**
    description
    : _Optional_ **String**

<%= json %5C :cms_ci => { :comments => "These are your comments", :ciAttributes => { :description => "This is your assembly description" } } %>

Response

<%= headers 200 %> <%= json :assembly %>

Delete

Remove the specified assembly.

DELETE /assemblies/:assembly

Response

<%= headers 200 %>

Clone

To create a clone with another name, copy the assembly.

Catalog

Save the assembly into the organization catalog.

CI Notification Format

OneOps broadcasts the CI notifications to all configured sinks as well as to email recipients configured. A CI notification json has a format like below sample:

{
    ts: "2016-01-01T15:51:42.183",
    cmsId: 1234,
    cloudName: "abc",
    severity: "warning",
    type: "ci",
    source: "ops",
    subject: "webapp-tomcat-compute-ssh:SSH Up is violated.",
    text: "compute-11031075-2 is in unhealthy state; Starting repair",
    nsPath: "/OneOps/webapp/prod/bom/tomcat/1",
    payload: {
        total: "6",
        oldState: "good",
        unhealthy: "5",
        eventName: "webapp-tomcat-compute-ssh",
        className: "bom.main.2.Compute",
        threshold: "SSH Up",
        state: "open",
        metrics: "{"avg":{"up":0.0}}",
        ciName: "compute-11031075-2",
        good: "1",
        newState: "unhealthy",
        status: "new"
    },
    timestamp: 1460404258633,
    environmentProfileName: "PROD",
    adminStatus: "active",
    manifestCiId: 58108355
}

The new state of a ci (payload.newState) could be any of below :

• notify
• unhealthy
• underutilized
• overutilized
• good

An “open” type of notification event (payload.state) is created in case a threshold/monitor is violated for a CI (component instance) - for example if cpu idle goes below 20

A matching close event notification is created in case a “reset” condition is met for a CI. - For example if cpu idle moves to above 60

A unique notification can be identified by this combination - {cmsId + payload.eventName + payload.threshold}. Here the cmsId identifies a unique ci object - like one particular compute (or tomcat) instance. The ( payload.eventName + payload.threshold) identifies the monitor-threshold that got violated.

There will be a matching “close” notification event with the same {ciId + payload.eventName + payload.threshold} but with payload.state = ‘close’

Here is the sample for a matching close event for above open event:

{
    ts: "2016-01-01T19:51:42.183",
    cmsId: 1234,
    cloudName: "abc",
    severity: "info",
    type: "ci",
    source: "ops",
    subject: "webapp-tomcat-compute-ssh:SSH Up recovered.",
    text: "compute-11031075-2 is in good state.",
    nsPath: "/OneOps/webapp/prod/bom/tomcat/1",
    payload: {
        total: "6",
        oldState: "unhealthy",
        unhealthy: "1",
        eventName: "webapp-tomcat-compute-ssh",
        className: "bom.main.2.Compute",
        threshold: "SSH Up",
        state: "close",
        metrics: "{"avg":{"up":100.0}}",
        ciName: "compute-11031075-2",
        good: "5",
        newState: "good",
        status: "new"
    },
    timestamp: 146040231302183,
    environmentProfileName: "PROD",
    adminStatus: "active",
    manifestCiId: 2345
}

Component List

Look here for available components.

Default Monitor Thresholds

The tables below list all of the default monitor thresholds implicitly added in all environments. As an app owner, you should review and update these thresholds to what is best suited for your app.

Volume /app Thresholds

Tomcat Thresholds

Artifact App – App-Specific Thresholds

Apache Server Thresholds

ActiveMQ Thresholds

Design Attachments API

Use the Attachment API to store additional configuration entities for any component. You can use attachments to add configuration files, certificates, custom scripts etc. Attachment content can be specified directly in the request or from a specified remote URL location.

Each attachment has a :runs_on attribute that allows for optional callback executions before or after component lifecycle events of add, update and delete. In addition, you can specify the on-demand option in the runs_on list which makes the attachment with the associated execution command to be available as an on-demand component action to be invoked at any time during operations.

List

Get a list of attachments for a design component.

GET /assemblies/:assembly/design/platforms/:platform/components/:component/attachments

Response

<%= headers 200 %> <%= json(:design_attachment) { |h| [h] } %>

Create

Add a new attachment to this design component.

POST /assemblies/:assembly/design/platforms/:platform/components/:component/attachments

Restrictions

Attachment names must be unique within a given platform namespace.

Input

cms_dj_ci : Required Hash
ciName
: _Required_ **String**
comments
: _Optional_ **String**
ciAttributes
: _Required_ **Hash**
    content
    : _Optional_ **String** - Attachment content.
    source
    : _Optional_ **String** - Source URL where the content to be downloaded is located. The location must be a file, binary or text.
    headers
    : _Optional_ **Hash** - Optional HTTP headers to be used to force MIME types or for other customizations to the download request.
    basic_auth_user
    : _Optional_ **String** - Username for protected URL location.
    basic_auth_password
    : _Optional_ **String** - Password for protected URL location.
    checksum
    : _Optional_ **String** - Checksum to compare after the download.
    path
    : _Optional_ **String** - Destination filename path where the content should be saved or the remote source URL content should be downloaded to.
    exec_cmd
    : _Optional_ **String** - Command-line to execute after the content is saved.
    runs_on
    : _Optional_ **String** - Comma-separated list of lifecycle events for automatic callbacks.
    The list can contain only the following events: **before-add, after-add, before-update, after-update, before-delete, after-delete, on-demand.**
    priority
    : _Optional_ **String** - Specify priority of executions in case there are multiple attachments in the same callback event.

<%= json %5C :cms_dj_ci => { :ciName => "myattachment", :comments => "These are your comments", :ciAttributes => { "content" => "Some file or script content here", "source" => "", "headers" => "", "basic_auth_user" => "", "basic_auth_password" => "", "checksum" => "", "path" => "/tmp/myattachment.sh",
"exec_cmd" => "/tmp/myattachment.sh", "run_on" => "before-add,on-demand", "priority" => "1" } } %>

Response

<%= headers 200 %> <%= json :design_attachment %>

Get

Retrieve the requested attachment in this design component.

GET /assemblies/:assembly/design/platforms/:platform/components/:component/attachments/:attachment

Response

<%= headers 200 %> <%= json :design_attachment %>

Update

Update the specified attachment in this design component with new data.

PUT /assemblies/:assembly/design/platforms/:platform/components/:component/attachments/:attachment

Input

cms_dj_ci : Required Hash
comments
: _Optional_ **String**
ciAttributes
: _Required_ **Hash**
    content
    : _Optional_ **String** - Attachment content.
    source
    : _Optional_ **String** - Source URL where the content to be downloaded is located. The location must be a file, binary or text.
    headers
    : _Optional_ **Hash** - Optional HTTP headers to be used to force MIME types or for other customizations to the download request.
    basic_auth_user
    : _Optional_ **String** - Username for protected URL location.
    basic_auth_password
    : _Optional_ **String** - Password for protected URL location.
    checksum
    : _Optional_ **String** - Checksum to compare after the download.
    path
    : _Optional_ **String** - Destination filename path where the content should be saved or the remote source URL content should be downloaded to.
    exec_cmd
    : _Optional_ **String** - Command-line to execute after the content is saved.
    runs_on
    : _Optional_ **String** - Comma-separated list of lifecycle events for automatic callbacks.
    The list can contain only the following events: **before-add, after-add, before-update, after-update, before-delete, after-delete, on-demand.**
    priority
    : _Optional_ **String** - Specify priority of executions in case there are multiple attachments in the same callback event.

<%= json %5C :cms_dj_ci => { :comments => "These are your comments", :ciAttributes => { "content" => "Some file or script content here", "source" => "", "headers" => "", "basic_auth_user" => "", "basic_auth_password" => "", "checksum" => "", "path" => "/tmp/myattachment.sh",
"exec_cmd" => "/tmp/myattachment.sh", "run_on" => "before-add,on-demand", "priority" => "1" } } %>

Response

<%= headers 200 %> <%= json :design_attachment %>

Delete

Remove the specified attachment in this design component.

DELETE /assemblies/:assembly/design/platforms/:platform/components/:component/attachments/:attachment

Response

<%= headers 200 %>

Metadata

Metadata files model components and have several parts:

• base/required Attributes (name, desc, etc)
• grouping Sub-groups of attributes CMS models (For an advanced example, see the token metadata.)
• attributes Defaults, format: UI metadata
• recipes Default actions. Add, update and delete are assumed and do not need to be added. Actions can also be added using the UI as on-demand attachments.

The following is an example of a metadata file:

# 1: base/required attributes
name             "Apache"
description      "Installs/Configures Apache"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version          "0.1"
maintainer       "Kloopz, Inc."
maintainer_email "dev@kloopz.com"
license          "Copyright OneOps, All rights reserved."
# 2: grouping - sub-groups of attributes cms models
# usually dont need to change this. Its for when different types 
# can have different attributes. See the token metadata for example.
grouping 'default',
  :access => "global",
  :packages => [ 'base', .. 'manifest', 'bom' ]
# 3: attributes
attribute 'install_type',
  :description => "Installation Type",
  :required => "required",
  :default => "repository",
  :format => {
    :category => '1.Source',
    :help => 'Select the type of installation - standard OS '+
             'repository package or custom build from source code',
    :order => 1,
    :form => { 'field' => 'select', 
               'options_for_select' => [['Repository package','repository'],
                                        ['Build from source','build']] }
  }
...
# 4. recipes - default actions. 
# Actions can also be added via UI in design mode as on-demand Attachments. 
recipe "status", "Apache Status"
recipe "start", "Start Apache"
recipe "stop", "Stop Apache"
recipe "restart", "Restart Apache"
recipe "repair", "Repair Apache"

See Also

• Component
• Recipes
• Attachments

Monitor

An optional monitor within a Pack Component Resource contains:

• Name, desc, optional source
• Charting defaults: For example, min/max y-axis, unit
• Nagios command name and command line to execute: cmd and cmd_line
• Metrics: name, unit, desc, dstype
• Thresholds: When to trigger events

For additional information about dstype, see Metric Data Source Type in the OneOps Admin Documentation.

The following is a sample monitor definition from Tomcat’s pack:

resource "tomcat",
  :cookbook => "tomcat",
  :design => true,
  :requires => { "constraint" => "1..1" },
  :monitors => {     
      'JvmInfo' =>  { :description => 'JvmInfo',
                  :source => '',
                  :chart => {'min'=>0, 'unit'=>''},
                  :cmd => 'check_tomcat_jvm',
                  :cmd_line => '/opt/nagios/libexec/check_tomcat.rb JvmInfo',
                  :metrics =>  {
                    'max'   => metric( :unit => 'B', :description => 'Max Allowed', :dstype => 'GAUGE'),
                    'free'   => metric( :unit => 'B', :description => 'Free', :dstype => 'GAUGE'),
                    'total'   => metric( :unit => 'B', :description => 'Allocated', :dstype => 'GAUGE'),
                    'percentUsed'  => metric( :unit => 'Percent', :description => 'Percent Memory Used', :dstype => 'GAUGE'),
                  },
                  :thresholds => {
                     'HighMemUse' => threshold('5m','avg','percentUsed',trigger('>',98,15,1),reset('<',98,5,1)),
                  }
                },
       ...

Pack Policy

Policies can also be specified as part of the pack definition. This enables policy evaluation on all CIs (components, attachments, platform variables, monitors) under the platform for a given pack. The violated policies can then be fixed to avoid issues further down the application lifecycle.

The policy definitions are added to the pack “.rb” file in a given circuit. Following are few examples of pack based policies.

policy "env-profile",
       :description => 'custom pack policy for env-profile',
       :query => 'ciClassName:manifest.Environment AND _missing_:ciAttributes.profile'
       :docUrl => '<document url link for the policy>'`
       :mode => 'passive'
policy "compute-ostype",
       :description => 'custom pack policy for compute-ostype',
       :query => 'ciClassName:(catalog.*Compute manifest.*Compute bom.*Compute) AND NOT ciAttributes.ostype:("centos-6.5" OR "centos-6.6" OR "redhat-6.5" OR "redhat-6.6" OR "default-cloud")'
       :docUrl => '<document url link for the policy>'`
       :mode => 'active'
policy "env-automation",
       :description => 'custom pack policy for env-automation',
       :query => 'ciClassName:manifest.Environment AND ciAttributes.profile:(PROD EBF STAGING) AND NOT (ciAttributes.autorepair:true AND ciAttributes.autoreplace:true)'
       :docUrl => '<document url link for the policy>'`
       :mode => 'passive'

Brief description about each field in the policy definition is as follows

• Description: Brief description about the Policy.
• Query: Elastic Search query to identify candidate objects that violate the policy.
• Doc URL: URL to the document about the policy details.
• Mode: Can be Active/Passive.
  • Active: Prohibits users from saving objects under violation. For example: A policy can be defined to allow only a few compute images like centos-6.6, redhat 6.5. Any attempt to save a compute component with an image value other than these two, fails.
  • Passive: All components and instances that violate such policies are marked with a failed policy status with the reason for the specific policy failures.

Packs API

List

Get a list of packs available for this organization.

GET /packs

Response

<%= headers 200 %> <%= json(:packs) { |h| [h] } %>

Platform Management Pack

A platform is added to the system by creating a Platform Management Pack (Pack) file and loading it into the CMS. A Pack is a Ruby DSL file that models a platform. It exists in the packer directory structure.

The file contains:

• Component Resources: Named resources with the type (cookbook attribute) and the Component Class name
• Relationships/dependencies with flexing/scaling attributes
• Metrics/Thresholds (optional)

A Pack can extend another Pack, which keeps the model clean and manageable. Packs are versioned to match a set of recipes.

For instructions on how to add a new platform, refer to Add a Platform.

Platforms

Each Platform has a set of Components (optional and required) that are predefined by a Platform template.

Each Component has configuration attributes that are specific to the type of Component. Components, like Platforms, have interdependencies that are used during the generation of a deployment plan. On the Platform detail page, there is a diagram and a list of Components. The list is grouped by Component type with an indication of the number of Components within each group.

After all changes are committed, you can move on to Transition to realize/promote your design/changes to the new/existing environment.

Relations

The following model diagrams describe the relationships for Design, Transition, and Operations in the OneOps UI. Relationships also have attributes, some of which are used to scale.

Design

In the Design aspect, we model the base application:

• No environmental
• No operational components

Transition

In the Transition aspect, we model two additional objects:

• IaaS components: Can be load balancers (haproxy) or DNS (djbdns). Can also use provider-based ones like route-53, dyndns, elb, etc.
• Monitors: Use to customize monitors for each environment

Operations

In the Operations aspect, we create bom components for the manifest components with relation to the Binding (cloud provider).

Relationships

Relationships have attributes like other objects modeled in OneOps. We are working on adding pages to visualize and explain all of them.

There are two primary relationships used in packs:

• depends_on Sets the order of deployment and dependency tree for escalation
• managed_via How to know where to connect for management. In most cases, this is a compute, but in some, it is a cluster or ring.

Relationships are modeled like components, with the same directory structure. Relationships also have attributes.

For more detail regarding relations for Design, Transition and Operations, see Relations.

List of relationships:

authenticates
binds_to
composed_of
controlled_by
depends_on
deployed_to
escorted_by
forwards_to
links_to
managed_via
manages
provides
realized_as
realized_in
requires
secured_by
serviced_by
supplied_by
utilizes
value_for
watched_by