[ovirt-devel] [Devel] QoS Aggregate

[Gilad Chaplik]

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: devel at ovirt.org
> Sent: Sunday, April 13, 2014 4:19:32 PM
> Subject: Re: [ovirt-devel] [Devel] QoS Aggregate
> 
> ----- 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.

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 at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> >
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel