[virt-tools-list] [PATCH virt-manager 5/5] virtManager: show QoS information for a network

[Cole Robinson]

On 06/27/2014 04:23 AM, Giuseppe Scrivano wrote:
> Laine Stump <laine at laine.org> writes:
> 
>> On 06/27/2014 12:41 AM, Giuseppe Scrivano wrote:
>>> Cole Robinson <crobinso at redhat.com> writes:
>>>
>>>> On 06/25/2014 07:05 AM, Giuseppe Scrivano wrote:
>>>>> Add UI elements to display QoS settings in the network details.
>>>>>
>>>>> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1089117
>>>>>
>>>>> Signed-off-by: Giuseppe Scrivano <gscrivan at redhat.com>
>>>>> ---
>>>>>  ui/host.ui             | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  virtManager/host.py    | 19 +++++++++++
>>>>>  virtManager/network.py |  2 ++
>>>>>  3 files changed, 106 insertions(+)
>>>> Actually I think we can save some work and make this more generally useful by
>>>> not exposing this bit in the createnet wizard, but making it unconditionally
>>>> visible and editable in the network details page. Keeps the createnet wizard
>>>> focused on the essential bits, and allows tweaking bandwidth for existing
>>>> networks. Thoughts?
>>> I've tried to use virNetworkUpdate but I couldn't manage to change the
>>> QoS settings.  IIUC, the way to do it (as virsh does) is to redefine the
>>> network.  In this case, IMO, the original implementation would make more
>>> sense as we don't allow any update.  What do you think?
>>>
>>
>> virNetworkUpdate() doesn't have support for updating the <bandwidth>
>> section of a network. My memory doesn't go that far back, but I'm
>> guessing that <bandwidth> for networks didn't exist yet when
>> virNetworkUpdate() was implemented (as I put in the enum value even for
>> several sections that weren't implemented, and <bandwidth> doesn't have
>> an enum value). Later when <bandwidth> was implemented, either we forgot
>> to add it to virNetworkUpdate(), or decided that it was too difficult to
>> get a live change to bandwidth settings right.
> 
> Laine, thanks for the clarification.  Cole, I would prefer to keep the
> original UI in this case that seems clearer for the users since we
> cannot have a live update of the QoS settings.  Is it ok for you?
> 

I'd rather it work like we do for a domain: attempt the live update, but if it
doesn't succeed, show a message like 'this change will take effect when the
network is restarted'.

Even if it's not changeable for a running network, it's still useful to
provide UI for editing this for an existing network.

- Cole