Qos feature

[Livnat Peer]

On 05/27/2013 03:32 PM, Michael Pasternak wrote:
> 
> Hi Livnat,
> 
> On 05/27/2013 02:45 PM, Livnat Peer wrote:
>> On 05/27/2013 02:18 PM, Michael Pasternak wrote:
>>> Hi Ofri,
>>>
>>> On 05/23/2013 10:34 AM, Ofri Masad wrote:
>>>> Hi Michael,
>>>>
>>>> I've drafted the Network QoS feature page. www.ovirt.org/Features/Design/Network_QoS
>>>> I'll appreciate it if you could go over it and see if you have comments or anything else to add to the API section.
>>>>
>>>> Thanks,
>>>> Ofri
>>>>
>>>
>>> i have few questions/comments regarding api/general design:
>>>
>>> 1) incoming and outgoing traffic can be shaped independently, will we support
>>>    granularity of enabling|disabling qos on inbound vs.outbound traffic?,
>>>    then i'd suggest modelling QOS in api like this:
>>>
>>> <qos>
>>>   <inbound enabled="true|false">
>>>     <average>xxx</average>
>>>     <peak>yyy</peak>
>>>     <burst>zzz</burst>
>>>     <floor>qqq</floor>
>>>   </inbound>
>>>   <outbound enabled="true|false">
>>>     <average>xxx</average>
>>>     <peak>yyy</peak>
>>>     <burst>zzz</burst>
>>>   </outbound>
>>> </qos>
>>
>>
>> Note that the above requires to support a mode of inbound (or outbound)
>> values configured while not enabled, 
> 
> no it doesn't, all attributes can have NULLs when disabled.
> 

Why disable+null values is better than just omitting the
inbound/outbound elements?

I liked the disable/enable idea...

>> it also requires a change in the UI.
> 
> api & UI doesn't have to be the same, but i think suggested above makes sense
> for UI as well.
> 
of course, I agree, they don't have to be the same. In this case I think
it makes sense.

>> I see how the above suggestion can be useful to users.
> 
> it can be useful for us on a first place, cause it's easily extendible,
> i.e it much easier to extend expended type with new elements rather
> than inline adding attributes <outbound average='' peak='' burst='' ...../>
> and in addition we can easily add system element's (if not now then in future)
> such as <inbound enabled="true|false" policy='xxx' ...>
> 
>>
>>>
>>>
>>> 2) at design page, i didn't saw you mentioning permission model for the QOS,
>>>    who should be able seeing it/manipulating it (note, that in case of user
>>>    that should not be seeing it, in api you shouldn't even show the state of the
>>>    qos e.g active or not, maybe not even worth mentioning <qos> at all)
>>>
>>
>> That's a good point.
>> Also note that the above suggests different UI dialogs in the user
>> portal and the admin portal for adding vnic.
>>
>>
>>>
>>> 3) what about exposing policies?, like making admin being able to apply same policy
>>>    on a different devices, rather than doing it manually per device.
>>
>> I suggest to support having default configuration on the Network entity,
>> all Vnics connected to the network inherit the configuration from the
>> Network.
>> If qos is configured both on the network and on the VNIC the VNIC
>> configuration holds.
> 
> usually QoS providers avoid having defaults cause when QoS turned on by
> mistake it's simply applies these values silently, while if it has NULLs,
> you cannot turn it on by mistake (i.e forcing users to set rules preferred
> over default configurations)
> 

I think the idea wasn't clear enough, a more detailed explanation -

A user can configure the inbound/outbound values on the network entity.
This configuration would apply to all VNICs using this network.
That approach would help the administrator to configure, in a very
simple way, a policy that prevents one VM from taking too much of the
network bandwidth.



>>
>>>
>>>> Change the Virtual Machine > Network Interfaces to support QoS properties Example of an XML representation of a network interface
>>>>
>>>> <nic id="7a3cff5e-3cc4-47c2-8388-9adf16341f5e"  ref="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e">
>>>>      <link rel="statistics" href="/api/vms/082c794b-771f-452f-83c9-b2b5a19c0399/nics/7a3cff5e-3cc4-47c2-8388-9adf16341f5e/statistics"/>
>>>>      <name>nic1</name>
>>>>      <interface>virtio</interface>
>>>>      <mac address="00:1a:4a:16:84:07"/>
>>>>      <network id="00000000-0000-0000-0000-000000000009" href="/api/networks/00000000-0000-0000-0000-000000000009"/>
>>>>      <vm id="cdc0b102-fbfe-444a-b9cb-57d2af94f401" href="/api/vms/cdc0b102-fbfe-444a-b9cb-57d2af94f401"/>
>>>
>>> - 'bandwidth' is not clear enough in my view, i think we should just use 'qos'
>>>
>>>>      <bandwidth>
>>>
>>> - we should be having <enabled>true|false</enabled> element here/peer traffic-dist?
>>>
>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>      </bandwidth>
>>>> </nic>
>>>>
>>>>
>>>> An API user modifies a network interface with a PUT request
>>>>
>>>> <nic>
>>>>       <name>nic2</name>
>>>>      <network id="00000000-0000-0000-0000-000000000010"/>
>>>>      <type>e1000</type>
>>>>      <bandwidth>
>>>>        <inbound average='1000' peak='5000' floor='200' burst='1024'/>
>>>>        <outbound average='128' peak='256' burst='256'/>
>>>>      </bandwidth>
>>>> </nic>
>>>
>>>
>>
> 
>