[ovirt-devel] [Devel] QoS Aggregate

[Gilad Chaplik]

FYI, Did some change in the design.
The main diff is NOT using sparse matrix for profiles, each profile will have its own table.

Thanks, 
Gilad.

----- 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 ?
> 
> 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.
> 
> Currently there is a top level collection named vnicprofiles, a specific
> collection
> for vm network interfaces profiles. Any thoughts about this as well ?
> 
> How will the search mechanism act with the suggested proposal ?
> 
> > Thanks,
> > Gilad.
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>