Decouple juniper

lib/hardware_services/hardware_drivers/hil_driver.py

@@ -0,0 +1,2 @@
+# this class will inherit from hardware_service.py and overwrite all of its methods
+# with hil-specific behaviors - mostly through api calls to the HIL server

lib/hardware_services/hardware_drivers/juniper_driver.py

@@ -0,0 +1,2 @@
+# this class will inherit from hardware_service.py and overwrite all of its methods
+# with the current quads behavior (calling scripts that interface with juniper switches)

lib/hardware_services/hardware_drivers/mock_driver.py

@@ -0,0 +1 @@
+# inherits from hardware_service.py and overwrites methods. This is a mock driver for testing purposes and will not be attached to any specific hardware

lib/hardware_services/hardware_service.py

@@ -0,0 +1,33 @@
+# EC528 change
+#
+# This will be an abstract class (perhaps can use abc) that will serve as a generic interface
+# for QUADS to interact with and isolate its hardware. It will allow QUADS to substitute different hardware
+# isolation services while making minimal changes to the current implementation of QUADS.
+
+# This class will declare methods corresponding to the functions defined in lib/libquads.py so that QUADS can
+# retain its normal workflow and command options. Once implemented, integration with a new hardware isolation
+# service will only require writing a driver that inherits from this class and overwrites its methods with
+# its service-specific behavior.
+
+# The hardware service used can be specified at runtime (by changing a single parameter in the conf/quads.yml file).
+# A user will specify the name of the service, which will be read in and used as a key in a dictionary (location tbd
+# - perhaps in libquads.py, or its own "class mapper" class?) that maps superclass to subclass.
+# Duck typing will be used to dynamically assign to a variable in libquads.py a concrete instance of the specified
+# subclass (using the "class mapper" dictionary). The quads library will thus be decoupled from any knowledge of
+# the specific hardware service being used, as it can now make calls based on this generic interface.
+
+
+# abstract methods to be overwritten by concrete subclasses:
+# note: these are only examples and do not describe the actual prototypes
+
+
+#   remove_host():
+#   remove_cloud():
+#   update_host():
+#   update_cloud():
+#   move_hosts():
+#   list_hosts():
+#   list_clouds():
+
+# this list may need to expand to accommodate for scheduling behavior, but for now we assume that scheduling
+# will be able to continue with minimal changes (only thing that this will change is where QUADS pulls its data from)