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" <[email protected]> > To: "Gilad Chaplik" <[email protected]> > Cc: [email protected] > Sent: Sunday, April 13, 2014 3:59:39 PM > Subject: Re: [Devel] QoS Aggregate > > > > ----- Original Message ----- > > From: "Gilad Chaplik" <[email protected]> > > To: [email protected] > > 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
