Reddwarf-actions

Reddwarf actions

Data tier

the database will consist of 2 tables, actions and action_items. The actions will define the overall uuid/action (create instance, delete user, etc), and the action_items 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.