6:59 p.m.
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
Thanks,
Gilad.
3:59 p.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
To: devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
4:19 p.m.
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: "Gilad Chaplik" <gchaplik(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Sunday, April 13, 2014 3:59:39 PM
Subject: Re: [Devel] QoS Aggregate
----- Original Message -----
> From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> To: devel(a)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.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
4:47 p.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Sunday, April 13, 2014 4:19:32 PM
Subject: Re: [ovirt-devel] [Devel] QoS Aggregate
----- Original Message -----
> From: "Moti Asayag" <masayag(a)redhat.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: devel(a)ovirt.org
> Sent: Sunday, April 13, 2014 3:59:39 PM
> Subject: Re: [Devel] QoS Aggregate
>
>
>
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> > To: devel(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:46 p.m.
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(a)redhat.com>
To: "Gilad Chaplik" <gchaplik(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Sunday, April 13, 2014 3:59:39 PM
Subject: Re: [Devel] QoS Aggregate
----- Original Message -----
> From: "Gilad Chaplik" <gchaplik(a)redhat.com>
> To: devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
3860
days inactive
3882
days old
4 comments
2 participants
participants (2)
-
Gilad Chaplik -
Moti Asayag