[Engine-devel] What type of DB inheritance to use?

[Itamar Heim]

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 at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>