I meant to send this out a while back, but don't see that I ever actually sent it. I'm currently reworking the matahari agents to clean up the code, refactor elements and also enhance the agents. And the one that has me stumped is the NIC agent. The main problem is that, if we're going to represent network interfaces, we shouldn't limit it to only physical devices. Instead, I feel that it should represent all network devices, including virtual interfaces, bridges, etc. So what I was thinking about was to have an agent to represent the physical device, and then agents under it to represent the network(s) to which it is associated. So the physical device would represented by a NetworkDevice agent with the following properties/methods: * mac_address - address for device * vendor - the NIC manufacturer * model - the NIC model * interface - the system iface name * create() - creates a network definition * destroy() - deletes the network definition * blink() - causes the device to blink, so it can be identified The properties are, hopefully, pretty clear. The methods will likely need a little more clarification. create() - Takes arguments that configure the network to which the device is to be connected; i.e., the address, netmask, gateway, DNS entries, whether to use DHCP, etc. This can become a very heavy method so might logically be broken up into related methods. destroy() - The reverse of connect(), it would take down an active network. An option argument would indicate to also delete the configuration file(s) for the network. The Network agent would represent the networks to which a NetworkDevice is connected. It has a parent reference to the NetworkDevice parent, and has the following properties/methods: * active - reports whether the interface is up or down * address - the assigned network address [1] * netmask * gateway * DNS * bridge - reports whether the interface is a bridge * virtual - reports whether the interface is virtual * up() - brings the interface up * down() - stops the interface Granted, this is not a complete list: here is where I really would like to kick around some ideas of how we ought to implement things if we go in this direction. In addition to being directed by the management server, the status of Network agents would be affected by local messaging (dbus?) to keep its status as real-time as possible. Ideas? Questions? [1] - duplication is needed to support IPv6 -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20100419/e639862c/attachment.sig>