Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple juniper #18

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions lib/hardware_services/hardware_service.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# EC528 change
#
# This will be an abstract class (perhaps can use abc) that will serve as a generic interface
# for QUADS to interact with 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
# be able to continue with minimal changes (only thing that this will change is where QUADS pulls its data from)

# assuming for now that scheduling services will not have to be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...

2 changes: 2 additions & 0 deletions lib/hardware_services/hil_driver.py
Original file line number Diff line number Diff line change
@@ -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
2 changes: 2 additions & 0 deletions lib/hardware_services/quads_default_driver.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
# this class will inherit from hardware_service.py and overwrite all of its methods
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you consider changing this name to juniper_driver.py?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+# This will be an abstract class (perhaps can use abc) that will serve as a generic interface
+# for QUADS to interact with its hardware.

+# remove_host():
+# remove_cloud():
+# update_host():
+# update_cloud():
+# list_hosts():
+# list_clouds():

All this commands don't interact with hardware...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vsemp while they may not directly interact with the hardware in the current quads implementation, I think they are still required to manage hardware isolation. Therefore, they should still be included in the hardware_service class, right? What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@portante changed the name to juniper_driver.py. Thanks!

# with the current quads behavior (calling scripts that interface with juniper switches)