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:
Ruslan,
+2!
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
ball rolling.
Regards,
-steve
# 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.
Summary:
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
expectations
* 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 [0] - 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.
[0] https://wiki.openstack.org/wiki/StoryBoard
Thanks,
Ruslan
_______________________________________________
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
