[libvirt] Entering freeze for libvirt-1.3.4

[Laine Stump]

On 04/27/2016 07:15 AM, Roman Bogorodskiy wrote:
>    Andrea Bolognani wrote:
>
>> On Wed, 2016-04-27 at 10:52 +0800, Daniel Veillard wrote:
>>>   
>>> [...] someone should look at a potential FreeBSD portability issue
>>> based on the report (or that could be that the Jenkins test need
>>> a bit of attention)
>> I believe the libvirt-freebsd Jenkins job has been phased out
>> in favor of adding the FreeBSD build slave to the same
>> libvirt-daemon-build job used for Linux builds.
>>
>> The downstream libvirt-daemon-syntax-check and
>> libvirt-daemon-check don't seem to have been updated to
>> reflect this change yet, nor have the libvirt-freebsd and
>> libvirt-freebsd-daemon-check jobs been removed.
>>
>> CCing Suren and Roman so they can give their take on the matter,
>> but I'm fairly confident FreeBSD is doing just fine :)
> Yeah, I'm not having any issues on FreeBSD so far, so I assume these
> issues are related to Jenkins configuration.
>
> However, there's at least one thing that's currently broken: the new
> peer address feature, when running with ifconfig, uses Linux specific
> syntax and in terms of peer address FreeBSD's ifconfig behaves
> differently. I haven't started working on the fix so far. :(

It is broken in other ways as well. I have a few patches for it that I 
need to send. (For your problem, since the bhve driver doesn't support 
setting the peer, I guess for now you could just log an error if peer 
was set.)

But beyond that I think that "peer" may not be the best name for the new 
attribute. The way it was added, the new attribute would indeed be 
placed in the "peer" field of the netlink request for setting the IP 
address, but in the case of qemu this was only because address and peer 
were mixed up (see my mail about it from yesterday:

https://www.redhat.com/archives/libvir-list/2016-April/msg01663.html

That this mixup was able to get into the code implies that the name 
"peer" is uninformative at best, and could be confusing ("peer" from 
who's point of view?). I suggested that it be named "host" or 
"hostAddress", but haven't gotten any upvotes so far. Can anyone come up 
with a better name? (Basically if you have <ip address='A' peer='B'/>, 
then "A" is the IP address of the guest, and "B" is the IP address of 
the host-end of that interface; for lxc veth interfaces, it does end up 
that "address" is put in the address field and "peer" in the peer field, 
but for qemu it's exactly the opposite.) If we are going to change it, 
it must be now before the first release containing the new 
functionality. (I suppose as long as it was *heavily* documented that 
the "peer" was from the point of view of the guest, that name would be 
okay; something more self-documenting would lead to less confusion though).