Open Stack

Clint Byrum <clint at fewbar.com> wrote on 04/04/2014 19:05:04:
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Date: 04/04/2014 19:06
> Subject: Re: [openstack-dev] [Heat] [Murano] [Solum] applications inthe
cloud
>
> Excerpts from Stan Lagun's message of 2014-04-04 02:54:05 -0700:
> > Hi Steve, Thomas
> >
> > I'm glad the discussion is so constructive!
> >
> > If we add type interfaces to HOT this may do the job.
> > Applications in AppCatalog need to be portable across OpenStack clouds.
> > Thus if we use some globally-unique type naming system applications
could
> > identify their dependencies in unambiguous way.
> >
> > We also would need to establish relations between between interfaces.
> > Suppose there is My::Something::Database interface and 7 compatible
> > materializations:
> > My::Something::TroveMySQL
> > My::Something::GaleraMySQL
> > My::Something::PostgreSQL
> > My::Something::OracleDB
> > My::Something::MariaDB
> > My::Something::MongoDB
> > My::Something::HBase
> >
> > There are apps that (say SQLAlchemy-based apps) are fine with any
> > relational DB. In that case all templates except for MongoDB and HBase
> > should be matched. There are apps that design to work with MySQL only.
In
> > that case only TroveMySQL, GaleraMySQL and MariaDB should be matched.
There
> > are application who uses PL/SQL and thus require OracleDB (there can be
> > several Oracle implementations as well). There are also applications
> > (Marconi and Ceilometer are good example) that can use both some SQL
and
> > NoSQL databases. So conformance to Database interface is not enough and
> > some sort of interface hierarchy required.
>
> IMO that is not really true and trying to stick all these databases into
> one "SQL database" interface is not a use case I'm interested in
> pursuing.
>
> Far more interesting is having each one be its own interface which apps
> can assert that they support or not.

Agree, this looks like a feasible goal and would already bring some value
add in that one could look up appropriate provider templates instead of
having to explicitly link them in environments.
Doing too much of inheritance sounds interesting at first glance but
burries a lot of complexity.

>
> >
> > Another thing that we need to consider is that even compatible
> > implementations may have different set of parameters. For example
> > clustered-HA PostgreSQL implementation may require additional
parameters
> > besides those needed for plain single instance variant. Template that
> > consumes *any* PostgreSQL will not be aware of those additional
parameters.
> > Thus they need to be dynamically added to environment's input
parameters
> > and resource consumer to be patched to pass those parameters to actual
> > implementation
> >
>
> I think this is a middleware pipe-dream and the devil is in the details.
>
> Just give users the ability to be specific, and then generic patterns
> will arise from those later on.
>
> I'd rather see a focus on namespacing and relative composition, so that
> providers of the same type that actually do use the same interface but
> are alternate implementations will be able to be consumed. So for
instance
> there is the non-Neutron LBaaS and the Neutron LBaaS, and both have their
> merits for operators, but are basically identical from an application
> standpoint. That seems a better guiding use case than different
databases.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>