----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: devel@ovirt.org Sent: Sunday, April 13, 2014 4:19:32 PM Subject: Re: [ovirt-devel] [Devel] QoS Aggregate
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: devel@ovirt.org Sent: Sunday, April 13, 2014 3:59:39 PM Subject: Re: [Devel] QoS Aggregate
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: devel@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:
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 Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel