Open Stack

I'm trying to think how the process is looks like from the application
provider point of view.
As application provider I need to:
1) Develop a new application, using 3rd party components (DB, Application
Container, Cache, Messaging etc).
2) Build and test my application
2) Upload the deployment artifact to the application catalog
3) Immediately or by demand of the dependent application to provision the
application to the certain environment
4) Automate application run-time management
5) Upgrade the application
6) Terminate the application


Now, getting to the underline OpenStack services, I  would think about the
following combination:
1) Develop, Build, Test and create an deployment artifact - Solum
2) Manage underline resources for deployment - Solum using Heat
3) Application Catalog Management - Murano
4) Application Deployment - Solum (for developed application) and Murano
(for dependent services: DB, Cache etc). Heroku BuildPack feature is
something I would suggest to embrace.
5) Run-time management - scale, repair, replicate, upgrade etc Solum using
Murano
6) Termination - Solum using Murano

My 2 cents  for the issue.

Dmitry


On Thu, Apr 3, 2014 at 3:04 AM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> 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.
>
> Thanks
> Georgy
>
>
> On Wed, Apr 2, 2014 at 3:30 PM, Steve Baker <sbaker at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/1e816b03/attachment.html>