Difference between revisions of "SystemInfoAPI"
m (Text replace - "__NOTOC__" to "") |
|||
Line 1: | Line 1: | ||
− | + | ||
= System Info API = | = System Info API = | ||
Latest revision as of 23:31, 17 February 2013
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, versions of libraries used by the service
- service config
TODO:
- define minimum set of recommended response pairs
- prepare example responses for projects
- should config be multiple sections? defaults, settings, ...
>>>>
I think that everything you're asking for below is provided by the CloudAudit API work that Piston Cloud is doing. This would end up being an OpenStack Regime which would provide controls using the extant evidence gathering engine that's already there. In fact, as a documented API regime, this information could end up being a compliance module for trademark use etc.
-0x44 >>>>
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", } "libraries": { "openssl": "1.0.0e-2ubuntu4", "kombu": "1.0.4-2", "eventlet": "0.9.15-0ubuntu4", } }, "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?
Existing Projects
For inspiration and ideas for what might work
- jenkins /systemInfo screenshot
- nova's services api screenshot from dashboard