[openstack-dev] [Murano][Heat][TC] MuranoPL questions?
sdake at redhat.com
Tue Mar 25 17:47:00 UTC 2014
On 03/25/2014 09:55 AM, Ruslan Kamaldinov wrote:
> Murano folks,
> I guess we should stop our debates with the Heat team about MuranoPL. What
> we should do instead is to carefully read this thread couple of times and
> collect and process all the feedback we've got. Steve and Zane did a very good
> job helping us to find a way to align with Heat and Orhcestration program. Let
> me outline the most important (imho) quotes:
The plan forward at the end of your email seem reasonable as well, but
Zane is probably in a bit better position to clarify if any suggested
changes would be recommended.
As a heat-core member, I would be supportive of ALM scope expansion
happening within the Orchestration program. I also think from a
technical perspective ALM fits nicely within the scope of OpenStack.
Just to head off possible questions about ALM and Solum, I do not see
them as competitive. I am only one voice among many, and think we need
some broad general agreement with heat-core and the TC that suggested
scope expansion makes sense and we won't get pushback 6-12 months down
the road. Perhaps the TC may think it belongs in a new program. I
honestly don't know. I'm not quite sure how to get that conversation
started, so I added [TC] to the subject tags in an attempt to get the
> # START quotes
> Steven Dake:
>> I see no issue with HOT remaining simple and tidy focused entirely on
>> orchestration (taking a desired state and converting that into reality) with
>> some other imperative language layered on top to handle workflow and ALM. I
>> believe this separation of concerns is best for OpenStack and should be the
>> preferred development path.
> Zane Bitter:
>> I do think we should implement the hooks I mentioned at the start of this
>> thread to allow tighter integration between Heat and a workflow engine
>> (i.e. Mistral).
>> So building a system on top of Heat is good. Building it on top of Mistral as
>> well would also be good, and that was part of the feedback from the TC.
>> To me, building on top means building on top of the languages (which users
>> will have to invest a lot of work in learning) as well, rather than having a
>> completely different language and only using the underlying implementation(s).
>> To me that implies that Murano should be a relatively thin wrapper that ties
>> together HOT and Mistral's DSL.
> Steve Dake:
>> I don't think HOT can do these things and I don't think we want HOT to do
>> these things. I am ok with that, since I don't see the pushback on having
>> two languages for two different things in OpenStack. I got from gokrove on
>> iRC today that the rationale for the pushback was the TC wanted Murano folks
>> to explore how to integrate better with Heat and possibly the orchestration
>> program. I don't see HOT as a place where there is an opportunity for scope
>> expansion. I see instead Murano creating HOT blobs and feeding them to Heat.
> Zane Bitter:
>> Because there have to be some base types that you can use as building blocks.
>> In the case of Heat, those base types are the set of things that you can
>> create by talking to OpenStack APIs authenticated with the user's token.
>> In the case of Mistral, I would expect it to be the set of actions that you
>> can take by talking to OpenStack APIs authenticated with the user's token.
>> And in the case of Murano, I would expect it to be the union of those two.
>> Everything is a combination of existing resources, because the set of existing
>> resources is the set of things which the operator provides as-a-Service. The
>> set of things that the operator provides as a service plus the set of things
>> that you can implement yourself on your own server (virtual or not) covers
>> the entire universe of things. What you appear to be suggesting is that
>> OpenStack must provide *Everything*-as-a-Service by allowing users to write
>> their own services and have the operator execute them as-a-Service. This
>> would be a breathtakingly ambitious undertaking, and I don't mean that in
>> a good way.
>> When the TC said "Murano is slightly too far up the stack at this point to
>> meet the "measured progression of openstack as a whole" requirement", IMO
>> one of the major things they meant was that you're inventing your own
>> workflow thing, leading to duplication of effort between this and Workflow
>> as a Service. (And Mistral folks are in turn doing the same thing by not
>> using the same workflow library, taskflow, as the rest of OpenStack.)
>> Candidly, I'm surprised that this is not the #1 thing on your priority list
>> because IMO it's the #1 thing that will delay getting the project incubated.
> # END quotes
> Also I should quote what Georgy Okrokvertkhov said:
>> Having this aligned I see a Murano package as an archive with all necessary
>> definitions and resources and Murano service will just properly pass them to
>> related services like Heat and Mistral. I think then Murano DSL will be much
>> more simple and probably will be closer to declarative format with some
>> specific data operations.
> I would like to propose further path for Murano evolution where it evolves as
> an OpenStack project, aligned with others and developed in agreement between
> all the interested sides. Here is the plan:
> * Step forward and implement hooks (for workflow customization) in Heat. We
> will register a blueprint, discuss it with the Heat team and implement it
> * Use our cross-project session on ATL summit to set clear goals and
> * Build pilot in Murano which:
> a. Uses new HOT Software components to do VM side software deployments
> b. Uses Mistral DSL to describe workflow. It'll require more focused
> discussion with Mistral team
> c. Bundles all that into an application package using new Murano DSL
> d. Allows users to combine applications in a single environenment
> * Continuously align with the Heat team
> * Continuously re-evaluate current state of pilot implementation and compare it
> with MuranoPL to keep track of features missing in pilot, but available in
> MuranoPL. If such feature exist - discuss it with the community. Find a place
> where the feature can be implemented and implement it
> * Murano DSL will focus on:
> a. UI rendering
> 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.
> There are examples in OpenStack community when absolutely new project is
> developed exactly for specific goal. For instance, there are a lot of task
> trackers (including Launchpad), but none of them was designed to address the
> needs of OpenStack community. That's why we're working on StoryBoard  - to
> address specific domain area.
> Clearly there is a need for a DSL to describe application packages. I believe
> that almost everyone agrees that there should be a layer on top of HOT to
> describe ALM. Feedback is - it should be simpler than our existing MuranoPL. So
> let's design that layer together.
>  https://wiki.openstack.org/wiki/StoryBoard
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev