On 3/25/14 11:55 AM, "Ruslan Kamaldinov" <rkamaldi...@mirantis.com> wrote:
>* Murano DSL will focus on: > a. UI rendering One of the primary reasons I am opposed to using a different DSL/project to accomplish this is that the person authoring the HOT template is usually the system architect, and this is the same person who has the technical knowledge to know what technologies you can swap in/out and still have that system/component work, so they are also the person who can/should define the "rules" of what component building blocks can and can't work together. There has been an overwhelmingly strong preference from the system architects/DevOps/ApplicationExperts I [1] have talked to for the ability to have control over those rules directly within the HOT file or immediately along-side the HOT file but feed the whole set of files to a single API endpoint. I'm not advocating that this extra stuff be part of Heat Engine (I understand the desire to keep the orchestration engine clean)... But from a barrier to adoption point-of-view, the extra effort for the HOT author to learn another DSL and use yet another system (or even have to write multiple files) should not be underestimated. These people are not OpenStack developers, they are DevOps folks and Application Experts. This is why the Htr[2] project was proposed and threads were started to add extra data to HOT template that Heat engine could essentially ignore, but would make defining UI rendering and component connectivity easy for the HOT author. I'm all for contributions to OpenStack, so I encourage the Murano team to continue doing its thing if they find it adds value to themselves or others. However, I'd like to see the Orchestration program support the surrounding things the users of the Heat engine want/need from their cloud system instead of having those needs met by separate projects seeking incubation. There are technical ways to keep the core engine "clean" while having the Orchestration Program API Service move up the stack in terms of cloud user experience. > b. HOT generation > c. Setup other services (like put Mistral tasks to Mistral and bind > them with events) > >Speaking about new DSL for Murano. We're speaking about Application >Lifecycle >Management. There are a lot of existing tools - Heat/HOT, Python, etc, >but none >of them was designed with ALM in mind as a goal. Solum[3] is specifically designed for ALM and purpose built for OpenStack... It has declared that it will generate HOT templates and setup other services, including putting together or executing supplied workflow definition (using Mistral if applicable). Like Murano, Solum is also not an OpenStack incubated project, but it has been designed with community collaboration (based on shared pain across multiple contributors) with the ALM goal in mind from the very beginning. -Keith [1] I regularly speak with DevOps, Application Specialists, and cloud customers, specifically about Orchestration and Heat.. HOT is somewhat simple enough for the most technical of them (DevOps & App Specialists) to grasp and have interest in adopting, but their is strong push back from the folks I talk to about having to learn one more thing... Since Heat adopters are exactly the same people who have the knowledge to define the overall system capabilities including component connectivity and how UI should be rendered, I'd like to keep it simple for them. The more we can do to have the Orchestration service look/feel like one thing (even if it's Engine + Other things under the hood), or reuse other OpenStack core components (e.g. Glance) the better for adoption. [2] https://wiki.openstack.org/wiki/Heat/htr [3] http://solum.io _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev