Jump to: navigation, search

SystemInfoAPI

Revision as of 19:55, 29 November 2011 by Anotherjesse (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

System Info API

STATUS: DRAFT - please help define response buckets / values

OpenStack services have many configuration options, as well as environmental conditions (operating system versions, hardware information, ...)

Currently we expose minimal information about the service. This proposal is to add an admin api to expose service information in a standard way:

  • version - api (2.0), code (sha?), release (essex-1)
  • hardware info - arch, memory, cpu,
  • system info - os, environment variables
  • service config

TODO:

  • define minimum set of recommended response pairs
  • prepare example responses for projects
  • should config be multiple sections? defaults, settings, ...

API

REQUEST:


GET /systemInfo


RESPONSE (json or xml):


{ "version": {
    "api": "2.0",
    "code": "8230533824fd170498e51b43dd2f20e6af410c53",
    "release": "essex-1"},
  "system": {
    "arch": "x86_64",
    "memory": "74371184",
    "cpu": "Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz",
    "disk": "an array or does this belong?",
    "os": {
      "arch": "amd64",
      "name": "Linux",
      "version": "#20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011",
      "kernel": "3.0.0-12-generic",
    }
  },
  "environment": {
    "USER": "stack",
    "HOME": "/opt/stack",
    "PWD": "/opt/stack/nova/bin",
    "SHELL": "/bin/bash"
  },
  "config": {
     "storage_availability_zone": "nova",
     "vc_image_name": "vc_image",
     "ec2_dmz_host": "50.56.12.197",
     "fixed_range": "10.4.96.0/20",
     "compute_topic": "compute",
     "vsa_topic": "vsa",
     "fixed_range_v6": "fd00::/48",
     "glance_api_servers": ["50.56.12.197:9292"],
     "user_cert_subject": "/C=US/ST=California/L=MountainView/O=AnsoLabs/OU=NovaDev/CN=%s-%s-%s",
     "s3_dmz": "50.56.12.197",
     "quota_ram": "51200",
     "find_host_timeout": "30",
  }
}


Questions

What about all the workers (compute hosts, swift nodes, ...)?

  • does the solution need to scale to 1000s of workers if we expose information for workers?
  • perhaps an api call to get a list of "resources" (workers/hosts/nodes) and then the ability to dynamically query status of an individual node?