----- Original Message ----- > From: "Gilad Chaplik" <[email protected]> > To: "Moti Asayag" <[email protected]> > Cc: [email protected] > Sent: Sunday, April 13, 2014 4:19:32 PM > Subject: Re: [ovirt-devel] [Devel] QoS Aggregate > > ----- 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 > > ? > > > > 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.
After thinking about it a bit, Policy is a huge feature and should be discussed thoroughly, please ignore my last statement. > > 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 > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/devel > > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
