-
Notifications
You must be signed in to change notification settings - Fork 4
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
Decouple juniper #18
Conversation
@@ -0,0 +1,2 @@ | |||
# this class will inherit from hardware_service.py and overwrite all of its methods |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
# 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...
@@ -0,0 +1,2 @@ | |||
# this class will inherit from hardware_service.py and overwrite all of its methods |
There was a problem hiding this comment.
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...
added mock_driver.py, which will be for testing without hardware, and moved all drivers into new subdirectory, hardware_drivers
@saacg, do you have another commit with code, too? If so, can we put the two together? |
The new files I added contain comments that describe a potential design @djfinn14 and I discussed (and presented to the team) to decouple QUADS from Juniper and allow it to use HIL, while making minimal changes to the current QUADS architecture. Is this going in the right direction? Any feedback would be much appreciated. Thanks!
(The design was inspired by how HIL uses abstract classes for switches and obm, which are then subclassed by specific drivers. See https://github.com/CCI-MOC/hil/tree/master/haas/ext and https://github.com/CCI-MOC/hil/blob/master/haas/class_resolver.py. Abstract Switch and OBM classes are defined in haas/model.py: https://github.com/CCI-MOC/hil/blob/master/haas/model.py )