Difference between revisions of "Reddwarf-actions"

Latest revision as of 16:46, 8 April 2013

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.