On 03/04/2012 11:42 PM, Ayal Baron wrote:
----- Original Message -----
On 03/04/2012 03:22 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Moti Asayag"<[email protected]>
To: [email protected]
Sent: Sunday, March 4, 2012 12:20:43 PM
Subject: Re: [Engine-devel] Introducing virt / gluster flags at
cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster /
Virtualization
capabilities, we plan to introduce two boolean columns -
virt_service
and gluster_service in the vds_groups table. As per immediate
plans, it
is intended to support only one service per cluster, meaning
only
one of
these two values can be true.
Couldn't there be additional future services in the future ? In
that
case perhaps worth considering enum for services, to be stored in
a
single service column, its values are: virt, gluster,...) instead
of
extending the vds_group table consistently when introducing new
services
(under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of
that
already and eventually we see long records and
routine refactoring to our DAL.
Also to make mixed configuration we can embrace bit fields which
interacts very nice with Enums e.g a 5 value of is a cluster with
VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't
like enums. What if we need to support finer grained services?
e.g. different topologies (active/passive, active/active etc) or
other types of intricate relationships?
Not to mention that looking at the raw data you don't undetstand
what it means without holding a dictionary. And it's annoying to
support BC of the numbers once things change.
enums are an issue, since we want to share them.
i agree services table seems the right approach, but actually,
booleans
are used here exactly because it seems services is the right long
term
approach, but we there is a lot of ground to cover before we know how
they would look like.
so boolean flags for the first few services, learning from these,
designing the bigger service models, and upgrading to it from the
cluster-with-flags seems (to me) the right path to take.
db scheme should be something that doesn't change every major, minor and
z-stream version. It means we're doing something wrong.
Having a 'gluster service' boolean column means that by definition we will be
changing the db scheme for the next service we want to add or even for the same
service but when we'll need some more info.
To start with, we can just rely on the hosts themselves reporting capabilities
and we can cache this info if we want it to display quickly next time we load.
This would be similar to supported cpu types.
If we have limitations on combining services then the first service utilized
wins.
we can't rely on hosts providing this info, as we want to provision
them, and need to know what to provision them with / monitor for.
i don't see the db scheme not changing between versions (not even sure
we defined a concept of major or minor versions, we just said we'll have
a version every 6 months).
as for backports of bug fixes to released versions, that's the only
thing we managed to avoid in the past (i.e., so far, we didn't change db
scheme when backporting patches, since dealing with upgrade is a
nightmare in that case - but that doesn't mean distributions of ovirt
will not stabilize on a version which is a mix of an upstream version
and a few more patches/features, which may include a db change, and will
have to maintain the upgrade from that.
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
