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

[Mike Kolesnik]

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