[Engine-devel] What type of DB inheritance to use?
------=_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--
------=_Part_119211_1477841530.1368352381010 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
</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=
------=_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" <mkolesni@redhat.com><br><b>To: </b>"engine-devel" <en= gine-devel@ovirt.org><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= 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--
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@redhat.com>wrote:
------------------------------
*From: *"Mike Kolesnik" <mkolesni@redhat.com> *To: *"engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Liran Zelkha" <liran.zelkha@gmail.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com > wrote:
From: "Mike Kolesnik" < mkolesni@redhat.com > To: "engine-devel" < engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Liran Zelkha" <liran.zelkha@gmail.com> Cc: "engine-devel" <engine-devel@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@gmail.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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
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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Liran Zelkha" <liran.zelkha@gmail.com> Cc: "engine-devel" <engine-devel@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@gmail.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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
Sorry, very tired. I read what I wrote and thought I should rephrase. 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@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Liran Zelkha" <liran.zelkha@gmail.com> Cc: "engine-devel" <engine-devel@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@gmail.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >
----- 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@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > >
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@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >>
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Mike Kolesnik" <mkolesni@redhat.com> Cc: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Mike Kolesnik" <mkolesni@redhat.com> Cc: "engine-devel" <engine-devel@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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)?
----- 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/Authentication-d...
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/Authentication-d...
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
----- 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/Authentication-d...
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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: "engine-devel" <engine-devel@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
participants (8)
-
Eli Mesika -
Federico Simoncelli -
Itamar Heim -
Liran Zelkha -
Mike Kolesnik -
Oved Ourfalli -
Saggi Mizrahi -
Yair Zaslavsky