Qos feature

Mon May 27 16:13:39 UTC 2013

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org
> Sent: Monday, May 27, 2013 3:32:37 PM
> Subject: Re: Qos feature
> 
> 
> 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.
> 

I'm ok with wither.
Just note that the hierarchy is deeper, and the design will be updated.
Basically we have:
Policy
  -> QoS
    -> Network
       -> In
       -> Out

The reason for it is that going forward Policy will include CPU QoS, memory
QoS, Storage QoS and Quota.
Most humans will want to kill us if they need to fill in all of it every
time. So policies is something which we can manage and people can actually
use. If someone needs something specific he can clone a policy and make the
relevant changes.
In this context what we need is for a network to reference a policy. The
vNIC will get the policy reference by default, and can override it by
specifying a different policy.

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

The assumption is that users with permissions to modify a vNIC can
get/set the information in REST.

> > 
> >>
> >> 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)
> 
See my response above on policies.
As for setting it, well, we prefer to start with a baseline which can be later
changed. This is better than starting in 'unlimited' mode we currently have.
In this way potential bursts are still in control and if more resources needed
than a matching policy should be assigned.

> > 
> >>
> >>> 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
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 