Jump to: navigation, search

Difference between revisions of "SystemUsageData"

(converted account id to tenant id)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
* '''Launchpad Entry''': [[NovaSpec]]: [https://blueprints.launchpad.net/nova/+spec/system-usage-records System Usage Data]
 
* '''Created''': 3 February 2011
 
* '''Contributors''': Paul Voccio, Glen Campbell
 
 
 
<<[[TableOfContents]]()>>
 
<<[[TableOfContents]]()>>
  
 
== Summary ==
 
== Summary ==
 
 
Nova administrators want data on system usage for billing, chargeback, or monitoring purposes.
 
Nova administrators want data on system usage for billing, chargeback, or monitoring purposes.
  
 
== Release Note ==
 
== Release Note ==
 +
System usage data is emitted from Nova in the form of usage events from Nova's Notifications system. The notifications system can be configured to emit events either through nova's logging facility, or send them to a series of AMQP queues (one per notification priority).  System usages are emitted as notification events with the INFO priority.  Different types of usage events are distinguished via the notifications' event_type, which is a hierarchical dotted string such as ''compute.instance.create'', which allows usages to be easily grouped for aggregation. Usage notifications can be immediate, created when a specific increment of usage occurs (such as creation of an instance) or periodic, generated by a periodic task, like a cron job, and covering usage for a certain period of time. Besides the standard Nova Notification priority, notification timestamp, and event_type, usage notifications contain a payload of data that will vary depending on the event_type. This is presented as a json-formatted hash of key-value pairs. Some of the keys, such as tenant_id will always be present in any usage notification, others will be data relevent to that event_type (For example, instance related notifications will contain data describing the instance.)
  
System usage data is collected by Nova and provided via a rich Atom API. Usage data includes utilization of bandwidth, hard disk, and RAM, along with other important events such as the creation or teardown of servers. If configured, usage data is provided via [[PubSubHubbub]] (PSH) for efficient distribution of data to subscribers.
+
An external application (https://github.com/Cerberus98/yagi) is available that can read notifications from AMQP queues and provide an Atom API. This application generates Atom feeds of the notifications, and can publish feeds via [[PubSubHubbub]] (PSH) for efficient distribution of data to subscribers.
  
 
== Rationale ==
 
== Rationale ==
 +
As a systems integrator, we need the ability for 3rd party systems to query usage information from Nova to determine how to charge customers for use of the platform.
  
As a systems integrator, we need the ability for 3rd party systems to query usage information from Nova to determine how to charge customers for use of the platform.
+
Enterprise customers also need the ability to determine usage data, though for different reasons. For example, a cloud administrator may want to determine VMs that have not been used in several month so that they can be reclaimed and the resources reallocated. Some IT departments may implement a quota system for their users.
 
 
Enterprise customers also need the ability to determine usage data, though for different reasons. For example, a cloud administrator may want to determine VMs that have not been used in several month so that they can be reclaimed and the resources reallocated. Bandwidth statistics at the individual VM level could be used to optimize load balancing and deployment efficiency. And some IT departments may implement a quota system for their users.
 
  
Note that Nova itself should not be concerned with billing, but it needs to collect the usage data and aggregate it for a requested time period, as well as potentially reset any counters involved.  
+
Note that Nova itself should not be concerned with billing, but it needs to present a feed of usage data that an external application could use to aggregate the billing data for a requested time period.
  
 
== User stories ==
 
== User stories ==
 
 
# As a systems integrator, I need to retrieve usage data so that I can properly bill my customers.
 
# As a systems integrator, I need to retrieve usage data so that I can properly bill my customers.
 
# As a systems integrator or enterprise cloud administrator, I want to monitor usage data over time so that I can optimize the utilization of my resources.
 
# As a systems integrator or enterprise cloud administrator, I want to monitor usage data over time so that I can optimize the utilization of my resources.
 
# As an business or agency that supports multiple projects, I need to account for the resources consumed by each project so that I can properly meet accounting and budget standards.
 
# As an business or agency that supports multiple projects, I need to account for the resources consumed by each project so that I can properly meet accounting and budget standards.
# As a systems integrator, I need to provide usage data to multiple third-party systems without building custom interfaces to each one so that I can efficiently utilize my manpower.  
+
# As a systems integrator, I need to provide usage data to multiple third-party systems without building custom interfaces to each one so that I can efficiently utilize my manpower.
  
 
== Assumptions ==
 
== Assumptions ==
 +
Usage data can be aggregated by Tenant ID (as defined in the [[openstack-accounting]] blueprint).(i.e. Tenant ID is always present)
  
Usage data is retrieved by Tenant ID (as defined in the [[openstack-accounting]] blueprint - is this still relevant?).
+
There is a billing system that is not a part of [[OpenStack]]. Invoicing, billing, and customer management are handled externally to [[OpenStack]]/Nova. Nova only has knowledge of an "tenant ID" (as per the [[openstack-accounting]] blueprint).
  
There is a billing system that is not a part of [[OpenStack]]. Invoicing, billing, and customer management are handled externally to [[OpenStack]]/Nova. Nova only has knowledge of an "tenant ID" (as per the [[openstack-accounting]] blueprint -- relevant?).
+
The Tenant ID is the same as the tenant id concept in Keystone, and is known internally to Nova as the "Project ID".
  
The "tenant ID" is "not" the same as the (existing) project_id; there may be multiple projects under a single account ID.
+
If Nova is installed in multiple regions (aka "zones"), usage data will not span zones; even if the same tenant ID is used in multiple zones, that data must be aggregated external to Nova.
 
 
* *NOTE**: if we need to store account as well as tenant, we need to revisit keystone!  Current design is that open stack services are only given tenant and user.
 
 
 
If Nova is installed in multiple regions (aka "zones"), usage data will not span zones; even if the same tenant ID is used in multiple zones, that data must be aggregated external to Nova.  
 
 
 
The usage data API is queried against a regional endpoint, and not directly against the host. (open for discussion)
 
  
 
== Design and Implementation ==
 
== Design and Implementation ==
 +
=== Event Types and Payload data: ===
 +
==== compute.instance.create: ====
 +
* Usage notification upon creation of a new instance.
 +
* '''tenant_id''':  Tenant ID that owns the this instance (string)
 +
* '''user_id''':  User ID that owns this instance (string)
 +
* '''instance_id''':  Nova instance ID of this instance (string)
 +
* '''instance_type''':  Name of the instance type ('flavor') of this instance. (string)
 +
* '''instance_type_id''': Nova ID for instance type ('flavor') of this instance. (string)
 +
* '''display_name''': User selected display name for instance.
 +
* '''created_at''': Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''launched_at''': Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''image_ref''':  Image URL (from Glance) that this instance was created from. (string)
  
=== Event Data ===
+
==== compute.instance.delete: ====
 
+
* Usage notification upon deletion of an instance.
We need to have a model for usages that record a usage every time an action ("event") happens on a vm. Events include creation, resizes, deletions, add/remove ips, etc. In theory, any event should be logged; in practice, it may be suitable to focus only on those events that are of significant interest to the [[OpenStack]] community.
+
* '''tenant_id''': Tenant ID that owns the this instance (string)
 
+
* '''user_id''':  User ID that  owns this instance (string)
Event data would include something similar, but not strict to the following:
+
* '''instance_id''':  Nova  instance ID of this instance (string)
 
+
* '''instance_type''': Name of the instance type ('flavor') of this instance. (string)
{| border="1" cellpadding="2" cellspacing="0"
+
* '''instance_type_id''': Nova ID  for instance type ('flavor') of this instance. (string)
'''Data Type'''  
+
* '''display_name''': User  selected display name for instance.
| '''Name'''
+
* '''created_at''': Timestamp for  when this instance's record was created in Nova (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
|-
+
* '''launched_at''': Timestamp for when this instance was last launched by hypervisor. (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
| t.integer
+
* '''image_ref''':  Image URL (from Glance) that this instance was created from. (string)
| instance_id
 
|-
 
| t.integer
 
| ram_size
 
|-
 
| t.integer
 
| disk_size
 
|-
 
| t.string
 
| tenant_id
 
|-
 
| t.integer
 
| used_tx
 
|-
 
| t.integer
 
| used_rx
 
|-
 
| t.integer
 
| has_backups
 
|-
 
| t.integer
 
| extra_ips
 
|-
 
| t.datetime
 
| started_at
 
|-
 
| t.datetime
 
| ended_at
 
|-
 
| t.datetime
 
| created_at
 
|-
 
| t.datetime
 
| updated_at
 
|-
 
| t.string
 
| options
 
|}
 
 
 
This could potentially be made generic by specifying the attributes to be tracked and recorded in a configuration file. Ideally, the usage tracking API should be extensible so that users may track specific usage data of interest to themselves without the need to modify the core Nova system.
 
 
 
=== API ===
 
 
 
==== RETURN FORMAT ====
 
 
 
The usage data API will return [http://www.ietf.org/rfc/rfc4287.txt Atom 1.0]-formatted data.
 
 
 
(*NOTE* this proposal is still being evaluated; please do not start implementation before a final determination is made.) The proposed method for returning structured data is by using the [http://www.odata.org/ Open Data Protocol] embedded within the Atom feed.
 
 
 
==== CACHING ====
 
 
 
GET requests MUST return a Cache-Control: header.
 
 
 
The default cache time (in seconds) MUST be configurable by a system-wide setting. For example, if the system setting for cache time is 60 seconds, then an API GET request should return:
 
 
 
Cache-Control: max-age=60
 
 
 
If the user wishes to disable caching, use a cache setting of 0.
 
 
 
==== METHODS ====
 
 
 
{| border="1" cellpadding="2" cellspacing="0"
 
'''URN'''  
 
'''Method'''  
 
'''Returns'''  
 
|-
 
|rowspan="4" | /v1.0/usage
 
| GET
 
| returns aggregated usage information for the entire Nova instance/zone
 
|-
 
|  PUT
 
|  405 Method Not Allowed
 
|-
 
|  POST
 
|  405 Method Not Allowed
 
|-
 
|  DELETE
 
|  405 Method Not Allowed
 
|-
 
|rowspan="4" | /v1.0/''tenantId''/usage
 
|  GET
 
|  Returns aggregated usage data for the specified tenant. Strictly speaking, GET requests should be idempotent; however, because usage data may have some latency, a second GET request may return (slightly) different data
 
|-
 
|  PUT
 
|  405 Method Not Allowed
 
|-
 
|  POST
 
|  Returns aggregated usage data for the specified account as per GET; however, the POST request also resets ongoing counters to zero.
 
|-
 
|  DELETE
 
|  Resets aggregated usage data for the specified account.
 
|}
 
 
 
==== QUERY STRINGS ====
 
 
 
All queries must be able to be constrained by a timestamp:
 
 
 
/''version''/''tenantID''/usage?begin=''timestamp1''&end=''timestamp2''
 
 
 
''It's probably best not to provide search functionality like this on the host node. We should do our best to keep the database on each host node as small as we reasonably can. The API would be useful with this capability, but it should search through a data store at a region level.''
 
 
 
In these cases, the begin value is compare as being "greater than or equal to" and the end value as "less than." This allows for inclusive date/time ranges without, for example, the need to specify complex operators.
 
 
 
This could get propagated to the regional level and then put into a log db for retrieval later or processing. The api to retrieve usages would look at this secondary db and not the configuration db.
 
 
 
''timestamp1'' and ''timestamp2'' are UNIX timestamp values.
 
 
 
This paradigm works for event type data, but it's not optimal for accumulation of usage that happens out-of-band from the API. For example, you may create an instance, and it remains on through an entire billing cycle, consuming network bandwidth during that period. If bandwidth should be billable, there would need to be regular "bandwidth used" events in the event stream that get added up when it's time to bill for them. It might make more sense to have a separate solution for cumulative counters (like bandwidth) that can be externally retreived on regular intervals rather than having some sort of local scheduler that generates events on such intervals. This way the collection interval could vary on a per-instance basis and no complex scheduler logic would need to be tracked on the host node.
 
 
 
=== Notifications ===
 
 
 
The event-tracking worker should provide the ability to perform [[PubSubHubbub]] (PSH) notifications based on configuration settings (i.e., this functionality can be disabled via a configuration flag).
 
 
 
See the [https://blueprints.launchpad.net/nova/+spec/notification-system Notification System] blueprint for details.
 
 
 
The configuration must also allow zero or more PSH endpoints ("hubs") to be defined.
 
 
 
When an events occurs and notifications are enabled, then the worker would issue [http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#anchor9 a standard PSH "ping"].
 
 
 
Specifically, it would issue a POST request to the hubs defined in the configuration; the POST would include the content-type and parameters as defined in the specification.
 
 
 
Note that [[PubSubHubbub]] is optional; the API may always be retrieved via a simple Atom 1.0 query.
 
 
 
== Dependencies ==
 
 
 
"Customer," in this case, is simply the account code specified in the [https://blueprints.launchpad.net/nova/+spec/multi-tenant-accounting multi-tenant-accounting blueprint].
 
 
 
Notifications require the implementation of the [https://blueprints.launchpad.net/nova/+spec/notification-system Notification System blueprint].
 
 
 
"Instance," must be independent of Customer (actions, usages) in the event of a transfer between Customers.
 
 
 
=== Instance Diagnostics ===
 
 
 
already available via the API and [[XenTools]] - they just need to be stored in the DB
 
 
 
=== Instance Actions ===
 
 
 
already available for all XenAPI calls (also available via the API) - this will need to be implemented for every action that is performed outside of the XenAPI itself
 
 
 
=== Migration ===
 
 
 
N/A
 
 
 
== Test/Demo Plan ==
 
 
 
This need not be added or completed until the specification is nearing beta.
 
  
== Unresolved issues ==
+
==== compute.instance.rebuild: ====
 +
* Usage notification upon rebuild of instance.
 +
* '''tenant_id''':  Tenant ID that  owns the this instance (string)
 +
* '''user_id''':  User ID that  owns this instance (string)
 +
* '''instance_id''':  Nova  instance ID of this instance (string)
 +
* '''instance_type''':  Name of  the instance type ('flavor') of this instance. (string)
 +
* '''instance_type_id''': Nova ID  for instance type ('flavor') of this instance. (string)
 +
* '''display_name''': User  selected display name for instance.
 +
* '''created_at''': Timestamp for  when this instance's record was created in Nova (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''launched_at''': Timestamp for  when this instance was last launched by hypervisor. (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''image_ref''':  Image  URL (from Glance) that this instance <u>is being rebuilt</u> from.  (string)
  
The actual usage data is still under consideration and needs further definition.  
+
==== compute.instance.resize.prep: ====
 +
* Usage notification when a resize/migrate of an instance is begun.
 +
* '''tenant_id''':  Tenant ID that  owns the this instance (string)
 +
* '''user_id''':  User ID that  owns this instance (string)
 +
* '''instance_id''':  Nova  instance ID of this instance (string)
 +
* '''instance_type''':  Name of  the <u>current</u> (before resize) instance type ('flavor') of this instance. (string)
 +
* '''instance_type_id''': Nova ID  for <u>current</u> (before resize) instance type ('flavor') of this instance. (string)
 +
* '''new_instance_type''':  Name of  the new (after  resize) instance type ('flavor') of this instance. (string)
 +
* '''new_instance_type_id''': Nova ID  for new (after  resize) instance type ('flavor') of this instance. (string)
 +
* '''display_name''': User  selected display name for instance.
 +
* '''created_at''': Timestamp for  when this instance's record was created in Nova (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''launched_at''': Timestamp for  when this instance was last launched by hypervisor. (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''image_ref''':  Image  URL (from Glance) that this instance was  created from. (string)
  
== BoF agenda and discussion ==
+
==== compute.instance.resize.confirm: ====
 +
* Usage notification when a resize/migration of an instance has been confirmed by the user.
 +
* '''tenant_id''':  Tenant ID that  owns the this instance (string)
 +
* '''user_id''':  User ID that  owns this instance (string)
 +
* '''instance_id''':  Nova  instance ID of this instance (string)
 +
* '''instance_type''':  Name of  the current instance type ('flavor') of this instance. (i.e. the one it has been resized to.) (string)
 +
* '''instance_type_id''': Nova ID  for the current instance type ('flavor') of this instance. (i.e. the one it has been resized to.) (string)
 +
* '''display_name''': User  selected display name for instance.
 +
* '''created_at''': Timestamp for  when this instance's record was created in Nova (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''launched_at''': Timestamp for  when this instance was last launched by hypervisor. (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''image_ref''':  Image URL (from Glance) that this instance was created from.  (string)
  
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
+
==== compute.instance.resize.revert: ====
 +
* Usage notification when a resize/migration of an instance has been reverted by the user.
 +
* '''tenant_id''':  Tenant ID that  owns the this instance (string)
 +
* '''user_id''':  User ID that  owns this instance (string)
 +
* '''instance_id''':  Nova  instance ID of this instance (string)
 +
* '''instance_type''':  Name of  the current instance type ('flavor') of this instance. (i.e. the one it has been reverted back to.) (string)
 +
* '''instance_type_id''':  Nova ID  for the current instance type ('flavor') of this instance. (i.e. the one it has been reverted back to.) (string)
 +
* '''display_name''':  User  selected display name for instance.
 +
* '''created_at''': Timestamp for  when this instance's record was created in Nova (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''launched_at''': Timestamp for when this instance was last launched by hypervisor. (string, formatted  "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''image_ref''':  Image  URL (from Glance) that this instance was  created from. (string)
  
----
+
==== compute.instance.exists: ====
[[Category:Spec]]
+
* Periodic usage notification generated by the instance-usage-audit cron job. These usages are generated for '''each''' instance that has been neither '''created''' not '''deleted''' during the specified audit period.  Aggregating these usages with the compute.instance.create and compute.instance.delete usages for the audit period will give a complete account of instance usage for each tenant during the audit period.
 +
* '''tenant_id''':  Tenant ID that owns the this instance (string)
 +
* '''user_id''':  User ID that owns this instance  (string)
 +
* '''instance_id''':  Nova  instance ID of this instance (string)
 +
* '''instance_type''':  Name of the instance type ('flavor') of this instance. (string)
 +
* '''instance_type_id''': Nova ID for instance type  ('flavor') of this instance. (string)
 +
* '''display_name''':  User selected display name for instance.
 +
* '''created_at''': Timestamp for when this instance's  record was created in Nova (string, formatted "YYYY-MM-DD  hh:mm:ss.ssssss")
 +
* '''launched_at''':  Timestamp for when this instance was last launched by hypervisor.  (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
 +
* '''image_ref''':  Image URL (from Glance) that this  instance was created from. (string)
 +
* '''audit_period_begining''':  Timestamp of beginning of audit period. (string, formatted "YYYY-MM-DD  hh:mm:ss.ssssss")
 +
* '''audit_period_ending''':  Timestamp of end of audit period. (string, formatted "YYYY-MM-DD  hh:mm:ss.ssssss")

Revision as of 10:54, 12 July 2011

<<TableOfContents()>>

Summary

Nova administrators want data on system usage for billing, chargeback, or monitoring purposes.

Release Note

System usage data is emitted from Nova in the form of usage events from Nova's Notifications system. The notifications system can be configured to emit events either through nova's logging facility, or send them to a series of AMQP queues (one per notification priority). System usages are emitted as notification events with the INFO priority. Different types of usage events are distinguished via the notifications' event_type, which is a hierarchical dotted string such as compute.instance.create, which allows usages to be easily grouped for aggregation. Usage notifications can be immediate, created when a specific increment of usage occurs (such as creation of an instance) or periodic, generated by a periodic task, like a cron job, and covering usage for a certain period of time. Besides the standard Nova Notification priority, notification timestamp, and event_type, usage notifications contain a payload of data that will vary depending on the event_type. This is presented as a json-formatted hash of key-value pairs. Some of the keys, such as tenant_id will always be present in any usage notification, others will be data relevent to that event_type (For example, instance related notifications will contain data describing the instance.)

An external application (https://github.com/Cerberus98/yagi) is available that can read notifications from AMQP queues and provide an Atom API. This application generates Atom feeds of the notifications, and can publish feeds via PubSubHubbub (PSH) for efficient distribution of data to subscribers.

Rationale

As a systems integrator, we need the ability for 3rd party systems to query usage information from Nova to determine how to charge customers for use of the platform.

Enterprise customers also need the ability to determine usage data, though for different reasons. For example, a cloud administrator may want to determine VMs that have not been used in several month so that they can be reclaimed and the resources reallocated. Some IT departments may implement a quota system for their users.

Note that Nova itself should not be concerned with billing, but it needs to present a feed of usage data that an external application could use to aggregate the billing data for a requested time period.

User stories

  1. As a systems integrator, I need to retrieve usage data so that I can properly bill my customers.
  2. As a systems integrator or enterprise cloud administrator, I want to monitor usage data over time so that I can optimize the utilization of my resources.
  3. As an business or agency that supports multiple projects, I need to account for the resources consumed by each project so that I can properly meet accounting and budget standards.
  4. As a systems integrator, I need to provide usage data to multiple third-party systems without building custom interfaces to each one so that I can efficiently utilize my manpower.

Assumptions

Usage data can be aggregated by Tenant ID (as defined in the openstack-accounting blueprint).(i.e. Tenant ID is always present)

There is a billing system that is not a part of OpenStack. Invoicing, billing, and customer management are handled externally to OpenStack/Nova. Nova only has knowledge of an "tenant ID" (as per the openstack-accounting blueprint).

The Tenant ID is the same as the tenant id concept in Keystone, and is known internally to Nova as the "Project ID".

If Nova is installed in multiple regions (aka "zones"), usage data will not span zones; even if the same tenant ID is used in multiple zones, that data must be aggregated external to Nova.

Design and Implementation

Event Types and Payload data:

compute.instance.create:

  • Usage notification upon creation of a new instance.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the instance type ('flavor') of this instance. (string)
  • instance_type_id: Nova ID for instance type ('flavor') of this instance. (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance was created from. (string)

compute.instance.delete:

  • Usage notification upon deletion of an instance.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the instance type ('flavor') of this instance. (string)
  • instance_type_id: Nova ID for instance type ('flavor') of this instance. (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance was created from. (string)

compute.instance.rebuild:

  • Usage notification upon rebuild of instance.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the instance type ('flavor') of this instance. (string)
  • instance_type_id: Nova ID for instance type ('flavor') of this instance. (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance is being rebuilt from. (string)

compute.instance.resize.prep:

  • Usage notification when a resize/migrate of an instance is begun.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the current (before resize) instance type ('flavor') of this instance. (string)
  • instance_type_id: Nova ID for current (before resize) instance type ('flavor') of this instance. (string)
  • new_instance_type: Name of the new (after resize) instance type ('flavor') of this instance. (string)
  • new_instance_type_id: Nova ID for new (after resize) instance type ('flavor') of this instance. (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance was created from. (string)

compute.instance.resize.confirm:

  • Usage notification when a resize/migration of an instance has been confirmed by the user.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the current instance type ('flavor') of this instance. (i.e. the one it has been resized to.) (string)
  • instance_type_id: Nova ID for the current instance type ('flavor') of this instance. (i.e. the one it has been resized to.) (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance was created from. (string)

compute.instance.resize.revert:

  • Usage notification when a resize/migration of an instance has been reverted by the user.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the current instance type ('flavor') of this instance. (i.e. the one it has been reverted back to.) (string)
  • instance_type_id: Nova ID for the current instance type ('flavor') of this instance. (i.e. the one it has been reverted back to.) (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance was created from. (string)

compute.instance.exists:

  • Periodic usage notification generated by the instance-usage-audit cron job. These usages are generated for each instance that has been neither created not deleted during the specified audit period. Aggregating these usages with the compute.instance.create and compute.instance.delete usages for the audit period will give a complete account of instance usage for each tenant during the audit period.
  • tenant_id: Tenant ID that owns the this instance (string)
  • user_id: User ID that owns this instance (string)
  • instance_id: Nova instance ID of this instance (string)
  • instance_type: Name of the instance type ('flavor') of this instance. (string)
  • instance_type_id: Nova ID for instance type ('flavor') of this instance. (string)
  • display_name: User selected display name for instance.
  • created_at: Timestamp for when this instance's record was created in Nova (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • launched_at: Timestamp for when this instance was last launched by hypervisor. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • image_ref: Image URL (from Glance) that this instance was created from. (string)
  • audit_period_begining: Timestamp of beginning of audit period. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")
  • audit_period_ending: Timestamp of end of audit period. (string, formatted "YYYY-MM-DD hh:mm:ss.ssssss")