On Sat, Jun 25, 2016 at 03:42:38PM +0200, Tomasz Flendrich wrote:
On 24 Jun 2016, at 13:25, Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:And what about the current bad behavior when you do this? virsh attach interface f24 --type network --source default --live virsh attach interface f24 --type network --source default --live --configThis can be separated into two different issues. If you do attach-interface, we generate an XML without address, so you should be able to do the above and have 2 more interfaces live, the second one would be identical to the only one added to config.What if we guaranteed that adding a device with both “—live —config” options at once would always generate the same address? It could even leave some holes (unassigned addresses) in one of {config, live}, but it doesn’t bother us, does it? It would make the ABI stable. If finding such address would be impossible, the user would be informed that he/she can try adding the device separately using two calls without ABI stability. This solution means that there are less surprises for the user. Is there any reason it can’t be done, apart from complicating the code?
That's what we were talking about and that's what we need to do =) There is no reason it can't be done.
Besides, how often do people run —live without —config? Perhaps we should figure out what the most common use case is, make it work flawlessly and have some undesired behavior in other cases as a compromise.
It's hard to guess. However when concentrating on the guarantee of ABI stability, it's pretty clear how it should behave from the user's POV. - when both live and config are used, the devices plugged there must be identical, i.e. anything generated must be the same, all addresses, etc. - when you can't plug identical devices to both config and live definitions, just error out. Of course the more descriptive error message there is, the better.
Have a nice day,
U2
Tomasz
Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list