Qos feature

[Michael Pasternak]

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.

> 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.

> 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)

> 
>>
>>> 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>
>>
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D