On 07/26/2011 07:10 PM, Eric Blake wrote:
On 07/26/2011 08:50 AM, Laine Stump wrote:
I think it is a somewhat overkill to have 'autoport' be a setting
per-<listen> element. I can't imagine people want a fixed port
number on one IP addr, but a dynamic port number on another IP
addr. So we could just keep that on the top level element.
Although I agree with you for config purposes, it looks to me like the
real use of autoport is that in the live XML it allows differentiating
between ports that were manually specified and those that were
automatically allocated (really, that seems like its main purpose, since
simply not giving a port also implies autoport). If we have only a
single autoport attribute for all the listens, we'll have to put in
extra code that makes sure if they specify port for one listen, they do
it for all of them.
Is it that hard to add that additional validation?
Anything can be done, given enough time to think, code, and test all the
corner cases. I don't see where the gain is in this case, though. I see
autoport more as an attribute that's useful when examining live XML than
as something useful to set in the config. Having a separate autoport for
each port is then not overkill, but just natural. Trying to use a single
autoport to indicate whether all of a set of ports were generated
automatically or were manually configured is what's overkill - you're
going to a lot of trouble to enforce an unnatural restriction for no
practical gain.
Maybe the best thing is to only allow autoport in <listen> when (flags &
INACTIVE) is false (live XML). This would mean that, as far as config
was concerned, <listen> would *never* have any autoport in it (which
would be fine with me); it would however still be in the data structure,
and still output in live XML.
Regardless of that answer, and whether this requires a v4, I'll go
ahead and review v3 code as if we decide that autoport-per-<listen> is
acceptable.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list