[libvirt] [PATCH] v2:Support for adding a static route to a bridge

[Gene Czarcinski]

On 04/10/2013 03:09 PM, Laine Stump wrote:
> On 04/09/2013 04:28 PM, Gene Czarcinski wrote:
>> On 04/04/2013 12:08 PM, Laine Stump wrote:
>>> Except that it's obvious from your response that I misunderstood your
>>> patch, and thought that you were trying to make the route to an
>>> otherwise unreachable network a part of the unreachable network's config
>>> :-) (my defense is that the dual usage of the <ip> element to define a
>>> route confused me)
>> You were correct to be confused.  At first, I thought your suggestions
>> for <route> were just cosmetic but then I realized that, in general,
>> an <ip> definition resulted in a specific ".1" or ":1" device address
>> would be assigned to an interface (bridge).  The net address looked
>> similar but there would be no device address assigned to the
>> interface/bridge but there would be an entry for a (static) route.
>>
>> While the backend will continue to be more or less the same and
>> instantiate the static route, the "front" end will add a new element:
>> <route>.  I intend to keep "via" for specifying the gateway rather
>> than using "gateway.".  This makes it consistent with the ip-route
>> command.  So, to add a static would, the text would look like:
>>          <route address='<IPv4-network-addr>'  prefix='24'
>> via='<IPv4-gateway-addr>' />
>> or
>>          <route family='ipv6' address='<IPv6-net-addr>' prefix='64'
>> via='<IPv6-gateway-addr>'  />
>>
>> More work:  I will need to go back and "fix" the virt-manager code.
>>> Based on my now corrected understanding that the route is added to the
>>> config of the network which is directly connected to the gateway (rather
>>> than the network *beyond* the gateway), I have two comments/requests:
>>>
>>> 1) I think a separate <route> element is a better idea than trying to
>>> make <ip> dual purpose. Aside from confusing simple-minded people like
>>> me, when things are intertwined like that it has the potential to lead
>>> to an ambiguous situation further down the road. Also, using a separate
>>> <route> element is closer to the system config files as well as more
>>> similar to the xml used by the virInterface APIs (aka netcf).
>> Right on ... see above.
>>> 2) Although /sbin/ip uses the term "via", I do think that "gateway"
>>> would be the preferred term, since that's been in use for many years
>>> with the (admittedly now deprecated) /sbin/route command, as well as
>>> what is used in the system ifcfg-* and route-* files.
>> OK, how about having it both ways.  If we can have both mask and
>> prefix, why not both via and gateway.
>
> Having both mask and prefix was kind of forced by circumstance - when
> networks were first created, and there was only support for IPv4, the
> people who came up with the XML chose to use netmask; when I later added
> IPv6 support, netmask was inappropriate - nobody uses a netmask with
> IPv6, they always use prefix. Since prefix was now present, I made it
> also recognized for IPv4, but 1) you can only have one or the other, 2)
> whichever one you supply is what you get back with dumpxml. That's a
> different situation from simultaneously adding two attributes that have
> exactly the same purpose and same data type.
Picture an IPv6 mask.  Now picture having to figure out just mean it 
means.  Ugly!
>
> BTW, another reason I prefer "gateway" over "via" is that the xml for
> virInterface (netcf) uses "gateway" for the same information in its
> <route> element:
>
>   <interface type="ethernet" name="eth0">
>     <start mode="onboot"/>
>     <protocol family="ipv4">
>       <ip address="192.168.21.5" prefix="24"/>
>       <route gateway="192.168.21.1"/>
>     </protocol>
>   </interface>
>   
>
>>    I know gateway has some history attached to it but the new /sbin/ip
>> uses via.
>
> But remember that the goal isn't necessarily to make the xml be similar
> to any particular backend, but to make it generic enough that the
> backend could be replaced by something else. In this case either term
> would work, but I think "gateway" is more widely used and generally
> understandable to someone who isn't familiar with /sbin/ip.
>
> (I would still prefer if at least one other person voiced an opinion
> though - I don't want to seem like a "patch bully" :-)
>
>
>> I am just trying to keep a line of text being as close to not
>> exceeding 80 characters as practical.
>
> That's eventually a losing battle :-)
>
>
>> Correct me if I am wrong but all of this is suppose to be free-form
>> and this should be valid:
>>
>>          <route ip='ipv6'  address='fd00:dead:beef:472::1' prefix='64'
>
> (I think you meant to say "family='ipv6'" here...)
>
>>                      gateway='fd00:dead:beef:10::2'  />
>>
>> Of course, when it gets written back out by code it will all be on a
>> "single" line.

OK, OK ... I give up.  It will be "gateway" rather than "via" in the 
patch I submit.

One reason I am giving up is that while I was creating the 
formatnetwork.html documentation update, I found that using "via" became 
a little confusing and that "gateway" made more sense.

I must say that I have been impressed with the libvirt development 
cycle.  Releases and updates come out often and they are substantial.

Gene