Determine the remaining gap between nova's API and notifications
Nova represents probably the most serious problem with API hits; a nova boot results in several update notifications each of which we end up hitting the API. We need to figure out what's still missing from notifications, whether we can add to them, and whether we can handle not having any missing information. Being able to index from the notifications alone will be extremely beneficial at scale.
https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Essential
- Drafter:
- Steve McLellan
- Direction:
- Approved
- Assignee:
- Steve McLellan
- Definition:
- Approved
- Series goal:
- Accepted for newton
- Implementation:
- Implemented
- Milestone target:
- newton-1
- Started by
- Travis Tripp
- Completed by
- Travis Tripp
Related branches
Related bugs
Sprints
Whiteboard
Fields missing from api v2 versus api version 2.25 (mitaka stable):
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'description',
'host_status',
'locked'
Fields missing from notifications versus v225 api:
The only fields exactly common to notifications and the v225 API are: metadata, progress, tenant_id, user_id. Some are remapped (api -> notification):
{'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-SRV-
'OS-SRV-
'accessIPv4': 'access_ip_v4',
'accessIPv6': 'access_ip_v6',
'id': 'instance_id',
'image': 'image_meta',
'flavor': ['disk_gb', 'memory_mb', 'vcpus'],
'name': 'display_name'}
These are missing entirely:
{'OS-DCF:
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'OS-EXT-
'addresses',
'config_drive',
'description',
'flavor', # attributes are in the root payload
'hostId',
'host_status',
'key_name',
'locked',
'os-extended-
'security_
Of these, the most problematic are 'addresses' , security_groups, volumes. These are all denormalized by the API.
Added https:/