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