Open Stack

>
>
> *Murano UI to Dashboard Program*
>
> Application Catalog requires  a UI focused on user experience. Currently
> there is a Horizon plugin for Murano App Catalog which adds Application
> catalog page to browse, search and filter applications. It also adds a
> dynamic UI functionality to render a Horizon forms without writing an
> actual code.
>
>
>
> Are we going to wait for the generic UI (Merlin) or get murano-dashboard
into Horizon then work on Merlin?

Merlin will be a generic library\framework in Horizon for Application
projects (Heat, Murano, Solum). We still need to have specific
implementations of UI for each project, but these projects will reuse the
common code.

We can put existing Murano UI to Dashboard or inside Catalog program as a
separate repo. I think it might make sense to keep UI components closer to
project rather then keep UI in a separate program.


On Thu, Aug 21, 2014 at 6:35 PM, Angus Salkeld <asalkeld at mirantis.com>
wrote:

> On Thu, Aug 21, 2014 at 6:14 AM, Georgy Okrokvertskhov <
> gokrokvertskhov at mirantis.com> wrote:
>
>> During last Atlanta summit there were couple discussions about
>> Application Catalog and Application space projects in OpenStack. These
>> cross-project discussions occurred as a result of Murano incubation request
>> [1] during Icehouse cycle.  On the TC meeting devoted to Murano incubation
>> there was an idea about splitting the Murano into parts which might belong
>> to different programs[2].
>>
>>
>> Today, I would like to initiate a discussion about potential splitting of
>> Murano between two or three programs.
>>
>>
>> *App Catalog API to Catalog Program*
>>
>> Application Catalog part can belong to Catalog program, the package
>> repository will move to artifacts repository part where Murano team already
>> participates. API part of App Catalog will add a thin layer of API methods
>> specific to Murano applications and potentially can be implemented as a
>> plugin to artifacts repository. Also this API layer will expose other 3rd
>> party systems API like CloudFoundry ServiceBroker API which is used by
>> CloudFoundry marketplace feature to provide an integration layer between
>> OpenStack Application packages and 3rd party PaaS tools.
>>
>>
> Seems to make sense, tho' I am not a glance-core.
>
>
>>
>>
>> *Murano Engine to Orchestration Program*
>>
>> Murano engine orchestrates the Heat template generation. Complementary to
>> a Heat declarative approach, Murano engine uses imperative approach so that
>> it is possible to control the whole flow of the template generation. The
>> engine uses Heat updates to update Heat templates to reflect changes in
>> applications layout. Murano engine has a concept of actions - special flows
>> which can be called at any time after application deployment to change
>> application parameters or update stacks. The engine is actually
>> complementary to Heat engine and adds the following:
>>
>>
>>    - orchestrate multiple Heat stacks - DR deployments, HA setups,
>>    multiple datacenters deployment
>>    - Initiate and controls stack updates on application specific events
>>    - Error handling and self-healing - being imperative Murano allows
>>    you to handle issues and implement additional logic around error handling
>>    and self-healing.
>>
>>
>>
> +1
>
> Are the teams going to work as-is from a core reviewer PoV (I'd assume so,
> just clarifying). I am just wondering how
> we can get the Heat and Murano teams to know what each are doing -
> basically work at least somewhat together.
>
>
>>
>> *Murano UI to Dashboard Program*
>>
>> Application Catalog requires  a UI focused on user experience. Currently
>> there is a Horizon plugin for Murano App Catalog which adds Application
>> catalog page to browse, search and filter applications. It also adds a
>> dynamic UI functionality to render a Horizon forms without writing an
>> actual code.
>>
>>
>>
> Are we going to wait for the generic UI (Merlin) or get murano-dashboard
> into Horizon then work on Merlin?
>
> -Angus
>
>
>>
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html
>>
>> [2]
>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-04-20.02.log.txt
>>
>>
>>
>> --
>> 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
>>
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/45c8f94f/attachment.html>