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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]