On 03/04/14 13:04, Georgy Okrokvertskhov wrote: > Hi Steve, > > I think this is exactly the place where we have a boundary between > Murano catalog and HOT. > > In your example one can use abstract resource type and specify a > correct implementation via environment file. This is how it will be > done on the final stage in Murano too. > > Murano will solve another issue. In your example user should know what > template to use as a provider template. In Murano this will be done in > the following way: > 1) User selects an app which requires a DB > 2) Murano sees this requirement for DB and do a search in the app > catalog to find all apps which expose this functionality. Murano uses > app package definitions for that. > 3) User select in UI specific DB implementation he wants to use. > > As you see, in Murano case user has no preliminary knowledge of > available apps\templates and it uses catalog to find it. A search > criteria can be quite complex with using different application > attribute. If we think about moving application definition to HOT > format it should provide all necessary information for catalog. > > In order to search apps in catalog which uses HOT format we need > something like that: > > One needs to define abstract resource like > OS:HOT:DataBase > > Than in each DB implementation of DB resource one has to somehow refer > this abstract resource as a parent like > > Resource OS:HOT:MySQLDB > Parent: OS:HOT:DataBase > > Then catalog part can use this information and build a list of all > apps\HOTs with resources with parents OS:HOT:DataBase > > That is what we are looking for. As you see, in this example I am not > talking about version and other attributes which might be required for > catalog. >
This sounds like a vision for Murano that I could get behind. It would be a tool which allows fully running applications to be assembled and launched from a catalog of Heat templates (plus some app lifecycle workflow beyond the scope of this email). We could add type interfaces to HOT but I still think duck typing would be worth considering. To demonstrate, lets assume that when a template gets cataloged, metadata is also indexed about what parameters and outputs the template has. So for the case above: 1) User selects an app to launch from the catalog 2) Murano performs a heat resource-type-list and compares that with the types in the template. The resource-type list is missing My::App::Database for a resource named my_db 3) Murano analyses the template and finds that My::App::Database is assigned 2 properties (db_username, db_password) and elsewhere in the template is a {get_attr: [my_db, db_url]} attribute access. 4) Murano queries glance for templates, filtering by templates which have parameters [db_username, db_password] and outputs [db_url] (plus whatever appropriate metadata filters) 5) Glance returns 2 matches. Murano prompts the user for a choice 6) Murano constructs an environment based on the chosen template, mapping My::App::Database to the chosen template 7) Murano launches the stack Sure, there could be a type interface called My::App::Database which declares db_username, db_password and db_url, but since a heat template is in a readily parsable declarative format, all required information is available to analyze, both during glance indexing and app launching. > > > On Wed, Apr 2, 2014 at 3:30 PM, Steve Baker <sba...@redhat.com > <mailto:sba...@redhat.com>> wrote: > > On 03/04/14 10:39, Ruslan Kamaldinov wrote: > > This is a continuation of the "MuranoPL questions" thread. > > > > As a result of ongoing discussions, we figured out that > definition of layers > > which each project operates on and has responsibility for is not > yet agreed > > and discussed between projects and teams (Heat, Murano, Solum (in > > alphabetical order)). > > > > Our suggestion and expectation from this working group is to > have such > > a definition of layers, agreement on it and an approach of > reaching it. > > > > As a starting point, we suggest the following: > > > > There are three layers of responsibility: > > 1. Resources of the cloud > > 2. Applications of the cloud > > 3. Layers specific for Murano and Solum (to be further discussed and > > clarified, for this discussion it's out of scope) > > > > Layer 1 is obviously covered by Heat. > > > > Most of the disagreement is around layer 2. Our suggestion is to > figure out > > the way where we can have common engine, DSL and approach to > apps description. > > For this we'll take HOT and TOSCA as a basis and will work on > addition of > > functionality missing from Murano and Solum point of view. > > > > We'll be happy if existing Heat team continue working on it, > having the full > > control of the project, provided that we agree on functionality > missing there > > from Murano and Solum point of view and addition of this > functionality in a > > systematic way. > > > > Let me outline the main concern in regards to HOT from Murano > perspective. > > Others concerns could be figured out later. The typical use case > for Murano is > > the following: > > Application writer sets a requirement for her application to use > RDBMS > > assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine > should be able > > to understand such requirements and be able to satisfy them by > instantiating > > instances with DB. End user should be able to control which > particular type of > > DB should be used. This is quite similar to abstract > requirements described in > > TOSCA. As Heat wants to cover TOSCA format too this Murano > requirement is > > pretty well aligned with what HOT\TOSCA can provide. > > > > > > Hopefully this functionality can be introduced into HOT. Solum > and Murano will > > leverage it by using some common API, and implementing layer 3 > as thin as > > possible. > > > > Again, this is only suggested starting point, something to begin > with. > > > Thanks for bring this discussion back to solving specific > problems. The > above database abstraction can be nicely represented using HOT > environments and provider resources [1]. > > Take the following template snippet: > > resources: > my_db: > type: My::Database > properties: > # ... > > my_server > type: OS::Nova::Server > properties: > # ... including a {get_attr: [my_db, connection_url]} > > My::Database is a type defined in the environment which is included in > the stack-create call. Different environments can provide different > database implementations, for example: > > resource_registry: > "My::Database": path/to/trove_wrapper.yaml > > resource_registry: > "My::Database": path/to/nova_galera_ubercluster.yaml > > resource_registry: > "My::Database": path/to/postgresql.yaml > > Each of these templates could be implemented to have the same > parameters > and outputs so the template will work with any of these resource > provider templates. > > One thing we could consider adding to HOT is allow the defining of a > type interface, and validating that a given template/resource > implements > its declared interfaces. However the above example works just fine > without interfaces, and this duck-typing approach may provide a better > user experience anyway. > > [1] > http://docs.openstack.org/developer/heat/template_guide/environment.html >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev