Define state machines

https://blueprints.launchpad.net/blazar/+spec/state-machine

Define state machines for leases, reservations, and events, and use the status field of the leases table which is unused for now.

Problem description

Statuses of leases, reservations, and events cannot properly describe some actual statuses because state machines for leases, reservations, and events are not well defined for now. It causes inconsistency of statuses, unrecoverable failures and so on.

Actually, currently leases have no status. Even though the leases table has a status field, it is not used. It should be used to describe the status of a lease properly.

Use Cases

  • A lease owner can see the exact status of the lease in the lease parameters included in the request response.

Proposed change

Overview

Define state machines of leases, reservations, and events as follows.

Lease statuses

Lease statuses are categorized into 2 types: stable or transitional. In the state machine shown below, stable statuses are drawn as black nodes while transitional statuses are drawn as gray nodes. Stable statuses change to transitional statuses when a specific method of the blazar manager is called. After the method has completed or failed, the transitional statuses change to stable statuses.

A lease has the following four stable statuses:

  • PENDING: A lease has been successfully created and is ready to start. The lease stays in this status until it starts.

  • ACTIVE: A lease has been started and is active.

  • TERMINATED: A lease has been successfully terminated.

  • ERROR: Unrecoverable failures happened to the lease.

Transitional statuses are as follows:

  • CREATING: A lease is being created.

  • STARTING: A lease is being started.

  • UPDATING: A lease is being updated.

  • TERMINATING: A lease is being terminated.

  • DELETING: A lease is being deleted. Any status can change to this status because delete is the highest prioritized operation. e.g. when a lease hangs up in the STARTING status, delete should be allowed.

../../_images/lease_statuses.png

Reservation statuses

A reservation has the following four statuses. Small letters are used for backward compatibility:

  • pending: A reservation has been successfully created and is ready to start. The reservation stays in this status until it starts.

  • active: A reservation has been started and is active.

  • deleted: Reserved resources have been successfully released.

  • error: Unrecoverable failures happened to resources.

../../_images/reservation_statuses.png

Event statuses

Event statuses are not changed.

../../_images/event_statuses.png

Relationships between statuses

The following table shows conditions of statuses of reservations and events that have to be satisfied for each lease status.

Lease

Reservations

Events

CREATING

pending

start_lease: UNDONE , end_lease: UNDONE

PENDING

pending

start_lease: UNDONE , end_lease: UNDONE

STARTING

pending or active or error

start_lease: IN_PROGRESS , end_lease: UNDONE

ACTIVE

active

start_lease: DONE , end_lease: UNDONE

TERMINATING

active or deleted or error

start_lease: DONE , end_lease: IN_PROGRESS

TERMINATED

deleted

start_lease: DONE , end_lease: DONE

DELETING

Any status

Any status

UPDATING

Any status

Any status other than IN_PROGRESS

Alternatives

Express resource capacity sufficiency as a lease status like _DEGRADED statuses and a reservation status like *_MISSING_RESOURCES and *_RESOURCES_CHANGED. The problem of this solution is that it complicates state machines. Instead, we will introduce boolean flags like *degraded to leases and reservations for expressing such resource capacity sufficiency. See the resource-monitoring spec[1] in detail.

Data model impact

None

RESTAPI impact

None

Security impact

None

Notifications impact

None

Other end user impact

  • Users can see the lease status.

Performance Impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

hiro-kobayashi

Work Items

  • Implement LeaseStatus, ReservationStatus and EventStatus class that contain statuses and basic methods for managing these statuses.

  • Implement a decorator that checks/updates the lease status before/after *-lease methods of manager.

  • Decorate *-lease methods with the decorator.

Dependencies

None

Testing

  • Test status transitions.

Documentation Impact

None

References

History

Revisions

Release Name

Description

Queens

Introduced