----- Original Message ----- > From: "Michael Pasternak" <[email protected]> > To: "Livnat Peer" <[email protected]> > Cc: "Ofri Masad" <[email protected]>, [email protected] > Sent: Tuesday, May 28, 2013 10:49:40 AM > Subject: Re: Qos feature > > On 05/27/2013 07:55 PM, Livnat Peer wrote: > > 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? > > basically this design serves my proposal mentioned below, > so administration can clearly see that no defaults exist, > and they have to choose policy explicitly. > > but i agree "omitting" is a good way to go as well > (we actively using it across the api) > > > > > I liked the disable/enable idea... > > this is exactly the same idea, just a bit visualized. > > > > >>> 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. > > i understand, but this is different use-case, i was thinking about > private policies (i'm sure there are plenty use-cases for it), this > way we can help by providing policy management, like: > > /api/slapolicies > > <slapolicy id=xxx href=/api/slapolicies> > <name>backup_qos_policy</name> > <type>network</type> > <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> > </slapolicy> > > <slapolicy id=xxx href=/api/slapolicies> > <name>user_cpu_policy</name> > <type>cpu</type> > ... > </slapolicy> > > <slapolicy id=xxx href=/api/slapolicies> > <name>user_memory_policy</name> > <type>memory</type> > ... > </slapolicy> > > ... >
Michael, This makes a lot of sense, but in a given context. For example, each cluster will have its own defaults, and policy implementations. Since this is still in a thinking process I'd like to wait with this important discussion until we have some time to come up with a more complete policies design. In the meantime we may want to continue with network QoS without the REST implementation to prevent a lock before we can ensure it works well with the whole SLA design. > > > > > > > >>> > >>>> > >>>>> 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
