Jump to: navigation, search

Difference between revisions of "Reddwarf-actions"

(Created page with "== 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, de...")
 
(Data tier)
Line 3: Line 3:
  
 
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)
 
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 ===
 
=== 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.
 
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.

Revision as of 16:37, 8 April 2013

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.