[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Groups - TOSCA Architectures and Language impact uploaded
|
Hi Peter, I believe this is what imperative (event/condition/action) policies were intended for, but based on my own experience trying to implement âclosed-loop automationâ using TOSCA policies, I agree there are extensions needed to the grammar
to make this work. Would you be interested in sharing your experiences with closed loop automation during one of our upcoming TOSCA TC meetings? Thanks, Chris From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Hi Tal, I am glad to hear that I must have misunderstood some of your comments last time, Tal. Letâs move ahead. Best regards, Peter P.S. Chris, you mention closed loop. That is a really interesting topic. We were struggling a bit with that for a little while, but now we have it fully supported and performant. We did find a need for some extra
functions to handle threshold and severity mappings to get it fully integrated into our language. And of course there needs to be event handling and an ability to express different types of corrective actions. Has there been any previous work in the TOSCA
group on this? From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers Thanks Peter, we should absolutely get agreement on scope so we can avoid rehashing these discussions in the future. It seems to me that TOSCA could be used in all three phases of service lifecycles:
It is my impression that we currently have only two points of view of where TOSCA should be used:
I havenât heard anyone on the team express an opinion that TOSCA should be used for Day 0 and Day 1, but not for Day 2.
It might be useful to formalize which TOSCA features are necessary for which phases of service lifecycles, and then figure out which ones of your architectures are required to be able to provide those features. That might be a useful exercise
for the next couple of Language Ad-Hoc meetings. Based on this outcome of that exercise, we can then decide if it is desirable to split up the Language Ad-Hoc into multiple sessions.
Thanks, Chris From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Hi all, I think there are some of us who want to discuss standardization and language features that only make sense in larger architectures, and some who work in contexts where such topics are irrelevant. This becomes
a question of scope and charter for the TOSCA standardization. Does having a minimal useful architecture necessarily imply that the TOSCA language may not have:
Perhaps the minimal language and minimal features be a separate group from ad-hoc groups working on larger contexts? We could then have separate ad hoc groups defining language and semantic extensions for inventory
and catalog based orchestrator architectures separate from the minimal language group. One of the objections I heard the last time was, that TOSCA should only impose conformance requirements on orchestration of day-1 deployment, and that day-2 maintenance of services should be explicitly scoped
out of TOSCA work. There are many orchestrators out there that pre-date TOSCA and the argument was, that after day-1, any requirements for day-2 maintenance in TOSCA context would be too demanding for such orchestrators to comply to. If I were selfish, that would be perfect for HPE, because we do happen to have a very strong orchestrator that predates TOSCA. The problem I face is that some real-life users out there are not really satisfied
with that approach because they expect to be able to continue to see their services âthrough the glassesâ of their TOSCA model. So to be extremely selfish, I would want the TOSCA standardization to explicitly and publicly announce that users of TOSCA must
not expect such day-2 use of TOSCA, and failure by providers of TOSCA Orchestrators to provide day-2 service management is
not a failure of the providers to comply with the standard. But do I want TOSCA to succeed, and I believe that the outcome above would effectively kill TOSCA in Telco contexts. (I acknowledge that there are of course non-Telco uses of TOSCA) So although there are minimal uses of TOSCA out-there that do not require day-2 features of TOSCA, I do see it as essential for the success and survival of TOSCA that such matters are not ignored. Whether such
a scope requires a separate Ad Hoc group with mandate to define extended language features, or whether that scope can stay within the Language Ad Hoc group, I donât know â but I hope we can settle on a way to do this that avoids further discussions of the
relevance. And again â if the consensus ends up being that day-2 is completely out-of-scope for TOSCA, then that is definitely the easiest for me. Just my 5 cents. Peter From: Chris Lauwers [mailto:lauwers@ubicity.com]
Hi Tal, Yes, we should continue to discuss this. In my opinion, there is a huge difference between âfind me something that already existsâ vs. âcreate me something newâ. The âcreate something newâ may have cost implications, in which case the service
designer will want to control the creation explicitly. I donât believe that an orchestrator should ever go and create something that a service designer has not explicitly asked for.
Letâs continue to discuss during our upcoming language meetings. Thanks Chris From: Tal Liron <tliron@redhat.com>
On Tue, Nov 17, 2020 at 1:51 PM Chris Lauwers <lauwers@ubicity.com> wrote:
I think these are often useful but not absolutely required and indeed there can be twists.
Of course, as you know I disagree with the "dangling requirement" feature, and in my view these two features are essentially identical for the orchestrator in that they allow for a node to be "provided" from somewhere else. The difference
in #2 is a TOSCA grammatical feature, allowing a TOSCA service template to explicitly "provide" a node. My point is that how exactly the orchestrator "provides" is beyond the scope of TOSCA. It
could be an inventory, but it doesn't have to be. The orchestrator could simply look for existing resources in the cloud, whether they were created via TOSCA or not, thus the cloud itself becomes the inventory. And of course an orchestrator could also
provision such implementations itself on-demand. As for catalogs, it does seem that if a service template does substitution then of course the orchestrator would have to know of it and thus it must be "somewhere". But, again, it doesn't have to be in a catalog.
For example, a bunch of CSARs can be provided at once to the orchestrator, to be used just at the moment of the day 1 instantiation, and they do not necessarily have to live in a catalog. My one concern here is that inventories and catalogs involve state and and state management, but there is a lot of room for orchestration that is as stateless and lightweight as possible. I still think the minimal architecture is functionally
sufficient for TOSCA orchestration. My second concern is not to scare off potential consumers of TOSCA, who might look at a complex architectural diagram and worry about the amount of effort they would need to put in in order to make use of TOSCA. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]