Open Stack

Hi Ruslan,

> From: Ruslan Kamaldinov <rkamaldinov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 16/04/2014 00:38
> Subject: Re: [openstack-dev] [Heat] [Murano] [Solum] applications inthe
cloud
>
> 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

Those two sound great. For the version of TOSCA we are currently defining,
the more concrete implementation input we get, the better. So your
collaboration is more than welcome. And putting things into Heat that make
sense to be put into Heat is also a good plan, since this gives us a common
code base instead of duplicated efforts.

It would be good to get together at the next summit and discuss some of
this. We also started implementation of a TOSCA YAML library and a
translator to HOT as a stackforge project, and we are thinking about how a
"TOSCA layer" actually fits into the overall picture. Would be good to talk
about this with key stackholders. I actually submitted a sessions proposal
for one of the "open source @ OpenStack" slots to get a room and time slot,
but have not heard back yet.

> * Adopt Mistral DSL for workflow management. Find a way to compose Heat
>   templates and Mistral DSL

Also makes sense, and this is another item where we have some interest from
a TOSCA perspective.

Regards,
Thomas

> * 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>