[openstack-dev] [Solum/Heat] Is Solum really necessary?

Alexander Tivelkov ativelkov at mirantis.com
Thu Nov 14 19:47:45 UTC 2013


That's an important question, and I've seen it being asked many times
before, often regarding the Murano project, which also hides Heat templates
under the hood: people were asking why do they need yet another abstraction
layer on top of the familiar and powerful tool such as Heat.

I believe that the difference is the target audience of the projects. It
seems to me that Heat's primary users are the people who will write their
own templates - or use the existing ones but having a deep understanding of
how their work.
Meanwhile, the end-users of Solum are application developers, they do not
need (and, probably, do not want at all) to worry about
infrastructure-specific tools, frameworks and APIs - and they are probably
not going to write the Heat (or HOT) templates on their own: they need a
higher-level tooling for that. And that is exactly the place where Solum
will come into play, generating these templates for them.

Alexander Tivelkov

2013/11/14 Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>

> Hi,
> I think that Heat is mostly focused on deployment even with new software
> configs and convergence. HOT template is quite "static" description of
> desired state we want to achieve and it is up to Heat engine how to achieve
> this state.
> Solum is focused on managing the process of converting source code to some
> deployable entity (image or container). The power of Solum is an ability to
> fully describe and control the process of building and testing of
> application. Some of the stages of build and testing process might require
> actual deployment and stack creation, but this is not an ultimate goal of
> the Solum.
> If someone will try to use just Heat for building process description they
> will figure out quickly that they need different templates for different
> build\testing stages. As Heat itself can't modify templates you will need
> some external mechanism for template creation, and this is what Solum
> actually does.
> Thanks
> Georgy
> On Thu, Nov 14, 2013 at 11:08 AM, Christopher Armstrong <
> chris.armstrong at rackspace.com> wrote:
>> On Thu, Nov 14, 2013 at 11:04 AM, Sam Alba <sam.alba at gmail.com> wrote:
>>> Hi Jay,
>>> I think Heat is an ingredient for Solum. When you build a PaaS, you
>>> need to control the app at different levels:
>>> #1 describing your app (basically your stack)
>>> #2 Pushing your code
>>> #3 Deploying it
>>> #4 Controlling the runtime (restart, get logs, scale, changing
>>> resources allocation, etc...)
>>> I think Heat is a major component for step 3. But I think Heat's job
>>> ends at the end of the deployment (the status of the stack is
>>> "COMPLETED" in Heat after processing the template correctly). It's
>>> nice though to rely on Heat's template generation for describing the
>>> stack, it's one more thing to delegate to Heat.
>>> In other words, I see Heat as an engine for deployment (at least in
>>> the context of Solum) and have something on top to manage the other
>>> steps.
>> I'd say that Heat does (or should do) more than just the initial
>> deployment -- especially with recent discussion around healing /
>> convergence.
>> --
>> IRC: radix
>> Christopher Armstrong
>> Rackspace
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/51c33d0f/attachment.html>

More information about the OpenStack-dev mailing list