[openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

Clint Byrum clint at fewbar.com
Fri Apr 4 17:05:04 UTC 2014


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.

> 
> 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.



More information about the OpenStack-dev mailing list