[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Follow up on the boundary definition section
Thought I will put down the discussed areas with some relevant example. Guess this can be picked up and will be useful to develop some thinking, scenario / approach.
Importantly, I was not sure how all the areas will exactly be tackled in TOSCA, for now I went by trying to classify as per Chris’s hint.
Happy weekend.
Cheers Saji From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers I think we need to start by clearly defining: 1.
Which ones of these are features of an orchestrator? 2.
Which ones represent external services that deployed services need to access (and as a result may need to be captured in a service topology) 3.
Which ones are representations of “service level guarantees” and likely need to be expressed through policies. There may be other categories as well. Chris From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Luca Gioppo Hi Saji, wellcome, I really like the lid you opened :D I really believe that ALL those things need to find adeguate modeling in the standard, either by finding the proper way to map them using the existing entities or by defining a proper new one.
I think, that it could be useful for all to treat each one as a separate issue so we can talk about them; for example licence keys are very different than billing system integration so I believe that we will come out with different solution
for the 2 problems (or I do not understand well one of the two and so is better to have a single thread for each).
Also even if the idea of Chris really got me I have now a concern after reading your mail.
The concern is this: - there are lots of external "virtual" systems that need/could need to be addressed, if we add to the topology a node to map that object we end up with lots of nodes just to map the internals of the orchestrator.
- a generic TOSCA writer guy would be a little scared to have to "map" all these things and draw all those relations and creating all those nodes. The reason for a boundary section was to briefly state the need for a component of the orchestrator.
Here, as correctly stated by Chris, we are setting constraints on the orchestrator: - this TOSCA file need an orchestrator able to do those things: scaling+monitoring + billing etc We can for sure think of the existance of different flavour of orchestrators. We could have a basic one just able to do deploy and than you are on your own, to the more sophisticated capable of offering to the customer many features (this is where all implementors compete). So maybe a section dedicated could be in the long run easier. Luca > _________________________________________________________________________ > >
> |
Attachment:
Service Boundary-Dependency 1.1.xlsx
Description: Service Boundary-Dependency 1.1.xlsx
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]