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

Conversation

saacg
Copy link
Member

@saacg saacg commented Mar 22, 2017

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 )

@portante
Copy link
Member

@saacg, @vsemp, this will send a notification to the user by using the "at" sign username reference.

@@ -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!

# 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.

...

@portante portante self-assigned this Mar 22, 2017
@@ -0,0 +1,2 @@
# this class will inherit from hardware_service.py and overwrite all of its methods
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...

saacg added 2 commits March 23, 2017 09:36
added mock_driver.py, which will be for testing without hardware,
and moved all drivers into new subdirectory, hardware_drivers
@portante
Copy link
Member

portante commented Apr 7, 2017

@saacg, do you have another commit with code, too? If so, can we put the two together?

@portante portante mentioned this pull request Apr 10, 2017
@portante
Copy link
Member

@saacg, how does this PR reconcile with #30? Why are they different?

@saacg
Copy link
Member Author

saacg commented Apr 10, 2017

@portante this pr does not reconcile with #30. It is an old pr made so everyone could review the initial plan for making changes to QUADS via abstraction. It should have been closed as soon as #30 was made, and I will do so now.

@saacg saacg closed this Apr 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants