Hi Peter,
You're mostly right as to my intent, though I wanted to take even a further step back than that.
I don't want to make any assumptions as to where, how, why, and how often events come, because I know we want to of course support all of cases. You can call it "managing a topology over time", but I'm addressing something narrower: this is about how attributes change. So I'm even more specifically talking only about mutable data, which has always been part of TOSCA but has always been rather fuzzy.
In particular I want to get us out of thinking only about scripts. Sure, scripts and playbooks and workflows and are still used a lot in devops, but our clouds keep getting more and more declarative, more and more intent-oriented, more and more asynchronous, and more and more event-based. There's no "create" script for Kubernetes, at least none that is exposed to users. You declare your resource. At some point you expect it to come up. And you might want a way to get the current status in TOSCA (e.g. an IP address). This is not about "managing a topology over time" but about the fundamental resource modality in Kubernetes.
This leads us to think more abstractly about "Day 1" vs. "Day 2". Let me put this way: when does Day 1 end, exactly? If you're in the script/playbook/worklfow paradigm then it's very clear: when the workflow finishes successfully. But in the declarative cloud native world the resources will be managing themselves, autonomously and independently. So does "Day 1" end when the state matches your intent? Or when you finish running tests that prove that it works? And what if it works for 5 minutes and then fails, are you still in "Day 1" or is this considered ongoing "Day 2" maintenance? We're encouraged to think about all of these together, as events that can happen either in Day 1 or Day 2, or maybe it doesn't quite matter which day it is.
(Now, changing the topology is indeed a different issue. For TOSCA, at least, the Day 1 topology is a very well defined concept. I am talking about cloud modality here.)
Of course you can enforce your own modalities on top of anything by adding layers of state. That's what a lot of classic orchestrators do, e.g. OpenStack Heat.
Argo CD is an example for K8s -- it allows for "workflows" by exactly letting you implement "event handlers" that in turn create or modify resources. I'm always, though, more interested in having TOSCA represent the existing paradigms, in addition to allowing users to create new paradigms. As I always point out, we already have orchestrators. If TOSCA requires us to build new kinds of orchestrators then it's going to be very hard to gain adoption. We want it to be able to glue together the systems we already use. So my point here is to define a conceptual event model that could, potentially, represent anything. And then have the grammar support that.
I'll add another point I forgot to make during the meeting today -- I intentionally avoided talking about transactionality. It's possible to imagine a system in which multiple events for the same node are handled at the same time. In that case, what would happen if they keep trying to change each other's shared mutable data? Of course transactions are a huge barrier for scalability. So, at least in a minimal scenario they don't have to be included. They don't change the conceptual model itself. But advanced orchestration systems might allow each event context its own transactional view of the topology. Or have some other higher level management of topology changes.
Iâm redistributing Peterâs message since he is unable to send to the tosca list directly.
Â
Â
Hi Tal,
Â
Thank you for the great slides today.
Â
Let me try to see if I understand you correctly â I probably donât.
J
Â
When we move away from the strict modality of lifecycles involved in topology *creation*, what I see is rather one of the Orchestration *managing* a topology over time.
Â
So âTOSCA Orchestrationâ is not just a question of creating the topology, so that when done, there would be nothing more to do.
Â
Instead, each Node and Interface of a node may hold multiple state-dimensions, some of which could be related to creation, others to maintaining other aspects of the infrastructure associated with the node representations.
Â
At least that is what I am hearing, when you talk about an on-going relationship between the Executor Context and the Node/Interface scopes, in which Events may keep coming for hours, days, months while the topology
is being *maintained*.
Â
Does this capture some of your thinking, or am I misunderstanding you?
Â
I mentioned, and you kind of nodded, that we might even consider the possibility that Events may even drive the Resolver to mutate the Representation Graph â or is that out-of-scope? Of course if that can happen,
then it will blur the distinction between what is mutable and immutable.
Â
Best regards,
Peter
Â
P.S. @Chris â I am still unable to send to the TOSCA distribution list â can I ask you to distribute, please?
Â
Â
Â
- Continue the discussion about the operational model for events and notifications
- Using Talâs contribution to guide the discussion
Â
Thanks,