4:42 a.m.
------=_Part_165720_1428728257.1368351734157
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi All,
I would like to have your opinions on which inheritance type to use in the DB.
We are adding an "external provider" entity to the system which will be able to
provide various resources (networks, hosts, etc).
These providers will be distinguishable by "type".
The basic definition of a provider contains:
* name
* description
* url
* type
Some providers might need additional properties such as:
* user
* password
In Java this is easily represented by inheritance.
In the DB however, there are 3 approaches that we can take:
1. No inheritance. This means that each type will wit in his own table, with no
relation or re-use.
2. Single table inheritance. All types sit in a single table, and each has his
corresponding columns.
3. Multiple table inheritance. Each type sists in his own table, where the PK is FK
for the most basic table (providers).
Pros for each approach:
1. None that I can think of.
2. No joins: Better performance Easier for developer to see the DB info Facilitate
column reuse
3. Constraints can be set on each column
Cons for each approach:
1. No reuse of DB entities + no compliance for column types Most cumbersome to query
all providers
2. Can't put some constraints on non-base columns (esp. not null)
3. Joins are needed - opposite of the pros of 2.
From personal experience, I find #2 to be better and easier to work
with & maintain.
What are your thoughts?
Regards,
Mike
------=_Part_165720_1428728257.1368351734157
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color: #000000"><div>Hi
All,<br></div><div><br></div>=
<div>I would like to have your opinions on which inheritance type to use in=
the DB.<br></div><div>We are adding an "external provider"
entity to the s=
ystem which will be able to provide various resources (networks, hosts, etc=
).<br></div><div><br></div><div>These providers will
be distinguishable by =
"type".<br></div><div>The basic definition of a provider
contains:</div><di=
v><ul><li>
name</li><li>description</li><li>url</li><li>type</li></ul><div>=
Some providers might need additional properties such
as:<br></div><div><ul>=
<li>user<br></li><li>password<br></li></ul><div>In
Java this is easily repr=
esented by
inheritance.<br></div><div><br></div><div>In the DB
however, the=
re are 3 approaches that we can
take:<br></div><div><ol><li>No inheritance.=
<br>This means that each type will wit in his own table, with no relation o=
r re-use.<br></li><li>Single table inheritance.<br>All types sit
in a singl=
e table, and each has his corresponding columns.<br></li><li>Multiple
table=
inheritance.<br>Each type sists in his own table, where the PK is FK for t=
he most basic table
(providers).<br></li></ol><div><br></div><div>Pros
for =
each approach:<br></div><div><ol><li>None that I can think
of.<br></li><li>=
No joins:<br> Better
performance<br> &nbs=
p; Easier for developer to see the DB
info<br> =
Facilitate column reuse<br></li><li>Constraints can be set on each
column<b=
r></li></ol></div></div></div></div><div>Cons
for each approach:<br></div><=
div><ol><li>No reuse of DB entities + no compliance for column
types<br>Mos=
t cumbersome to query all providers<br></li><li>Can't put some
constraints =
on non-base columns (esp. not null)<br></li><li>Joins are needed -
opposite=
of the pros of 2.<br></li></ol><div>From personal experience, I
find #2 to=
be better and easier to work with &
maintain.<br></div><div><br></div>=
<div>What are your
thoughts?<br></div></div><div><br></div><div><span
name=
=3D"x"></span>Regards,<br>Mike<span
name=3D"x"></span><br></div><div><br></=
div></div></body></html>
------=_Part_165720_1428728257.1368351734157--
4:53 a.m.
------=_Part_119211_1477841530.1368352381010
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, May 12, 2013 12:42:14 PM
Subject: [Engine-devel] What type of DB inheritance to use?
Hi All,
I would like to have your opinions on which inheritance type to use
in the
DB.
We are adding an "external provider" entity to the system which will be able
to provide various resources (networks, hosts, etc).
These providers will be distinguishable by "type".
The basic definition of a provider contains:
* name
* description
* url
* type
Some providers might need additional properties such as:
* user
* password
In Java this is easily represented by inheritance.
In the DB however, there are 3 approaches that we can take:
1. No inheritance. This means that each type will wit in his own
table, with
no relation or re-use.
2. Single table inheritance. All types sit in a single table, and each has
his corresponding columns.
You forgot to mention discriminator column at option 2 (how are you going to differ
between sub types) which should be indexed.
1.
2. Multiple table inheritance. Each type sists in his own table, where the PK
is FK for the most basic table (providers).
Pros for each approach:
1. None that I can think of.
2. No joins: Better performance Easier for developer to see the DB info
Facilitate column reuse
3. Constraints can be set on each column
Cons for each approach:
1. No reuse of DB entities + no compliance for column types Most
cumbersome
to query all providers
2. Can't put some constraints on non-base columns (esp. not null)
3. Joins are needed - opposite of the pros of 2
1.
From personal experience, I find #2 to be better and easier to work
with &
maintain.
I think it really depends on the use-case, but I also had better experience with 2.
What are your thoughts?
Regards,
Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
------=_Part_119211_1477841530.1368352381010
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color:
#000000"><br><div><br></div><hr
id=3D"zwchr"><=
blockquote style=3D"border-left:2px solid #1010FF;margin-left:5px;padding-l=
eft:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:non=
e;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Mik=
e Kolesnik" &lt;mkolesni(a)redhat.com&gt;<br><b>To:
</b>"engine-devel" <en=
gine-devel(a)ovirt.org&gt;<br><b>Sent: </b>Sunday, May 12, 2013
12:42:14 PM<b=
r><b>Subject: </b>[Engine-devel] What type of DB inheritance to
use?<br><di=
v><br></div><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color: #000000"><div>Hi
All,<br></div><div><br></div>=
<div>I would like to have your opinions on which inheritance type to use in=
the DB.<br></div><div>We are adding an "external provider"
entity to the s=
ystem which will be able to provide various resources (networks, hosts, etc=
).<br></div><div><br></div><div>These providers will
be distinguishable by =
"type".<br></div><div>The basic definition of a provider
contains:</div><di=
v><ul><li>
name</li><li>description</li><li>url</li><li>type</li></ul><div>=
Some providers might need additional properties such
as:<br></div><div><ul>=
<li>user<br></li><li>password<br></li></ul><div>In
Java this is easily repr=
esented by
inheritance.<br></div><div><br></div><div>In the DB
however, the=
re are 3 approaches that we can
take:<br></div><div><ol><li>No inheritance.=
<br>This means that each type will wit in his own table, with no relation o=
r re-use.<br></li><li>Single table inheritance.<br>All types sit
in a singl=
e table, and each has his corresponding
columns.</li></ol></div></div></div=
</div></blockquote><div>You forgot to mention
discriminator column a=
t option 2 (how are you going to differ between
sub types) which should be =
indexed.</div><blockquote style=3D"border-left:2px solid
#1010FF;margin-lef=
t:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text=
-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><d=
iv style=3D"font-family: times new roman, new york, times, serif; font-size=
: 12pt; color:
#000000"><div><div><div><ol><li><br></li><li>Multiple
table =
inheritance.<br>Each type sists in his own table, where the PK is FK for th=
e most basic table
(providers).<br></li></ol><div><br></div><div>Pros
for e=
ach approach:<br></div><div><ol><li>None that I can think
of.<br></li><li>N=
o joins:<br> Better
performance<br>  =
; Easier for developer to see the DB
info<br> F=
acilitate column reuse<br></li><li>Constraints can be set on each
column<br=
</li></ol></div></div></div></div><div>Cons
for each approach:<br></div><d=
iv><ol><li>No reuse of
DB entities + no compliance for column types<br>Most=
cumbersome to query all providers<br></li><li>Can't put some
constraints o=
n non-base columns (esp. not null)<br></li><li>Joins are needed -
opposite =
of the pros of
2</li></ol></div></div></blockquote><blockquote
style=3D"bor=
der-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font=
-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica=
,Arial,sans-serif;font-size:12pt;"><div style=3D"font-family: times new
rom=
an, new york, times, serif; font-size: 12pt; color:
#000000"><div><ol><li><=
br></li></ol><div>From personal experience, I find #2 to be better
and easi=
er to work with &
maintain.</div></div></div></blockquote><div>I think =
it really depends on the use-case, but I also had better experience with 2.=
</div><blockquote style=3D"border-left:2px solid
#1010FF;margin-left:5px;pa=
dding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decorat=
ion:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div style=
=3D"font-family: times new roman, new york, times, serif; font-size: 12pt; =
color:
#000000"><div><div><br></div><div><br></div><div>What
are your thoug=
hts?<br></div></div><div><br></div><div>Regards,<br>Mike<br></div><div><br>=
</div></div><br>_______________________________________________<br>Engine-d=
evel mailing list<br>Engine-devel@ovirt.org<br>http://lists.ovirt.org/mailm=
an/listinfo/engine-devel<br></blockquote><br></div></body></html>
------=_Part_119211_1477841530.1368352381010--
5:19 a.m.
Hi
From my experience, single table inheritance quickly grows into
something
unmanagable, as more and more (child related) fields are added, each line
has a few relevant attributes, and a long list of NULL values.
I would go with option 3. With materialized views, the costs of joins can
be eliminated.
On Sun, May 12, 2013 at 12:53 PM, Yair Zaslavsky <yzaslavs(a)redhat.com>wrote:
------------------------------
*From: *"Mike Kolesnik" <mkolesni(a)redhat.com>
*To: *"engine-devel" <engine-devel(a)ovirt.org>
*Sent: *Sunday, May 12, 2013 12:42:14 PM
*Subject: *[Engine-devel] What type of DB inheritance to use?
Hi All,
I would like to have your opinions on which inheritance type to use in the
DB.
We are adding an "external provider" entity to the system which will be
able to provide various resources (networks, hosts, etc).
These providers will be distinguishable by "type".
The basic definition of a provider contains:
- name
- description
- url
- type
Some providers might need additional properties such as:
- user
- password
In Java this is easily represented by inheritance.
In the DB however, there are 3 approaches that we can take:
1. No inheritance.
This means that each type will wit in his own table, with no relation
or re-use.
2. Single table inheritance.
All types sit in a single table, and each has his corresponding
columns.
You forgot to mention discriminator column at option 2 (how are you going
to differ between sub types) which should be indexed.
1.
2. Multiple table inheritance.
Each type sists in his own table, where the PK is FK for the most
basic table (providers).
Pros for each approach:
1. None that I can think of.
2. No joins:
Better performance
Easier for developer to see the DB info
Facilitate column reuse
3. Constraints can be set on each column
Cons for each approach:
1. No reuse of DB entities + no compliance for column types
Most cumbersome to query all providers
2. Can't put some constraints on non-base columns (esp. not null)
3. Joins are needed - opposite of the pros of 2
1.
From personal experience, I find #2 to be better and easier to work with &
maintain.
I think it really depends on the use-case, but I also had better
experience with 2.
What are your thoughts?
Regards,
Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:21 p.m.
----- Original Message -----
From: "Liran Zelkha" <liran.zelkha(a)gmail.com>
To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, May 12, 2013 1:19:07 PM
Subject: Re: [Engine-devel] What type of DB inheritance to use?
Hi
From my experience, single table inheritance quickly grows into something
unmanagable, as more and more (child related) fields are added, each line
has a few relevant attributes, and a long list of NULL values.
I would go with option 3. With materialized views, the costs of joins can be
eliminated.
+1
On Sun, May 12, 2013 at 12:53 PM, Yair Zaslavsky < yzaslavs(a)redhat.com >
wrote:
From: "Mike Kolesnik" < mkolesni(a)redhat.com >
To: "engine-devel" < engine-devel(a)ovirt.org >
Sent: Sunday, May 12, 2013 12:42:14 PM
Subject: [Engine-devel] What type of DB inheritance to use?
Hi All,
I would like to have your opinions on which inheritance type to use in the
DB.
We are adding an "external provider" entity to the system which will be able
to provide various resources (networks, hosts, etc).
These providers will be distinguishable by "type".
The basic definition of a provider contains:
* name
* description
* url
* type
Some providers might need additional properties such as:
* user
* password
In Java this is easily represented by inheritance.
In the DB however, there are 3 approaches that we can take:
1. No inheritance. This means that each type will wit in his own table,
with no relation or re-use.
2. Single table inheritance. All types sit in a single table, and each
has his corresponding columns.
You forgot to mention discriminator column at option 2 (how are you going to
differ between sub types) which should be indexed.
1.
2. Multiple table inheritance. Each type sists in his own table, where
the PK is FK for the most basic table (providers).
Pros for each approach:
1. None that I can think of.
2. No joins: Better performance Easier for developer to see the DB info
Facilitate column reuse
3. Constraints can be set on each column
Cons for each approach:
1. No reuse of DB entities + no compliance for column types Most
cumbersome to query all providers
2. Can't put some constraints on non-base columns (esp. not null)
3. Joins are needed - opposite of the pros of 2
1.
From personal experience, I find #2 to be better and easier to work with &
maintain.
I think it really depends on the use-case, but I also had better experience
with 2.
What are your thoughts?
Regards,
Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:13 a.m.
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: "Liran Zelkha" <liran.zelkha(a)gmail.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Tuesday, May 14, 2013 3:21:11 AM
Subject: Re: [Engine-devel] What type of DB inheritance to use?
----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Sunday, May 12, 2013 1:19:07 PM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
>
> Hi
>
> From my experience, single table inheritance quickly grows into something
> unmanagable, as more and more (child related) fields are added, each line
> has a few relevant attributes, and a long list of NULL values.
> I would go with option 3. With materialized views, the costs of joins can
> be
> eliminated.
+1
I'd prefer option 3 too.
--
Federico
9:35 a.m.
From my experience inheritance in the database is usually a bad idea
all together.
Fields like even if "user" and "password" fields
exist in more than one provider type
they shouldn't share a table as their indexes and type validation have no reason to
be
shared (even if they theoretically can)and it makes both suffer from forced
standardisation.
I don't know what a "provider" is in your world but in the classic sense you
should even
have all providers be part of the same object inheritance as you shouldn't have all
factories. A "Provider" is a function and not identity. In Java terms, and
interface and
not a base class.
----- Original Message -----
From: "Federico Simoncelli" <fsimonce(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Tuesday, May 14, 2013 3:13:30 AM
Subject: Re: [Engine-devel] What type of DB inheritance to use?
----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Tuesday, May 14, 2013 3:21:11 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
>
>
>
> ----- Original Message -----
> > From: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > Sent: Sunday, May 12, 2013 1:19:07 PM
> > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> >
> > Hi
> >
> > From my experience, single table inheritance quickly grows into something
> > unmanagable, as more and more (child related) fields are added, each line
> > has a few relevant attributes, and a long list of NULL values.
> > I would go with option 3. With materialized views, the costs of joins can
> > be
> > eliminated.
>
> +1
I'd prefer option 3 too.
--
Federico
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:40 a.m.
Sorry, very tired. I read what I wrote and thought I should rephrase.
From my experience inheritance in the database is usually a bad idea
all
together.
Even if "user" and "password" fields exist in more than one
provider type
they shouldn't share a table as their indexes and type validation have no
reason to be > shared (even if they theoretically can)and it makes both
suffer from forced standardisation.
I don't know what a "Provider" in relation to your specific problem
but in the classic sense you shouldn't even have all providers be part
of the same type hatchery as you shouldn't have all factories or adapters.
A "Provider" is a trait and not identity. In Java terms, an interface and
not a base class.
----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Eli Mesika" <emesika(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Tuesday, May 14, 2013 10:35:20 AM
Subject: Re: [Engine-devel] What type of DB inheritance to use?
From my experience inheritance in the database is usually a bad idea all
together.
Fields like even if "user" and "password" fields exist in more than
one
provider type
they shouldn't share a table as their indexes and type validation have no
reason to be
shared (even if they theoretically can)and it makes both suffer from forced
standardisation.
I don't know what a "provider" is in your world but in the classic sense
you
should even
have all providers be part of the same object inheritance as you shouldn't
have all
factories. A "Provider" is a function and not identity. In Java terms, and
interface and
not a base class.
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Eli Mesika" <emesika(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Tuesday, May 14, 2013 3:13:30 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
>
> ----- Original Message -----
> > From: "Eli Mesika" <emesika(a)redhat.com>
> > To: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:21:11 AM
> > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> >
> >
> >
> > ----- Original Message -----
> > > From: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> > > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > > Sent: Sunday, May 12, 2013 1:19:07 PM
> > > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > >
> > > Hi
> > >
> > > From my experience, single table inheritance quickly grows into
> > > something
> > > unmanagable, as more and more (child related) fields are added, each
> > > line
> > > has a few relevant attributes, and a long list of NULL values.
> > > I would go with option 3. With materialized views, the costs of joins
> > > can
> > > be
> > > eliminated.
> >
> > +1
>
> I'd prefer option 3 too.
>
> --
> Federico
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
7:14 a.m.
On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
Hi All,
I would like to have your opinions on which inheritance type to use in
the DB.
We are adding an "external provider" entity to the system which will be
able to provide various resources (networks, hosts, etc).
These providers will be distinguishable by "type".
The basic definition of a provider contains:
* name
* description
* url
* type
Some providers might need additional properties such as:
* user
* password
what type of provider won't require authentication?
In Java this is easily represented by inheritance.
In the DB however, there are 3 approaches that we can take:
1. No inheritance.
This means that each type will wit in his own table, with no
relation or re-use.
2. Single table inheritance.
All types sit in a single table, and each has his corresponding columns.
3. Multiple table inheritance.
Each type sists in his own table, where the PK is FK for the most
basic table (providers).
Pros for each approach:
1. None that I can think of.
2. No joins:
Better performance
Easier for developer to see the DB info
Facilitate column reuse
3. Constraints can be set on each column
Cons for each approach:
1. No reuse of DB entities + no compliance for column types
Most cumbersome to query all providers
2. Can't put some constraints on non-base columns (esp. not null)
3. Joins are needed - opposite of the pros of 2.
From personal experience, I find #2 to be better and easier to work
with & maintain.
What are your thoughts?
Regards,
Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:16 a.m.
----- Original Message -----
On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> Hi All,
>
> I would like to have your opinions on which inheritance type to use in
> the DB.
> We are adding an "external provider" entity to the system which will be
> able to provide various resources (networks, hosts, etc).
>
> These providers will be distinguishable by "type".
> The basic definition of a provider contains:
>
> * name
> * description
> * url
> * type
>
> Some providers might need additional properties such as:
>
> * user
> * password
what type of provider won't require authentication?
Quantum provider in the 1st implementation will not require these fields.
It will eventually require some sort of authentication, but not necessarily
these fields, or only these fields.
>
> In Java this is easily represented by inheritance.
>
> In the DB however, there are 3 approaches that we can take:
>
> 1. No inheritance.
> This means that each type will wit in his own table, with no
> relation or re-use.
> 2. Single table inheritance.
> All types sit in a single table, and each has his corresponding
> columns.
> 3. Multiple table inheritance.
> Each type sists in his own table, where the PK is FK for the most
> basic table (providers).
>
>
> Pros for each approach:
>
> 1. None that I can think of.
> 2. No joins:
> Better performance
> Easier for developer to see the DB info
> Facilitate column reuse
> 3. Constraints can be set on each column
>
> Cons for each approach:
>
> 1. No reuse of DB entities + no compliance for column types
> Most cumbersome to query all providers
> 2. Can't put some constraints on non-base columns (esp. not null)
> 3. Joins are needed - opposite of the pros of 2.
>
> From personal experience, I find #2 to be better and easier to work
> with & maintain.
>
> What are your thoughts?
>
> Regards,
> Mike
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
7:43 a.m.
On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
----- Original Message -----
> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>> Hi All,
>>
>> I would like to have your opinions on which inheritance type to use in
>> the DB.
>> We are adding an "external provider" entity to the system which will
be
>> able to provide various resources (networks, hosts, etc).
>>
>> These providers will be distinguishable by "type".
>> The basic definition of a provider contains:
>>
>> * name
>> * description
>> * url
>> * type
>>
>> Some providers might need additional properties such as:
>>
>> * user
>> * password
>
> what type of provider won't require authentication?
Quantum provider in the 1st implementation will not require these fields.
It will eventually require some sort of authentication, but not necessarily
these fields, or only these fields.
I'm not talking about a POC.
unless we pass through credentials of users for some actions, how do you
use a provider without user/password (or client cert, etc. - i.e., all
authentication methods are usually similar on the info you need to persist)?
>
>>
>> In Java this is easily represented by inheritance.
>>
>> In the DB however, there are 3 approaches that we can take:
>>
>> 1. No inheritance.
>> This means that each type will wit in his own table, with no
>> relation or re-use.
>> 2. Single table inheritance.
>> All types sit in a single table, and each has his corresponding
>> columns.
>> 3. Multiple table inheritance.
>> Each type sists in his own table, where the PK is FK for the most
>> basic table (providers).
>>
>>
>> Pros for each approach:
>>
>> 1. None that I can think of.
>> 2. No joins:
>> Better performance
>> Easier for developer to see the DB info
>> Facilitate column reuse
>> 3. Constraints can be set on each column
>>
>> Cons for each approach:
>>
>> 1. No reuse of DB entities + no compliance for column types
>> Most cumbersome to query all providers
>> 2. Can't put some constraints on non-base columns (esp. not null)
>> 3. Joins are needed - opposite of the pros of 2.
>>
>> From personal experience, I find #2 to be better and easier to work
>> with & maintain.
>>
>> What are your thoughts?
>>
>> Regards,
>> Mike
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>
8:31 a.m.
----- Original Message -----
On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>> Hi All,
>>>
>>> I would like to have your opinions on which inheritance type to use in
>>> the DB.
>>> We are adding an "external provider" entity to the system which
will be
>>> able to provide various resources (networks, hosts, etc).
>>>
>>> These providers will be distinguishable by "type".
>>> The basic definition of a provider contains:
>>>
>>> * name
>>> * description
>>> * url
>>> * type
>>>
>>> Some providers might need additional properties such as:
>>>
>>> * user
>>> * password
>>
>> what type of provider won't require authentication?
>
> Quantum provider in the 1st implementation will not require these fields.
> It will eventually require some sort of authentication, but not necessarily
> these fields, or only these fields.
I'm not talking about a POC.
unless we pass through credentials of users for some actions, how do you
use a provider without user/password (or client cert, etc. - i.e., all
authentication methods are usually similar on the info you need to persist)?
I did not say that we will use Quantum without auth, only that these fields may or
may not necessarily be in the Quantum provider entity.
I think this is regardless of the main discussion here of inheritance, which I
think will happen regardless of how Quantum provider is implemented. If you wish
to discuss these details I'll be happy do it on a new thread, so that this one
can stay focused on the subject of DB inheritance.
>
>>
>>>
>>> In Java this is easily represented by inheritance.
>>>
>>> In the DB however, there are 3 approaches that we can take:
>>>
>>> 1. No inheritance.
>>> This means that each type will wit in his own table, with no
>>> relation or re-use.
>>> 2. Single table inheritance.
>>> All types sit in a single table, and each has his corresponding
>>> columns.
>>> 3. Multiple table inheritance.
>>> Each type sists in his own table, where the PK is FK for the most
>>> basic table (providers).
>>>
>>>
>>> Pros for each approach:
>>>
>>> 1. None that I can think of.
>>> 2. No joins:
>>> Better performance
>>> Easier for developer to see the DB info
>>> Facilitate column reuse
>>> 3. Constraints can be set on each column
>>>
>>> Cons for each approach:
>>>
>>> 1. No reuse of DB entities + no compliance for column types
>>> Most cumbersome to query all providers
>>> 2. Can't put some constraints on non-base columns (esp. not null)
>>> 3. Joins are needed - opposite of the pros of 2.
>>>
>>> From personal experience, I find #2 to be better and easier to work
>>> with & maintain.
>>>
>>> What are your thoughts?
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
9:05 a.m.
On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
----- Original Message -----
> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>> ----- Original Message -----
>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>> Hi All,
>>>>
>>>> I would like to have your opinions on which inheritance type to use in
>>>> the DB.
>>>> We are adding an "external provider" entity to the system which
will be
>>>> able to provide various resources (networks, hosts, etc).
>>>>
>>>> These providers will be distinguishable by "type".
>>>> The basic definition of a provider contains:
>>>>
>>>> * name
>>>> * description
>>>> * url
>>>> * type
>>>>
>>>> Some providers might need additional properties such as:
>>>>
>>>> * user
>>>> * password
>>>
>>> what type of provider won't require authentication?
>>
>> Quantum provider in the 1st implementation will not require these fields.
>> It will eventually require some sort of authentication, but not necessarily
>> these fields, or only these fields.
>
> I'm not talking about a POC.
> unless we pass through credentials of users for some actions, how do you
> use a provider without user/password (or client cert, etc. - i.e., all
> authentication methods are usually similar on the info you need to persist)?
I did not say that we will use Quantum without auth, only that these fields may or
may not necessarily be in the Quantum provider entity.
I think this is regardless of the main discussion here of inheritance, which I
think will happen regardless of how Quantum provider is implemented. If you wish
to discuss these details I'll be happy do it on a new thread, so that this one
can stay focused on the subject of DB inheritance.
how many discrepancies do we expect between the various providers, to be
actually defined at provider level rather than consumption level?
>
>>
>>>
>>>>
>>>> In Java this is easily represented by inheritance.
>>>>
>>>> In the DB however, there are 3 approaches that we can take:
>>>>
>>>> 1. No inheritance.
>>>> This means that each type will wit in his own table, with no
>>>> relation or re-use.
>>>> 2. Single table inheritance.
>>>> All types sit in a single table, and each has his corresponding
>>>> columns.
>>>> 3. Multiple table inheritance.
>>>> Each type sists in his own table, where the PK is FK for the most
>>>> basic table (providers).
>>>>
>>>>
>>>> Pros for each approach:
>>>>
>>>> 1. None that I can think of.
>>>> 2. No joins:
>>>> Better performance
>>>> Easier for developer to see the DB info
>>>> Facilitate column reuse
>>>> 3. Constraints can be set on each column
>>>>
>>>> Cons for each approach:
>>>>
>>>> 1. No reuse of DB entities + no compliance for column types
>>>> Most cumbersome to query all providers
>>>> 2. Can't put some constraints on non-base columns (esp. not null)
>>>> 3. Joins are needed - opposite of the pros of 2.
>>>>
>>>> From personal experience, I find #2 to be better and easier to work
>>>> with & maintain.
>>>>
>>>> What are your thoughts?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>
>>>
>
>
12:33 a.m.
----- Original Message -----
On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>
> ----- Original Message -----
>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>> ----- Original Message -----
>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>> Hi All,
>>>>>
>>>>> I would like to have your opinions on which inheritance type to use
in
>>>>> the DB.
>>>>> We are adding an "external provider" entity to the system
which will be
>>>>> able to provide various resources (networks, hosts, etc).
>>>>>
>>>>> These providers will be distinguishable by "type".
>>>>> The basic definition of a provider contains:
>>>>>
>>>>> * name
>>>>> * description
>>>>> * url
>>>>> * type
>>>>>
>>>>> Some providers might need additional properties such as:
>>>>>
>>>>> * user
>>>>> * password
>>>>
>>>> what type of provider won't require authentication?
>>>
>>> Quantum provider in the 1st implementation will not require these fields.
>>> It will eventually require some sort of authentication, but not
>>> necessarily
>>> these fields, or only these fields.
>>
>> I'm not talking about a POC.
>> unless we pass through credentials of users for some actions, how do you
>> use a provider without user/password (or client cert, etc. - i.e., all
>> authentication methods are usually similar on the info you need to
>> persist)?
>
> I did not say that we will use Quantum without auth, only that these fields
> may or
> may not necessarily be in the Quantum provider entity.
>
> I think this is regardless of the main discussion here of inheritance,
> which I
> think will happen regardless of how Quantum provider is implemented. If you
> wish
> to discuss these details I'll be happy do it on a new thread, so that this
> one
> can stay focused on the subject of DB inheritance.
how many discrepancies do we expect between the various providers, to be
actually defined at provider level rather than consumption level?
I expect at least a few, there has to be some divergence.
For instance, if we model Glance as a provider then it may require a "tenant
name"
field which is not something Quantum provider requires.
Both these providers will be probably linked to a keystone entity, while a host
provider (such as Foreman) will not be since it doesn't work with keystone.
We can't expect all providers to be the same, some divergence is bound to occur.
>
>>
>>>
>>>>
>>>>>
>>>>> In Java this is easily represented by inheritance.
>>>>>
>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>
>>>>> 1. No inheritance.
>>>>> This means that each type will wit in his own table, with no
>>>>> relation or re-use.
>>>>> 2. Single table inheritance.
>>>>> All types sit in a single table, and each has his
corresponding
>>>>> columns.
>>>>> 3. Multiple table inheritance.
>>>>> Each type sists in his own table, where the PK is FK for the
most
>>>>> basic table (providers).
>>>>>
>>>>>
>>>>> Pros for each approach:
>>>>>
>>>>> 1. None that I can think of.
>>>>> 2. No joins:
>>>>> Better performance
>>>>> Easier for developer to see the DB info
>>>>> Facilitate column reuse
>>>>> 3. Constraints can be set on each column
>>>>>
>>>>> Cons for each approach:
>>>>>
>>>>> 1. No reuse of DB entities + no compliance for column types
>>>>> Most cumbersome to query all providers
>>>>> 2. Can't put some constraints on non-base columns (esp. not
null)
>>>>> 3. Joins are needed - opposite of the pros of 2.
>>>>>
>>>>> From personal experience, I find #2 to be better and easier to
work
>>>>> with & maintain.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>
>>>>
>>
>>
1:01 a.m.
On 05/13/2013 08:33 AM, Mike Kolesnik wrote:
----- Original Message -----
> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>>
>> ----- Original Message -----
>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>>> ----- Original Message -----
>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I would like to have your opinions on which inheritance type to
use in
>>>>>> the DB.
>>>>>> We are adding an "external provider" entity to the
system which will be
>>>>>> able to provide various resources (networks, hosts, etc).
>>>>>>
>>>>>> These providers will be distinguishable by "type".
>>>>>> The basic definition of a provider contains:
>>>>>>
>>>>>> * name
>>>>>> * description
>>>>>> * url
>>>>>> * type
>>>>>>
>>>>>> Some providers might need additional properties such as:
>>>>>>
>>>>>> * user
>>>>>> * password
>>>>>
>>>>> what type of provider won't require authentication?
>>>>
>>>> Quantum provider in the 1st implementation will not require these
fields.
>>>> It will eventually require some sort of authentication, but not
>>>> necessarily
>>>> these fields, or only these fields.
>>>
>>> I'm not talking about a POC.
>>> unless we pass through credentials of users for some actions, how do you
>>> use a provider without user/password (or client cert, etc. - i.e., all
>>> authentication methods are usually similar on the info you need to
>>> persist)?
>>
>> I did not say that we will use Quantum without auth, only that these fields
>> may or
>> may not necessarily be in the Quantum provider entity.
>>
>> I think this is regardless of the main discussion here of inheritance,
>> which I
>> think will happen regardless of how Quantum provider is implemented. If you
>> wish
>> to discuss these details I'll be happy do it on a new thread, so that this
>> one
>> can stay focused on the subject of DB inheritance.
>
> how many discrepancies do we expect between the various providers, to be
> actually defined at provider level rather than consumption level?
I expect at least a few, there has to be some divergence.
For instance, if we model Glance as a provider then it may require a "tenant
name"
field which is not something Quantum provider requires.
actually, since these are both openstack services, why would one need a
tenant name and the other wouldn't?
Both these providers will be probably linked to a keystone entity,
while a host
provider (such as Foreman) will not be since it doesn't work with keystone.
We can't expect all providers to be the same, some divergence is bound to occur.
true, but keystone is one of the few authentication aspects which are
going to be common to multiple providers, hence don't make sense to be
provider specific.
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> In Java this is easily represented by inheritance.
>>>>>>
>>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>>
>>>>>> 1. No inheritance.
>>>>>> This means that each type will wit in his own table, with
no
>>>>>> relation or re-use.
>>>>>> 2. Single table inheritance.
>>>>>> All types sit in a single table, and each has his
corresponding
>>>>>> columns.
>>>>>> 3. Multiple table inheritance.
>>>>>> Each type sists in his own table, where the PK is FK for
the most
>>>>>> basic table (providers).
>>>>>>
>>>>>>
>>>>>> Pros for each approach:
>>>>>>
>>>>>> 1. None that I can think of.
>>>>>> 2. No joins:
>>>>>> Better performance
>>>>>> Easier for developer to see the DB info
>>>>>> Facilitate column reuse
>>>>>> 3. Constraints can be set on each column
>>>>>>
>>>>>> Cons for each approach:
>>>>>>
>>>>>> 1. No reuse of DB entities + no compliance for column types
>>>>>> Most cumbersome to query all providers
>>>>>> 2. Can't put some constraints on non-base columns (esp.
not null)
>>>>>> 3. Joins are needed - opposite of the pros of 2.
>>>>>>
>>>>>> From personal experience, I find #2 to be better and easier
to work
>>>>>> with & maintain.
>>>>>>
>>>>>> What are your thoughts?
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
1:27 a.m.
----- Original Message -----
On 05/13/2013 08:33 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>>>
>>> ----- Original Message -----
>>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>>>> ----- Original Message -----
>>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I would like to have your opinions on which inheritance type
to use
>>>>>>> in
>>>>>>> the DB.
>>>>>>> We are adding an "external provider" entity to the
system which will
>>>>>>> be
>>>>>>> able to provide various resources (networks, hosts, etc).
>>>>>>>
>>>>>>> These providers will be distinguishable by
"type".
>>>>>>> The basic definition of a provider contains:
>>>>>>>
>>>>>>> * name
>>>>>>> * description
>>>>>>> * url
>>>>>>> * type
>>>>>>>
>>>>>>> Some providers might need additional properties such as:
>>>>>>>
>>>>>>> * user
>>>>>>> * password
>>>>>>
>>>>>> what type of provider won't require authentication?
>>>>>
>>>>> Quantum provider in the 1st implementation will not require these
>>>>> fields.
>>>>> It will eventually require some sort of authentication, but not
>>>>> necessarily
>>>>> these fields, or only these fields.
>>>>
>>>> I'm not talking about a POC.
>>>> unless we pass through credentials of users for some actions, how do
you
>>>> use a provider without user/password (or client cert, etc. - i.e., all
>>>> authentication methods are usually similar on the info you need to
>>>> persist)?
>>>
>>> I did not say that we will use Quantum without auth, only that these
>>> fields
>>> may or
>>> may not necessarily be in the Quantum provider entity.
>>>
>>> I think this is regardless of the main discussion here of inheritance,
>>> which I
>>> think will happen regardless of how Quantum provider is implemented. If
>>> you
>>> wish
>>> to discuss these details I'll be happy do it on a new thread, so that
>>> this
>>> one
>>> can stay focused on the subject of DB inheritance.
>>
>> how many discrepancies do we expect between the various providers, to be
>> actually defined at provider level rather than consumption level?
>
> I expect at least a few, there has to be some divergence.
>
> For instance, if we model Glance as a provider then it may require a
> "tenant name"
> field which is not something Quantum provider requires.
actually, since these are both openstack services, why would one need a
tenant name and the other wouldn't?
I don't know why this is the case since I'm not familiar with Glance, but
from what I heard this is one of the fields it needs.
Either way, we can't expect all OpenStack providers to be modelled the same
until we model them, and then we will know if they have the same fields or not.
> Both these providers will be probably linked to a keystone entity, while a
> host
> provider (such as Foreman) will not be since it doesn't work with keystone.
>
> We can't expect all providers to be the same, some divergence is bound to
> occur.
true, but keystone is one of the few authentication aspects which are
going to be common to multiple providers, hence don't make sense to be
provider specific.
It will be common for OpenStack based providers.
How about UCSM for instance, should we want to integrate it as a provider?
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> In Java this is easily represented by inheritance.
>>>>>>>
>>>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>>>
>>>>>>> 1. No inheritance.
>>>>>>> This means that each type will wit in his own table,
with no
>>>>>>> relation or re-use.
>>>>>>> 2. Single table inheritance.
>>>>>>> All types sit in a single table, and each has his
>>>>>>> corresponding
>>>>>>> columns.
>>>>>>> 3. Multiple table inheritance.
>>>>>>> Each type sists in his own table, where the PK is FK
for the
>>>>>>> most
>>>>>>> basic table (providers).
>>>>>>>
>>>>>>>
>>>>>>> Pros for each approach:
>>>>>>>
>>>>>>> 1. None that I can think of.
>>>>>>> 2. No joins:
>>>>>>> Better performance
>>>>>>> Easier for developer to see the DB info
>>>>>>> Facilitate column reuse
>>>>>>> 3. Constraints can be set on each column
>>>>>>>
>>>>>>> Cons for each approach:
>>>>>>>
>>>>>>> 1. No reuse of DB entities + no compliance for column
types
>>>>>>> Most cumbersome to query all providers
>>>>>>> 2. Can't put some constraints on non-base columns
(esp. not null)
>>>>>>> 3. Joins are needed - opposite of the pros of 2.
>>>>>>>
>>>>>>> From personal experience, I find #2 to be better and
easier to
>>>>>>> work
>>>>>>> with & maintain.
>>>>>>>
>>>>>>> What are your thoughts?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
1:29 a.m.
On 05/13/2013 09:27 AM, Mike Kolesnik wrote:
----- Original Message -----
> On 05/13/2013 08:33 AM, Mike Kolesnik wrote:
>> ----- Original Message -----
>>> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>>>>
>>>> ----- Original Message -----
>>>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>>>>> ----- Original Message -----
>>>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I would like to have your opinions on which inheritance
type to use
>>>>>>>> in
>>>>>>>> the DB.
>>>>>>>> We are adding an "external provider" entity to
the system which will
>>>>>>>> be
>>>>>>>> able to provide various resources (networks, hosts,
etc).
>>>>>>>>
>>>>>>>> These providers will be distinguishable by
"type".
>>>>>>>> The basic definition of a provider contains:
>>>>>>>>
>>>>>>>> * name
>>>>>>>> * description
>>>>>>>> * url
>>>>>>>> * type
>>>>>>>>
>>>>>>>> Some providers might need additional properties such as:
>>>>>>>>
>>>>>>>> * user
>>>>>>>> * password
>>>>>>>
>>>>>>> what type of provider won't require authentication?
>>>>>>
>>>>>> Quantum provider in the 1st implementation will not require
these
>>>>>> fields.
>>>>>> It will eventually require some sort of authentication, but not
>>>>>> necessarily
>>>>>> these fields, or only these fields.
>>>>>
>>>>> I'm not talking about a POC.
>>>>> unless we pass through credentials of users for some actions, how do
you
>>>>> use a provider without user/password (or client cert, etc. - i.e.,
all
>>>>> authentication methods are usually similar on the info you need to
>>>>> persist)?
>>>>
>>>> I did not say that we will use Quantum without auth, only that these
>>>> fields
>>>> may or
>>>> may not necessarily be in the Quantum provider entity.
>>>>
>>>> I think this is regardless of the main discussion here of inheritance,
>>>> which I
>>>> think will happen regardless of how Quantum provider is implemented. If
>>>> you
>>>> wish
>>>> to discuss these details I'll be happy do it on a new thread, so
that
>>>> this
>>>> one
>>>> can stay focused on the subject of DB inheritance.
>>>
>>> how many discrepancies do we expect between the various providers, to be
>>> actually defined at provider level rather than consumption level?
>>
>> I expect at least a few, there has to be some divergence.
>>
>> For instance, if we model Glance as a provider then it may require a
>> "tenant name"
>> field which is not something Quantum provider requires.
>
> actually, since these are both openstack services, why would one need a
> tenant name and the other wouldn't?
I don't know why this is the case since I'm not familiar with Glance, but
from what I heard this is one of the fields it needs.
Either way, we can't expect all OpenStack providers to be modelled the same
until we model them, and then we will know if they have the same fields or not.
>
>> Both these providers will be probably linked to a keystone entity, while a
>> host
>> provider (such as Foreman) will not be since it doesn't work with keystone.
>>
>> We can't expect all providers to be the same, some divergence is bound to
>> occur.
>
> true, but keystone is one of the few authentication aspects which are
> going to be common to multiple providers, hence don't make sense to be
> provider specific.
It will be common for OpenStack based providers.
How about UCSM for instance, should we want to integrate it as a provider?
i'm sure it will require user/password as well.
if we model authentication of providers outside of the providers table,
it should be a general credentials solution for the various types of
authentication, not provider specific.
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> In Java this is easily represented by inheritance.
>>>>>>>>
>>>>>>>> In the DB however, there are 3 approaches that we can
take:
>>>>>>>>
>>>>>>>> 1. No inheritance.
>>>>>>>> This means that each type will wit in his own
table, with no
>>>>>>>> relation or re-use.
>>>>>>>> 2. Single table inheritance.
>>>>>>>> All types sit in a single table, and each has
his
>>>>>>>> corresponding
>>>>>>>> columns.
>>>>>>>> 3. Multiple table inheritance.
>>>>>>>> Each type sists in his own table, where the PK is
FK for the
>>>>>>>> most
>>>>>>>> basic table (providers).
>>>>>>>>
>>>>>>>>
>>>>>>>> Pros for each approach:
>>>>>>>>
>>>>>>>> 1. None that I can think of.
>>>>>>>> 2. No joins:
>>>>>>>> Better performance
>>>>>>>> Easier for developer to see the DB info
>>>>>>>> Facilitate column reuse
>>>>>>>> 3. Constraints can be set on each column
>>>>>>>>
>>>>>>>> Cons for each approach:
>>>>>>>>
>>>>>>>> 1. No reuse of DB entities + no compliance for
column types
>>>>>>>> Most cumbersome to query all providers
>>>>>>>> 2. Can't put some constraints on non-base
columns (esp. not null)
>>>>>>>> 3. Joins are needed - opposite of the pros of 2.
>>>>>>>>
>>>>>>>> From personal experience, I find #2 to be better and
easier to
>>>>>>>> work
>>>>>>>> with & maintain.
>>>>>>>>
>>>>>>>> What are your thoughts?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
2:42 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Mike Kolesnik" <mkolesni(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, May 12, 2013 5:05:52 PM
Subject: Re: [Engine-devel] What type of DB inheritance to use?
On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>
> ----- Original Message -----
>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>> ----- Original Message -----
>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>> Hi All,
>>>>>
>>>>> I would like to have your opinions on which inheritance type to use
in
>>>>> the DB.
>>>>> We are adding an "external provider" entity to the system
which will be
>>>>> able to provide various resources (networks, hosts, etc).
>>>>>
>>>>> These providers will be distinguishable by "type".
>>>>> The basic definition of a provider contains:
>>>>>
>>>>> * name
>>>>> * description
>>>>> * url
>>>>> * type
>>>>>
>>>>> Some providers might need additional properties such as:
>>>>>
>>>>> * user
>>>>> * password
>>>>
>>>> what type of provider won't require authentication?
>>>
>>> Quantum provider in the 1st implementation will not require these fields.
>>> It will eventually require some sort of authentication, but not
>>> necessarily
>>> these fields, or only these fields.
>>
>> I'm not talking about a POC.
>> unless we pass through credentials of users for some actions, how do you
>> use a provider without user/password (or client cert, etc. - i.e., all
>> authentication methods are usually similar on the info you need to
>> persist)?
>
> I did not say that we will use Quantum without auth, only that these fields
> may or
> may not necessarily be in the Quantum provider entity.
>
> I think this is regardless of the main discussion here of inheritance,
> which I
> think will happen regardless of how Quantum provider is implemented. If you
> wish
> to discuss these details I'll be happy do it on a new thread, so that this
> one
> can stay focused on the subject of DB inheritance.
how many discrepancies do we expect between the various providers, to be
actually defined at provider level rather than consumption level?
IMO, the following fields will fit most providers, at least the ones we plan to support in
the near future:
* id
* name
* type
* URL
* requires_authentication (boolean) to support development/POC/testing... mode
* username
* password
>
>>
>>>
>>>>
>>>>>
>>>>> In Java this is easily represented by inheritance.
>>>>>
>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>
>>>>> 1. No inheritance.
>>>>> This means that each type will wit in his own table, with no
>>>>> relation or re-use.
>>>>> 2. Single table inheritance.
>>>>> All types sit in a single table, and each has his
corresponding
>>>>> columns.
>>>>> 3. Multiple table inheritance.
>>>>> Each type sists in his own table, where the PK is FK for the
most
>>>>> basic table (providers).
>>>>>
>>>>>
>>>>> Pros for each approach:
>>>>>
>>>>> 1. None that I can think of.
>>>>> 2. No joins:
>>>>> Better performance
>>>>> Easier for developer to see the DB info
>>>>> Facilitate column reuse
>>>>> 3. Constraints can be set on each column
>>>>>
>>>>> Cons for each approach:
>>>>>
>>>>> 1. No reuse of DB entities + no compliance for column types
>>>>> Most cumbersome to query all providers
>>>>> 2. Can't put some constraints on non-base columns (esp. not
null)
>>>>> 3. Joins are needed - opposite of the pros of 2.
>>>>>
>>>>> From personal experience, I find #2 to be better and easier to
work
>>>>> with & maintain.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>
>>>>
>>
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:44 a.m.
----- Original Message -----
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Mike Kolesnik" <mkolesni(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Sunday, May 12, 2013 5:05:52 PM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
>
> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
> >
> > ----- Original Message -----
> >> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> >>> ----- Original Message -----
> >>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> I would like to have your opinions on which inheritance type to
use
> >>>>> in
> >>>>> the DB.
> >>>>> We are adding an "external provider" entity to the
system which will
> >>>>> be
> >>>>> able to provide various resources (networks, hosts, etc).
> >>>>>
> >>>>> These providers will be distinguishable by "type".
> >>>>> The basic definition of a provider contains:
> >>>>>
> >>>>> * name
> >>>>> * description
> >>>>> * url
> >>>>> * type
> >>>>>
> >>>>> Some providers might need additional properties such as:
> >>>>>
> >>>>> * user
> >>>>> * password
> >>>>
> >>>> what type of provider won't require authentication?
> >>>
> >>> Quantum provider in the 1st implementation will not require these
> >>> fields.
> >>> It will eventually require some sort of authentication, but not
> >>> necessarily
> >>> these fields, or only these fields.
> >>
> >> I'm not talking about a POC.
> >> unless we pass through credentials of users for some actions, how do you
> >> use a provider without user/password (or client cert, etc. - i.e., all
> >> authentication methods are usually similar on the info you need to
> >> persist)?
> >
> > I did not say that we will use Quantum without auth, only that these
> > fields
> > may or
> > may not necessarily be in the Quantum provider entity.
> >
> > I think this is regardless of the main discussion here of inheritance,
> > which I
> > think will happen regardless of how Quantum provider is implemented. If
> > you
> > wish
> > to discuss these details I'll be happy do it on a new thread, so that
> > this
> > one
> > can stay focused on the subject of DB inheritance.
>
> how many discrepancies do we expect between the various providers, to be
> actually defined at provider level rather than consumption level?
>
IMO, the following fields will fit most providers, at least the ones we plan
to support in the near future:
* id
* name
* type
* URL
* requires_authentication (boolean) to support development/POC/testing...
mode
* username
* password
Sounds good to me
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>> In Java this is easily represented by inheritance.
> >>>>>
> >>>>> In the DB however, there are 3 approaches that we can take:
> >>>>>
> >>>>> 1. No inheritance.
> >>>>> This means that each type will wit in his own table, with
no
> >>>>> relation or re-use.
> >>>>> 2. Single table inheritance.
> >>>>> All types sit in a single table, and each has his
corresponding
> >>>>> columns.
> >>>>> 3. Multiple table inheritance.
> >>>>> Each type sists in his own table, where the PK is FK for
the
> >>>>> most
> >>>>> basic table (providers).
> >>>>>
> >>>>>
> >>>>> Pros for each approach:
> >>>>>
> >>>>> 1. None that I can think of.
> >>>>> 2. No joins:
> >>>>> Better performance
> >>>>> Easier for developer to see the DB info
> >>>>> Facilitate column reuse
> >>>>> 3. Constraints can be set on each column
> >>>>>
> >>>>> Cons for each approach:
> >>>>>
> >>>>> 1. No reuse of DB entities + no compliance for column types
> >>>>> Most cumbersome to query all providers
> >>>>> 2. Can't put some constraints on non-base columns (esp.
not null)
> >>>>> 3. Joins are needed - opposite of the pros of 2.
> >>>>>
> >>>>> From personal experience, I find #2 to be better and easier
to
> >>>>> work
> >>>>> with & maintain.
> >>>>>
> >>>>> What are your thoughts?
> >>>>>
> >>>>> Regards,
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel(a)ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
2:46 a.m.
On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
IMO, the following fields will fit most providers, at least the ones
we plan to support in the near future:
* id
* name
* type
* URL
* requires_authentication (boolean) to support development/POC/testing... mode
redundant with empty username/password?
* username
* password
do keystone based services allow to authenticate directly to them, or
you need an additional authentication url (to get the ticket)?
3:05 a.m.
----- Original Message -----
On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> IMO, the following fields will fit most providers, at least the ones we
> plan to support in the near future:
> * id
> * name
> * type
> * URL
> * requires_authentication (boolean) to support development/POC/testing...
> mode
redundant with empty username/password?
Empty user/password is an implementation details.
Seems logical to me to be explicit about it.
> * username
> * password
do keystone based services allow to authenticate directly to them, or
you need an additional authentication url (to get the ticket)?
No, the OpenStack services require a header with the token:
"When Keystone is enabled, users that submit requests to the Quantum service must
provide an authentication token in X-Auth-Token request header. You obtain the token by
authenticating to the Keystone endpoint."
http://docs.openstack.org/api/openstack-network/2.0/content/Authenticatio...
3:11 a.m.
On 05/13/2013 11:05 AM, Mike Kolesnik wrote:
----- Original Message -----
> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
>> IMO, the following fields will fit most providers, at least the ones we
>> plan to support in the near future:
>> * id
>> * name
>> * type
>> * URL
>> * requires_authentication (boolean) to support development/POC/testing...
>> mode
>
> redundant with empty username/password?
Empty user/password is an implementation details.
Seems logical to me to be explicit about it.
>
>> * username
>> * password
>
> do keystone based services allow to authenticate directly to them, or
> you need an additional authentication url (to get the ticket)?
>
No, the OpenStack services require a header with the token:
"When Keystone is enabled, users that submit requests to the Quantum service must
provide an authentication token in X-Auth-Token request header. You obtain the token by
authenticating to the Keystone endpoint."
http://docs.openstack.org/api/openstack-network/2.0/content/Authenticatio...
so you are missing an 'authentication url' field, although i think there
was some discussion that until we expect more than a single keystone,
may be a config
3:15 a.m.
----- Original Message -----
On 05/13/2013 11:05 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
>>> IMO, the following fields will fit most providers, at least the ones we
>>> plan to support in the near future:
>>> * id
>>> * name
>>> * type
>>> * URL
>>> * requires_authentication (boolean) to support development/POC/testing...
>>> mode
>>
>> redundant with empty username/password?
>
> Empty user/password is an implementation details.
> Seems logical to me to be explicit about it.
>
>>
>>> * username
>>> * password
>>
>> do keystone based services allow to authenticate directly to them, or
>> you need an additional authentication url (to get the ticket)?
>>
>
> No, the OpenStack services require a header with the token:
> "When Keystone is enabled, users that submit requests to the Quantum
> service must provide an authentication token in X-Auth-Token request
> header. You obtain the token by authenticating to the Keystone endpoint."
>
>
http://docs.openstack.org/api/openstack-network/2.0/content/Authenticatio...
>
so you are missing an 'authentication url' field, although i think there
was some discussion that until we expect more than a single keystone,
may be a config
I think at this point it makes sense to keep as config value and in the next phase of
OpenStack providers integration we can model the keystone & tenant entities properly.
I do however, agree with oved, that the username/password should be kept per provider.
6:07 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Oved Ourfalli" <ovedo(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Monday, May 13, 2013 9:46:48 AM
Subject: Re: [Engine-devel] What type of DB inheritance to use?
On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> IMO, the following fields will fit most providers, at least the ones we
> plan to support in the near future:
> * id
> * name
> * type
> * URL
> * requires_authentication (boolean) to support development/POC/testing...
> mode
redundant with empty username/password?
> * username
> * password
do keystone based services allow to authenticate directly to them, or
you need an additional authentication url (to get the ticket)?
You need the ticket, but we said that the keystone service (auth url, username
and password) are config values for the time being. Anyway in the future I expect
these providers to be linked to their keystone service. E.g.:
id name username password url auth_provider tenant ...
1 keystone1 myuser mypass http://keystone <null> <null>
2 glance1 <null> <null> http://glance 1 mytenant1
3 glance1 <null> <null> http://glance 1 mytenant2
4 quantum1 <null> <null> http://quantum 1 mytenant1
I expect quantum to be needing the tenant name too (as soon as it will be
integrated with keystone).
Given the username/password (created for the ovirt management), the user can
be added to the tenants (all the ones that the admin wants to consume) and
then ovirt will get the auth tokens with the relevant info, e.g. (pseudocode
with reference to the table above):
keystone = new Keystone("http://keystone");
glance1_token = keystone.authenticate("myuser", "mypass",
"mytenant1");
glance2_token = keystone.authenticate("myuser", "mypass",
"mytenant2");
quantum1_token = glance1_token;
glance = new Glance("http://glance", glance1_token);
glance.listImages();
....
--
Federico
3994
days inactive
3996
days old
22 comments
8 participants
participants (8)
-
Eli Mesika -
Federico Simoncelli -
Itamar Heim -
Liran Zelkha -
Mike Kolesnik -
Oved Ourfalli -
Saggi Mizrahi -
Yair Zaslavsky