[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Differentiating TOSCA from HEAT
|
Thanks, Tal In our previous meeting, you mentioned that you are aware of bad experience and failures using âHEATâ, and for this discussion I donât think it matters if those
failures have been due to the HEAT orchestrator, the HOT language for configuring services with HEAT, or with the OpenStack architecture as a whole. After that, you are right that some of my concerns are with the expressiveness of HOT. I was hoping that you could add for our positioning of TOSCA some more concrete details about the mentioned bad experience? What exactly was the nature and reasons
for those failures? Your 4 bullets are too generic, I think. You mention that HEAT is slow and does not scale, and you ascribe that to the OpenStack architecture, and not so much to the HOT language. Is that, in your opinion, the primary reason for the shortcoming
of HEAT? If so, to ensure the success of TOSCA we would need to give some attention to scalability in our discussions. Concerning your views on declarative orchestration, clearly if a single underlying management system, and the components it orchestrates are all fully declarative
and insensitive to sequencing, then indeed, the orchestrator itself does not need to be concerned with sequencing. But at the lowest level, technology is inherently sensitive to sequencing. Example: Installing a VM running a database application. If the management
system allows you to specify this declaratively, including the required database configuration, then the orchestrator does not need to be concerned with the sequencing. If another VM needs to run an application that uses the database, and the two VMs are created
and started in arbitrary order, then either that application needs to be insensitive to situations where the database is not yet ready or the declarative management system must be aware of the dependency. The point is that the temporal dependencies do not go away by themselves. The prerequisite is careful design of applications and management systems to fit into
such a paradigm, and eventually in some cases, we are basically just pushing the sequencing problem down to lower level orchestrators/management-systems, and if the service topology happens to span more than one management system, then not only must each system
be declarative within itself, but all the systems must be designed to interwork according to the âcentrifugeâ model to handle any required sequencing between them. This is a beautiful vision, but as you also say, we are not there, and so TOSCA will need to be able to support any sequencing requirements that are not yet within
the capabilities of the systems being orchestrated. Frankly, just as you doubt the future of the state-sequencing model, I doubt the scalability and practicality of the centrifuge vision. But we donât need to settle
that â I definitely acknowledge the relevance of the centrifuge model for some scenarios and you recognize that state-sequencing will still be required for TOSCA for some time. So no need to argue about that. Best regards Peter From: Tal Liron [mailto:tliron@redhat.com]
On Tue, Jan 4, 2022 at 8:33 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:
It's a useful comparison, but importantly TOSCA is not so clearly superior in every aspect. The fully-declarative approach has linguistic disadvantages. By the way, "Heat" is the orchestration module, "HOT" is the language, though this distinction isn't always very meaningful. It becomes meaningful in the
Tacker project, which intends to be a TOSCA frontend for Heat (behind the scenes it translates to HOT, as far as I remember). By the way, Tacker's "problem", as I see it, is not in its
use of TOSCA, but in its use of the Simple Profile. The Simple Profile means that Tacker can do much less than HOT. But there's no reason why Tacker can't model all OpenStack resources in TOSCA. I have an
example of this. Also note that Puccini can compile
HOT into Clout, though obviously HOT is missing many features over TOSCA.
Well, you can, it's just not very easy. But it is powerful. TOSCA is designed to be extensible by using TOSCA itself (that's sometimes how I explain TOSCA to people: the same language is used for both the resources and their schema). For
HOT you need to use Python, but once you are in Python you can perform all kinds of validations that are impossible to do in TOSCA.
This is essentially true. TOSCA capabilities allow for a kind of composition (I often call a TOSCA node an "assemblage" of capabilities). In HOT these sub-components are all separate resources. The assemblage is often implied by using the
get_resource function.
Well, artifacts are not their own types (and there is no packaging format, like CSAR), but they are supported in a few ways: 1. The
get_file function lets you insert artifacts anywhere in HOT. This is actually more flexible, in some ways, to TOCA's get_artifact function. 2. Some OpenStack components support artifacts and these are specifically modeled as resource types. Examples:
Glance WebImage,
Barbican Secret,
Heat CloudConfig, etc. (By the way, HOT has more intrinsic functions than TOSCA, so it "wins" in this respect.)
I wouldn't say that it has no such concept, just that it has a very weak one. There is only one kind of relationship in HOT and that's "dependency", which is implicitly created via calls to functions such as get_resource and get_attr. It's
possible to extract this graph from the HOT parser. I find "dependency" relationships to be the least interesting. They are important for one and only purpose: to automatically create a "deploy" workflow for non-declarative platforms. TOSCA's power is in introducing typed relationships,
where each type implies its own semantic graph. One obvious use is networking, but we see graphs everywhere in the cloud: clustering, redundancy hierarchies, data streaming, service meshes, etc.
Well, this is true in the sense that all supported modules are part of the OpenStack project. But the point is that OpenStack is modular, and every OpenStack module represents its own management system. For example, Neutron is very different
from Nova. And then you have something like
Magnum for containers, which is again different from Nova. And it's definitely possible to create a custom module, which supports HOT, but is not part of the OpenStack family of modules.
Yes, but I would argue that TOSCA doesn't, either. At least not yet. :) You can probably manage event streams as relationship types. But doing so is in no way integrated with TOSCA operations/notifications.
So, if you recall from above, the dependency graph is used to generate a deployment workflow, which is not entirely unsophisticated LCM. There is, at least, an idea of when in time the object exists or does not exist. But also you can plug in your own custom
Mistral Workflow. Without saying anything bad about Mistral, I'll mention that most users probably use an external workflow engine to do their LCM work, something like Ansible.
Yes, Heat is also slow and painful and does not scale well. But that's not the fault of the HOT language. I mostly blame the traditional phase-by-phase paradigm baked into OpenStack for this. I think it's important for TOSCA to support
this paradigm because many systems look like this, but I can't see how TOSCA can fix the problem of "half-created services" (indeterminate states). It's not a language challenge but an architectural challenge. The solution I propose is simply "don't do this", or rather "don't assume that you can succeed in doing LCM in the cloud". In fully-declarative approaches there is no concept of order and time and instead you take for granted that state
is emergent (and to an extent ephemeral). TOSCA doesn't have to do anything special to support this paradigm because, again, it's a matter of "don't do this". If you're not modeling any kind of workflow then the feature is just not there. So TOSCA lends itself
quite easily to a fully-declarative approach. Then again, so does HOT. The problem is not HOT the language but Heat the orchestration module.
Hm, here's what I can think of are the main advantages of TOSCA: 1. TOSCA is a standard with wide industry support. HOT isn't. The standard also includes a packaging format (CSAR). 2. The fact that TOSCA is models + schema in one language is a major advantage over HOT. Indeed TOSCA's power of validation is way, way beyond anything HOT can do. This extends to data types, which are fairly rich in TOSCA (but can be richer
-- see OpenAPIv3). TOSCA's new-ish support for profiles in 2.0 makes all of this even more powerful, as it allows TOSCA to be used for all kinds of orchestration domains. Indeed, a single service can be described at various levels in just one topology template
that imports multiple profiles. 3. TOSCA allows for custom integrations with subsystems via interfaces/operations/notifications. 4. TOSCA has many implementations rather than just one (well, I guess you can use HOT with Puccini...). Each implementation has different approaches to orchestration and integration. So, TOSCA is just more broadly useful than HOT. HOT for
the most part limits you to an OpenStack-based environment (though again you can extend it for your own custom subsystems). The loose specification meant that for a while TOSCA implementations diverged quite a lot, but with TOSCA 2.0 we hope to run a tighter
ship and increase interoperability. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]