Open Stack

Update:
Stan filed a blueprint [0] for type interfaces in HOT.


I would like to outline the current vision of Murano Application format, to
make sure we're all on the same page. We had a valuable discussion in several
MLs and we also had a lot of discussions between Murano team members. As a
result of these discussion we see the following plan for Murano:

* Adopt TOSCA for application definition in Murano. Work with TOSCA committee
* Utilize Heat as much as possible. Participate in discussions and
  implementations for hooks mechanism in Heat. Participate in HOT format
  discussions
* Adopt Mistral DSL for workflow management. Find a way to compose Heat
  templates and Mistral DSL
* Keep MuranoPL engine in the source tree to take care of all the features we
  need for our users until those features are implemented on top things
  described above

Murano, Heat teams, please let me know if this plan sounds sane to you.

[0] https://blueprints.launchpad.net/heat/+spec/interface-types

Thanks,
Ruslan

On Sat, Apr 5, 2014 at 12:25 PM, Thomas Spatzier
<thomas.spatzier at de.ibm.com> wrote:
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev