Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, 2009-06-18 at 16:06 +0200, Daniel Veillard wrote:
On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote:
> On Wed, Jun 17, 2009 at 10:59:20PM +0000, David Lutterkort wrote:
>
The problem with the propsal is that it opens the door to a variety of
errors like using the same familly twice, which I would like to avoid
at the RNG level but it's not trivial.
An alternative is to drop the <addresses/> tag and just stick a
type=ipv4|ipv6 attribute on the <ip/> tags .. though that requirs that
we do the same for <route/> tags, and I have no idea what routing in
non-IP protocols looks like.
We should allow standalone IPv4 and IPv6, or both. Each could
either
use DHCP or allow one or more IP address and routes.
I think if we have routes, at most one need to be a gateway and the
other ones having destination + prefix.
So I suggest the following rewrite of interface-addressing
<!-- Assignment of IP address to an interface -->
<define name="interface-addressing">
<choice>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
<group>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
</group>
</choice>
</define>
Ok.
This allows one or 2 blocks of addresses ipv4, ipv6 or both
<define name="interface-addr-ipv4">
<element name="addresses">
<attribute name="family">
<value>ipv4</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
An IPv4 addresses block, allows for either static or dhcp
<define name="interface-addr-ipv6">
<element name="addresses">
<attribute name="family">
<value>ipv6</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
interface-addr-static and interface-addr-dhcp need to be split into ipv4
and ipv6 specific branches, so that we can typecheck that we don't use
an ipv6 address in an ipv4 addressing block.
Ultimately, that means we need ipv4 and ipv6 versions of ip-addr and
prefix-pattern.
For DHCP the only option is the peerdns yes/no attribute
There's a few more options we need to add for completeness, at least
PERSISTENT_DHCLIENT, DHCPRELEASE, and DHCLIENT_IGNORE_GATEWAY are
supported by initscripts.
And for routes we have at least one default route
Default route should be optional.
This makes parsing a bit heavier, and I didn't checked if this
really
affected bridging and bonding interfaces in a wrong way, but I think
that at least at an ethernet level definition this looks more complete.
It only affects it in so far as interface-addressing is also used for
the toplevel bridge/bond devices, which AFAIK is ok.
That said I have no idea how much of a problem it would be on the
netcf
impletmentation side.
I will find out ;)
P.S.: full rng attached, double check the prefix-pattern definition
I have no idea if it's sufficient for Ipv6
For ipv4, prefix is in the range 1..32, for ipv6, it's 1..128.
David