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>
