Hi Ruslan, > From: Ruslan Kamaldinov <rkamaldi...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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.spatz...@de.ibm.com> wrote: > > Clint Byrum <cl...@fewbar.com> wrote on 04/04/2014 19:05:04: > >> From: Clint Byrum <cl...@fewbar.com> > >> To: openstack-dev <openstack-dev@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@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev