Changes between Version 11 and Version 12 of Internal/NewNodeAgent

Timestamp:

Jan 16, 2015, 10:43:10 PM (9 years ago)

Author:

ssugrim

Comment:

—

Internal/NewNodeAgent

@@ -166 +166 @@
 As a side note the different mode connect methods should check if the device is already connected and if so do nothing (regardless of which mode it is connected in).
 
----
+----
 ''' 12/24/2014 '''
 
 The agent commands second argument is a object of type OmfPubSubMessage. The source of this class is located [http://www.orbit-lab.org/browser/omf/omf-common/ruby/omf-common/communicator/omfPubSubMessage.rb here]. The path method produces the output we'll be switching on. The configure command calls the respective device_driver's configure command and expects a hash output. In this configure command is where the connect state needs to be implemented and maintained. 
+
+----
+''' 1/16/2014 '''
+
+We've decided that the drivers will store config state. We've also said that there must be an explict call to connect. In the ethernet context connect means bring the interface up. In the wifi context it will mean something different.  
+
+To that end I've implemented a config method in the ethernet that stores what configs were pushed in. I've also overridden the setter for device name. The new devicename method checks if the kmod as loaded before allwoing name assignment. If the kmod is loaded and name assignment succeeds, the connected state is checked (via ifconfig) and recorded, as well as the hardware mac.
+
+When a call to configure is made the connection state is checked. If it is connected the configure call tries to apply the change immedately, if it is not connected the configure call merely updates the hash.
+
+When a call to connect is made, the config hash is checked for values and if any exist the approriate configure call is made. The set of possible props is stored in a frozen has along with a pointer to the function that will handle that prop. Configure it self takes 2 string arguments, the first is the "prop name" to be configured, and the second is a value string. e.g. ("ip","192.168.1.1."). If a prop name hit occurs in the hash, the mapped function is called and the value feed as an argument to that function. 
+
+A similar design is going to be worked into the WIFI class.