wiki:UseCases
Last modified 9 years ago Last modified on 05/11/10 11:05:43

Heckle Use Cases

Listed here are the various ways Heckle is intended to be used.

Heckle Admin Use Cases

Admin creates a user

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and creates a user.
  • Backend stores the data in the created user
  • If the validation fails, an error message is returned

Admin deletes a user

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and deletes the user
  • If the user doesn't exist, fail silently
  • If validation fails, return an error message

Admin modifies a user

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and locates the user
  • Backend updates the data in the user record
  • If validation fails or user is not found, return an error message

Admin lists a user

  • Admin provides either identifying information or no data via the admin tools to the backend
  • If no data is received, the Backend returns a list of all users in the system
  • If identifying information is received, the Backend returns a list of users that match the identifying information.
  • The admin tools format the data.

Admin creates an image

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and creates an image.
  • Backend stores the data in the created image
  • If the validation fails, an error message is returned
  • Admin then provides proper information about the image stages via the admin tools to the backend
  • Backend validates the data and creates image stages.
  • Backend stores the data in the created image stages and attaches the stages to the image
  • If the validation fails, an error message is returned

Admin deletes an image

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and deletes the image and any attached stages
  • If the image doesn't exist, fail silently
  • If validation fails, return an error message

Admin modifies an image

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and locates the image
  • Backend updates the data in the image record
  • If validation fails or image is not found, return an error message

Admin lists an image

  • Admin provides either identifying information or no data via the admin tools to the backend
  • If no data is received, the Backend returns a list of all images and their data in the system
  • If identifying information is received, the Backend returns a list of images and their data that match the identifying information.
  • The admin tools format the data.

Admin creates a hardware class

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and creates a hardware class.
  • Backend stores the data in the created hardware class
  • If the validation fails, an error message is returned

Admin deletes a hardware class

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and deletes the hardware class
  • If the hardware class doesn't exist, fail silently
  • If validation fails, return an error message

Admin modifies a hardware class

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and locates the hardware class
  • Backend updates the data in the hardware class record
  • If validation fails or hardware class is not found, return an error message

Admin lists a hardware class

  • Admin provides either identifying information or no data via the admin tools to the backend
  • If no data is received, the Backend returns a list of all hardware classes in the system
  • If identifying information is received, the Backend returns a list of hardware classes that match the identifying information.
  • The admin tools format the data.

Admin creates a node

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and creates a node.
  • Backend stores the data in the created node
  • If the validation fails, an error message is returned

Admin deletes a node

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and deletes the node
  • If the node doesn't exist, fail silently
  • If validation fails, return an error message

Admin modifies a node

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and locates the node
  • Backend updates the data in the node record
  • If validation fails or node is not found, return an error message

Admin lists a node

  • Admin provides either identifying information or no data via the admin tools to the backend
  • If no data is received, the Backend returns a list of all nodes in the system
  • If identifying information is received, the Backend returns a list of nodes that match the identifying information.
  • The admin tools format the data.

Admin creates a power controller

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and creates a power controller.
  • Backend stores the data in the created power controller
  • If the validation fails, an error message is returned

Admin deletes a power controller

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and deletes the power controller
  • If the power controller doesn't exist, fail silently
  • If validation fails, return an error message

Admin modifies a power controller

  • Admin provides proper information via the admin tools to the backend
  • Backend validates the data and locates the power controller
  • Backend updates the data in the power controller record
  • If validation fails or power controller is not found, return an error message

Admin lists a power controller

  • Admin provides either identifying information or no data via the admin tools to the backend
  • If no data is received, the Backend returns a list of all power controllers in the system
  • If identifying information is received, the Backend returns a list of power controllers that match the identifying information.
  • The admin tools format the data.

Admin creates a reservation

  • Admin provides criteria for selecting nodes via the admin tools to the backend.
  • Backend filters nodes by the criteria and creates a new reservation with the matching nodes.
  • If the criteria fail to match nodes, backend returns an error message.
  • Backend returns a list of all nodes reserved.

Admin frees a node from a reservation

  • Admin provides identifying information via the admin tools to the backend.
  • Backend validates the identifying information
  • If a reservation is provided, the backend removes the node from the reservation
  • If no reservation is provided, the backend removes the node from the soonest reservation
  • If the validation fails, the backend returns an error message.
  • If the reservation is now empty, the backend marks it as expired.
  • If the node is not part of a reservation, do nothing

Admin lists a reservation

  • Admin provides either identifying information or no data via the admin tools to the backend
  • If no data is received, the Backend returns a list of all reservations in the system
  • If identifying information is received, the Backend returns a list of reservations that match the identifying information.
  • The admin tools format the data.

Admin creates an allocation

  • Admin provides proper information along with reservation identifying information via the admin tools to the backend.
  • The backend validates the information and creates an allocation.
  • If the validation fails, the backend returns an error message.
  • The admin tools list the allocated nodes.

Admin creates an allocation with no existing reservation

  • Admin provides proper information to the admin tools.
  • Admin tools send a request to the backend to create a reservation.
  • If reservation fails, admin tools return an error message.
  • Admin tools send a request to the backend to create an allocation inside the reservation.
  • If the allocation fails, admin tools request the reservation be deleted and return an error message.
  • Admin tools display a list of allocated nodes.

Heckle Client Use Cases

Client creates an allocation

  • Client provides proper information to the client tools.
  • Client tools send a request to the backend to create a reservation.
  • If reservation fails, client tools return an error message.
  • Client tools send a request to the backend to create an allocation inside the reservation.
  • If the allocation fails, client tools request the reservation be deleted and return an error message.
  • Client tools display a list of allocated nodes.

Client frees a node

  • Client provides identifying information via the client tools to the backend.
  • Backend validates the identifying information and removes the node from the soonest reservation the client owns
  • If the validation fails, the backend returns an error message.
  • If the reservation is now empty, the backend marks it as expired.
  • If the node is not part of a reservation, do nothing

Client lists allocation stats

  • Client requests allocation stats from the client tools
  • Client tools request listing of reservations from backend
  • Client tools format data and display it

Client lists node stats

  • Client requests node stats from the client tools
  • Client tools request listing of nodes and hardware from backend
  • Client tools format data and display it

Client lists property stats

  • Client requests property stats from the client tools
  • Client tools request listing of hardware from backend
  • Client tools format data and display it

Client lists image stats

  • Client requests image stats from the client tools
  • Client tools request listing of images from backend
  • Client tools format data and display it

Heckle Node Use Cases

Node requests config

  • Node requests config from config daemon
  • Config daemon resolves node by IP address
  • If the node can not be found, a message is logged and a blank config is returned
  • Config daemon validates node state
  • If the validation fails, a message is logged and a blank config is returned
  • Config daemon retrieves the config script and advances the stage if there are more stages
  • Config daemon returns the script to the node.

Node sends log message

  • Node sends log message data to config daemon
  • Config daemon validates message body
  • If validation fails, an error message is returned
  • If the message is an INFO message, the config daemon records the message in the node's log
  • If the message is a CONTROL message, the config daemon performs the control action

User requests a log history

  • User sends log request with identifying information or no information to config daemon.
  • If identifying information is provided, the config daemon returns log messages that match the information
  • If no identifying information is provided, the config daemon returns all log messages

Heckle Miscellaneous Use Cases

User performs power management

  • User makes a power management request via the admin tools to the backend
  • The backend validates the data and locates the correct power driver module
  • If the validation fails, an error message is returned
  • The requested power management function is called from the power driver module
  • If the power driver module fails, an error message is returned.
  • The results of the operation are returned to the user via the admin tools