API Access Key

API Access Keys are used within organization services. They are used to provide programmtic access to the cloud environment. They can be associated with a user that can be an individual, e.g., Jane Doe, or an application, e.g., DivvyCloud. This class inherits from Resource and has direct access to the resource’s database object. The following attributes are directly accessible:

attr organization_service_id:
 The ID of the parent organization service (cloud)
attr access_key_id:
 The provider id for the API access key
attr status:Whether the key is active or inactive
attr user_resource_id:
 The ID of the user associated with the key
attr create_date:
 The date the API access key was created
attr last_used_date:
 The date the API access key was last used or None
attr resource_id:
 The primary resource identifier that takes the form of a prefix followed by numbers and letters
class DivvyResource.Resources.serviceaccesskey.ServiceAccessKey(resource_id)

Bases: DivvyResource.Resources.resource.Resource

Describes a cloud provider access key within a organization service

delete(user_resource_id=None)

Delete this resource. If wrapped in a with JobQueue() block, this will queue the deletion job to the wrapped queue, otherwise it calls immediately.

get_date_created()

Retrieve the time from the provider that this resource was created (if available).

static get_db_class()
get_db_pk()
static get_provider_id_field()
get_resource_name()

Returns the ID of the access key as there is no name

static get_resource_name_field()

Overrides parent function and returns the description field of this resource. This is required because not all resource types have a field explicitly called name.

static get_resource_type()
get_supported_actions()

Retrieve all the actions which are supported by this resource.

handle_resource_created(user_resource_id=None, project_resource_id=None)

This should be called when a resource is created/discovered after the basic data is added to the database. This gives an opportunity for post-addition hooks (assignment to groups, alerts, etc)

handle_resource_destroyed(user_resource_id=None)

This should be called when a resource is destroyed before the basic data is removed from the database. This gives an opportunity for pre-destruction hooks (removal from groups, alerts, etc)

handle_resource_modified(resource, *args, **kwargs)

This should be called when a resource is modified after the new data has been updated in the DB session This gives an opportunity for post-modification hooks

update_status(status, user_resource_id=None)

Delete this resource. If wrapped in a with JobQueue() block, this will queue the deletion job to the wrapped queue, otherwise it calls immediately.