[ovirt-devel] [Devel] QoS Aggregate

[Gilad Chaplik]

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: devel at ovirt.org
> Sent: Sunday, April 13, 2014 3:59:39 PM
> Subject: Re: [Devel] QoS Aggregate
> 
> 
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: devel at ovirt.org
> > Sent: Monday, April 7, 2014 6:59:07 PM
> > Subject: [Devel] QoS Aggregate
> > 
> > Hi list,
> > 
> > While oVirt is rapidly continues to grow and gather features, it’s
> > important
> > to wrap already existing features with new ones, for better UX reasons.
> > In oVirt 3.5, there are going to be 2 new QoS objects, CPU limits and blkio
> > limits, added to the existing one network QoS (since 3.3).
> > 
> > You are more than welcome to review my proposal to aggregate all features
> > under the same umbrella:
> > 
> > http://www.ovirt.org/Features/aggregate_QoS
> > 
> 
> Generally, I'm okay with the proposed design, however since we're using any
> ORM framework to mitigate the data retrieval, could you provide the required
> DB changes in details ? Meaning, how would you implement the DB inheritance ?
> 

Both net_QoS and net_profiles tables will be renamed and a type field will be added; current db network flows will be renamed as well, for all 'ByType' ref will be added. i.e. you can't query (fetching or CRUD) a QoS/profile without specifying type in parameters.

> In addition, could you add the expected can-do-actions for example, prevent
> using a
> specific QoS type when is not in the right scope, or block updating the QoS
> type.

All QoS and Profile objects will inherit IQoS and IProfile interfaces respectively; both ifaces will contain a 'validate()' and a 'toString()' methods.
validate will be used both in client and server sides, toString will be used in aggregating QoS objects in UI ("getQoSWithoutType" is the only place type won't be used in the process, REST is kinda unique since there is no type notion at least in QoS (DC level); profiles type will be derived from context).

> 
> Currently there is a top level collection named vnicprofiles, a specific
> collection
> for vm network interfaces profiles. Any thoughts about this as well ?

Should remain intact till we're allow to break it, I guess.

> 
> How will the search mechanism act with the suggested proposal ?

No search mechanism for vnicprofiles, is there a bug? anyway, that's good :) in new design network profiles will be removed as a main tab (no search is needed + no regression= I'm happy); for top level rest collection, I'm not sure search is required...

I know sparse matrix isn't the best approach, at least for profiles, but I believe we can reuse already existing flows (which were tested), with minor alterations and risk. also I believe that one day profiles (aka SLA policy) will be a main entity in the system and all profiles' parameters will be aggregated to a single policy object, to help administrators with simple use cases; GOLD policy = GOLD QoS = all params have max values.

Hope I've provided satisfying answers to your questions, I will update the wiki page accordingly.

Thanks Moti!

Thanks, 
Gilad.

> 
> > Thanks,
> > Gilad.
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>