Scott Seago wrote:
Perry N. Myers wrote:We should probably have an explicit flag for DHCP vs. static -- although a separate "specified IP address" field (where blank or "DHCP" == DHCP) would work too. IP_ADDRESS should probably be used for the actual IP address.Darryl L. Pierce wrote:The new fields are netmask and broadcast. You will need to run a migration with this patch.I'm not the right one to give ACKs on object model changes in the DB, but this looks ok with one question...How does the administrator indicate that a given NIC should be configured via DHCP? Is this done by explicitly setting the IP_ADDRESS field?One of the things I'd like to get back from the host along with broadcast and netmask is the actual IP. In the case of a host that is statically configured this IP will be the same as the admin configured IP. But in the case of a NIC using DHCP this will be useful info for the administrator.If IP_ADDRESS is used to determine whether the NIC is DHCP or not, we can't just simply add IP_ADDRESS to the list of data that is sent back via the node identify process. Since that would overwrite the empty field and switch the NIC from DHCP to static.We either need a field in the NIC table that indicates what mode the NIC is in (DHCP, bootp, static) or we need a second IP_ADDRESS field that is the ACTUAL_IP_ADDRESS instead of the configured IP_ADDRESS. There is a field in the nics table right now called USAGE_TYPE. If that is the intent of this field, then just ignore my comments :)Perry
I'm in favor or a new field that has a constrained set of values (DHCP, bootp, static) that the user selects from in the Node Edit screen. If DHCP/bootp are selected the admin configurable ip address, netmask, DNS server, default gateway fields should all be greyed out. If static is selected all of these fields can be edited.
If the administrator selects DHCP/bootp then ovirt identify node puts in values for IP_ADDRESS, NETMASK, BROADCAST, DEFAULT_GATEWAY, DNS_SERVERS, etc... that are collected after the interface is brought up on the Node. However, these fields should still be greyed out to indicate that the information there is not configurable by the admin.
Based on the current data model it looks like for static config we're missing a few items like the default gateway and dns fields. We'll need to add those to the model/UI and also extract them from the Node during identify.
That all make sense?
Usage type is not for this at all. The intent of usage type is to identify what the NIC is used for (i.e. management NIC, etc.) When the comments field was proposed I'd initially considered that USAGE_TYPE might do this, but I think comments should probably be separate. USAGE_TYPE should be confined to a known list -- so it will be easy to deteremine the management NIC, etc. for a host.
Ok. I agree with keeping usage type as it is. A way of identifying what the purpose of the network interface is for. Storage, Management, Guest.
In addition to this drop down, we also need a user configurable Label field. This should be a drop down that is editable. i.e. the user can select that a NIC belongs to LAN A, LAN B or define a new one called LAN C. This way NICs can be grouped together for purposes of determining which Nodes are suitable to start a VM or migrate a VM.