Keith is my co-worker. I deeply respect his opinion, and agree with his perspective with respect to devops users. That's exactly the persona that OpenStack appeals to today. However, devops is not the only perspective to consider.
OpenStack has not yet crossed the barrier into attracting Application Developers en-masse. The Application Developer persona has a different perspective, and would prefer not to use a DSL at all when they are building applications based on common design patterns. One such example is the three-tier-web application. Solum intends to address these use patterns using sensible selectable defaults such that most application developers do not need to use a DSL at all to run apps on OpenStack. They instead use parameters to select well understood and well documented patterns. We will generate HOT files as outputs and feed them into Heat for orchestration. For the smaller minority of application developers who do want a DSL to describe their app topology, we can offer them a choice: 1) Use the Heat DSL, and describe it in terms of infra resources. 2) Use an application-centric DSL that does not directly pertain to the resources in the Heat DSL. In cases where #2 is used, #1 will probably also be used as a complimentary input. There are reasons for having other DSL options that allow modeling of things that are not infrastructure resources. We would be fools to think that HOT is the only home for all that. HOT is about orchestration, not universal entity modeling and management. Devops users will naturally select HOT, not any alternate DSL. With that said, Solum aims to use HOT to the fullest extent. We may also offer to add features to it. Some things still do not fit there. Rather than debating the technical merits of a new DSL, and how it could be accomplished by tweaking existing projects, it would be wise for us to ask (and listen) carefully about WHY the alternate approach is desired. Some of it can certainly be addressed by HOT, and should. Some of it has no business in the orchestration system at all. Let's not quickly dismiss alternate approaches in cases where they do not overlap, or where the style and approach are essentially the same. Example: We have numerous programming languages today. Each one exists for a reason. Understanding those reasons and selecting the right tool for the job is a key to success as a computer scientist. I look forward to further discussions with the Heat team, and other StackForge projects to work to find more common ground and identify those areas where we should splinter off to innovate. Based on my in-person discussions with Georgy from Mirantis this week, I am convinced that they do intend to use Heat to the extent practical in Murano. I am continuing to keep an open mind about the desire to have other DSL systems that work on different planes and for different reasons than Heat. Adrian > On Mar 26, 2014, at 1:27 PM, "Keith Bray" <keith.b...@rackspace.com> wrote: > >> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
