On 05/27/2013 07:13 PM, Doron Fediuck wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" <[email protected]> >> To: "Livnat Peer" <[email protected]> >> Cc: "Ofri Masad" <[email protected]>, [email protected] >> 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.
I assume setting QoS is done per vnic, I see above you wrote network. Can you describe how setting a policy per vnic would look like in your mind? > >>> 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. A user can add a VNIC to his VM if he has permission to use the network, I'm not sure it make sense that he can also configure his own QoS. I agree with Michael that configuring the QoS might not be relevant to the user API/user Portal. I would say that we should add a new permission on the network entity for a user to configure QoS on that network. > >>> >>>> >>>> 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 >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/arch >> > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
