[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] RE: updated operational model
Thanks Tal. From you email below weâre actually more on the same page that what it sounds like sometimes
😊 From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron Thanks Peter, There's almost too much to unpack here. I'll try to be as succinct as possible. I absolutely want us to address Day 2. I just don't think designing an orchestrator is the way to achieve that goal for TOSCA. And it's not the right thing for us to do as a group comprising companies that make orchestrators that sometimes
compete. I joined the TOSCA TC to design a language, not another product. Not sure where youâre getting the impression that weâre trying to design an orchestrator. We all share the same goal, which is to design a language. Of course, this language defines orchestration semantics (and has
done so since v1.0) that may not be useful for your target applications. In that case, you should feel free to not implement those as Peter suggested. Day 2 is hard. Not just for TOSCA, but for any orchestration scenario. For a service to truly be "fire and forget" (are you sure you really mean "forget" here? more on that below) it means that the Day 0 design should already have precise
information (rules) on how the service can change, and also why it would change (transition states). The key to this, in my view, is policies. And this includes rich policy types, included in the profiles, that exactly expose what rules are possible for the
specific domain or platform. I suspect that a true overhaul of TOSCA policies would have to wait for TOSCA 2.1 or beyond. It seems like far more than we can chew right now. Policy types are only useful if they can define associated policy semantics. Current policy grammar in TOSCA allows you to specify semantics using event/condition/action tuples (i.e. âimperative policiesâ). Unfortunately,
there are no examples in the spec of how these policies should be used. Instead, the spec gives examples of policies where the semantics of the policy are implied by the policy name (âScaling policyâ). Clearly these examples are entirely useless. I completely
agree that more sophisticated support for policy semantics is needed. But there are some high-level and useful things we can say right now that would also be true for a later version of TOSCA. 1) The normalized representations are the common ground of truth. It might be "late truth" (eventual consistency) or "early truth" (not yet instantiated), but that's the only way our operational model can make any kind of sense. Of course
they are persisted, Peter. I'm not sure how you understood that I was suggesting otherwise. I was specifically pointing out that the
database may already exist. Terraform is based around a powerful, cloud-aware, transactional db. Ansible has its generic "facts" and "inventories". Kubernetes has etcd. If you are using these but want to create yet another database, then that's up to
you. I'm not in the market for a new orchestrator-of-orchestrators at the moment. I'm interested in TOSCA as a common language for those I already have. TOSCA doesnât say anything about where topology representations are expected to be stored. TOSCA just expects them to exist.
2) Where do these representations come from? From the TOSCA perspective we can say that TOSCA generates
some of them. But we can expect others to come from other sources. Importantly, TOSCA doesn't necessarily "own them", even those that it generates. Who owns them? Sometimes it is the orchestrator -- e.g. a lifecycle manager for virtual machines, each
with a UUID, per your example. In other cases (in many cases) it is a controller. For example, in Kubernetes it is rare to create a Pod directly. Rather, one would create a Deployment. The Deployment owns a ReplicaSet, which in turn is the owner of the Pods:
it is the one that maintains the Pod IDs. And yet both Deployments and Pods are represented in etcd. They are "representations". How we model all this is up to us. We can create models for all of these representations, one node template for each. Or
we can decide on, say, a single higher-level "Compute" node template, which behind the scene has these several representations, with only the Deployment ID being necessary for grammatical association. (As I say it's "zero or more representations" per node
template.) Yes, topology representations can include data that were not created based on TOSCA templates as long as we understand that only those parts of the ârepresentation graphâ that have corresponding templates can be
managed using TOSCA. And Iâm happy to hear that we not agree that one can create multiple node representations from the same node template. 3) There's some limited, but important, Day 2 stuff in TOSCA already. A TOSCA attribute only makes sense in Day 2. That is why "forget", from "fire and forget", made me a bit uneasy. If it's truly "forgotten" then it's hard to see TOSCA's
operational model being applicable to anything beyond that first nanosecond of deployment. An attribute represents new state. Likewise, operations can only make sense in terms of some kind of event model, which is, again, new state. Of course the constraint
here is that we are still talking about the same node templates, but again the node representations (and their IDs) might change. We need to revisit this. Operations are not events. 4) Then there's the big changes: adding/removing nodes (and relationships) on Day 2. I'm interested in cloud native orchestration. So, yes, I emphasize that controllers would often be owning the representations and we should operate them
by providing them with policies. It seems you're interested here in explicit, manual changes. You mention changing TOSCA inputs in order to create topological changes, but actually TOSCA inputs allow for very little variability. Let's be even more radical
and consider that someone could manually edit the TOSCA YAML file and then want to make that change happen. That seems like a reasonable Day 2 action to me.
Yes, this is the scenario suggested by Peter where you would âupgradeâ a running service by applying an âupgraded versionâ of the service template to it. Perhaps it might make sense for us to discuss what it would mean to re-apply a TOSCA service template to an already existing deployment and how a diff would be calculated, for example how node template names are preserved. By the way, I
recommend looking at Terraform for inspiration, because this is exactly how its aggressively declarative state management works. This is exactly the problem stated by Peter. If Terraform can help guide us to a solution, we should absolutely pursue this. On Mon, Feb 14, 2022 at 2:00 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote: Thanks, Chris
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]