Reddwarf-actions

Data tier
the database will consist of 2 tables, actions and action_events. The actions will define the overall uuid/action (create instance, delete user, etc), and the action_events will contain the states that the action goes through while completing that state (resize, resize_verify, etc) CREATE TABLE actions (	created_at DATETIME, 	updated_at DATETIME, 	deleted_at DATETIME, 	deleted BOOLEAN, 	id INTEGER NOT NULL, 	action VARCHAR(255), 	instance_id VARCHAR(36), 	request_id VARCHAR(255), 	user_id VARCHAR(255), 	start_time DATETIME, 	finish_time DATETIME, 	message VARCHAR(255), 	PRIMARY KEY (id), 	CHECK (deleted IN (0, 1)) ); CREATE INDEX instance_id_idx ON actions (instance_id); CREATE INDEX request_id_idx ON actions (request_id);

CREATE TABLE action_events (	created_at DATETIME, 	updated_at DATETIME, 	deleted_at DATETIME, 	deleted BOOLEAN, 	id INTEGER NOT NULL, 	event VARCHAR(255), 	action_id INTEGER, 	start_time DATETIME, 	finish_time DATETIME, 	result VARCHAR(255), 	traceback TEXT, 	PRIMARY KEY (id), 	CHECK (deleted IN (0, 1)), 	FOREIGN KEY(action_id) REFERENCES actions (id) );

api
so far the general consensus is that additional fields will be added to some (or possibly all) GET calls to define the status and description of said status.