[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-3) Grouping Element for Policies
[ http://tools.oasis-open.org/issues/browse/TOSCA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30010#action_30010 ]
Paul Lipton commented on TOSCA-3:
----------------------------------
A detailed discussion on this topic happened at the March 29 meeting. Chat room summaries are below:
[12:25] scribe: moving on to TOSCA 3
[12:27] scribe: I meant straw poll above, sorry for the typo
[12:28] scribe: Frank summarizes TOSCA 3
[12:29] Paul Lipton (co-chair) 1: np, thanks
[12:31] scribe: focusing on <PolicyAttachement> element
[12:34] Tobias Kunze (Red Hat): I agree with Paul's perception
[12:34] scribe: Paul is concerned about market resistence to WS* specs
[12:35] Mike Edwards: where is policy attachment discussed in the proposal document??
[12:35] scribe: Paul is asking if there are alternatives to express policies
[12:36] scribe: Frank: using <PolicyAttachement> would tie us to WS* specs
[12:38] scribe: Frank is offering to change proposal to include more general policy element
[12:38] Steve Winkler (SAP): From our charter: The ability to annotate the various elements that define the topology of a Service Template with policies that influence use of instances of a Service Template. Such annotations could leverage a wide range of policy languages (e.g. WS-Policy [2], KaoS [3], etc.).
[12:39] Paul Lipton (co-chair) 1: Paul (non-chair) concern about pulling in heavy-weight specs.
[12:39] Paul Lipton (co-chair) 1: Paul (non-chair) interest in lighter-weight grouping mechanisms.
[12:40] scribe: Derek: policies should be first class citizens
[12:42] Derek Palma (Vnomic): policies should be standalone elements at the root level so they can exist on their own.
[12:44] Matt Rutkowski (IBM): Policies do indeed to seem to be top level entities that we reference in plans and other places in text of spec. it seems we need to consider policy relationships at template level, node level and perhaps in relation to yet-to-be-named entities.
[12:44] Matt Rutkowski (IBM): and that this "attachment" is a type of relationship
[12:45] Matt Rutkowski (IBM): and as we discuss relationships that we should consider how policies relate to any entity type
[12:46] Derek Palma (Vnomic): When we say we want to "support policies generically" it means we must support "targeting" semantics which are required by each kind of policy. This will require an appropriate structure in the xml documents.
[12:47] Efraim - Scribe (CA) morphed into Efraim - (CA)
[12:47] Matt Rutkowski (IBM): e.g. perhaps there may exist (security) policies associated with types of deployment artifacts
[12:47] Mike Edwards: would it not make more sense for a given element to reference one or more policies by means of something like @policy attribute?
[12:47] Matt Rutkowski (IBM): Paul also expanded the notion that there may be "policy types" much like "node types" which I had not considered
[12:48] Matt Rutkowski (IBM): Thats one means Mike that has precedence
[12:48] Mike Edwards: rather than the <AppliesTo/> in the policy grouping element...
[12:48] Matt Rutkowski (IBM): however since we have described "relationship" as a TOSCA entity we should perhaps leverage that as it may give us more compositional options
[12:49] Matt Rutkowski (IBM): rather than tie it to each and every entity that we create
[12:49] Matt Rutkowski (IBM): (define)
[12:51] anonymous morphed into John Wilmes (Progress)
[12:51] Tobias Kunze (Red Hat): Propose to adhere to our spirit of being accomodating with existing standards while not being prescriptive about it (think BPMN). This means I propose to provide for the concept of "policy" to be expressed at the root level, possibly in form of an embedded WSP fragment, and then to provide a generic way to connect ("attach") elements of the template (e.g. policy) to other elements (e.g. nodes). I am proposing this in particular from a YAML perspective, which seems to want to be as simple as possible. I also believe that this proposal is largely in line with the other opinions laid out here.
[12:52] scribe: Frank will sumarize the comments and link them to TOSCA 3
[12:52] Matt Rutkowski (IBM): "attach" could be a "relationship" type, but perhaps there is a better semantic; the term attach provides no semantics for understanding the true dependency on the policy
[12:52] Paul Lipton (co-chair) 1: From the charter: The ability to annotate the various elements that define the topology of a Service Template with policies that influence use of instances of a Service Template. Such annotations could leverage a wide range of policy languages (e.g. WS-Policy [2], KaoS [3], etc.).
[12:53] DaleMoberg: ws-policy was to reference a subject at some level of service description (as modeled by wsdl) The policy attachment showed how to relate policies to specific level of wsdl descriptions of services... So if service deployment needs to go beyond interface aspects of services to quality of service aspects (such as security) we need a general way of relating services and policies...
[12:55] Matt Rutkowski (IBM): Policy deserves to be "typed" IMO and subclassed going forward
[12:55] Derek Palma (Vnomic): absolutely
[12:56] Derek Palma (Vnomic): and the targets of the policies also have to be typed
[12:56] Matt Rutkowski (IBM): +1 Derek
[12:56] Derek Palma (Vnomic): policies must belong to a type system
[12:57] DaleMoberg: Would policy "typing" follow policy formats? (xacml vs ws-policy vs sbvr ...) what is the basis of the typing?
[12:57] Matt Rutkowski (IBM): functional typing not bindings
[12:58] Matt Rutkowski (IBM): functional e.g. security, operational, etc.
[12:58] DaleMoberg: thanks matt
[12:59] Matt Rutkowski (IBM): BTW good to see you Dale
[13:01] DaleMoberg: always happy to add my confusions
[13:01] Matt Rutkowski (IBM): I agree that a policy entity could have an attribute that references a format, but an entity needs to exist to model
[13:02] scribe: Short break in the technical discussion to make sure that this policy discussion does not create an issue with our charter. Conclusion: no issue with charter
[13:04] Efraim - (CA): We need to define what are the use cases for using policy in TOSCA
[13:05] Matt Rutkowski (IBM): we need to refine any use case with more of the well understood entities before we can "add" policy entity scenarios
[13:06] Derek Palma (Vnomic): all roads lead back to use cases
[13:06] Efraim - (CA): yes
[13:06] Matt Rutkowski (IBM): I suggest we need to focus more on developing the 2-tier use case presented last week and build these discussions around it
[13:06] Derek Palma (Vnomic): we need a complete entity model (node/types, relations, and properties interpreted by policies)
[13:06] Frank Leymann (IBM): What does "interpreted" mean, Derek?
[13:07] Matt Rutkowski (IBM): +1 Derek
[13:07] DaleMoberg: it would be nice to have a tosca managed service with a policy of using single sign on based on oauth, e.g.
[13:08] Matt Rutkowski (IBM): OMG Dale, come back in a year /grin
[13:08] Marv Waschke (CA): A policy use case I have heard lately: this service cannot be instantiated without an approved budget.
[13:09] Matt Rutkowski (IBM): Again, policy seems to be a entity we need to model eventually and have already referenced it in spec. text. We DO need to address the basic TOSCA model first
[13:10] anonymous morphed into Allen Bannon
[13:10] Mike Edwards: hmm, not sure you can automate that one Marv
[13:10] Frank Leymann (IBM): Typical implementations have a plug-in mechanism for policy-assertions. a pipline of these plug-ins process a policy alternative...
[13:11] Tobias Kunze (Red Hat): Another use case are performance or resource reservations
[13:11] Matt Rutkowski (IBM): I think that discussing policies in terms of assertions is too soon, we need to agree that it deserves to be modeled
[13:11] Tobias Kunze (Red Hat): Performance requirements were a prominent concern at the OASIS Beijing meeting this week
[13:12] Marv Waschke (CA): I think the accounting case could be automated with a plug-in into some kind of work flow.
[13:14] scribe: Proposal Frank: Open new issue to discuss policies
[13:14] Matt Rutkowski (IBM): The trend is that these TOSCA issues are hitting arguments that can not be analyzed without agreement on the base entity model and relationships. IMO the use case we have from Derek will help give us commong ground for discussion and to build from in the future
> Grouping Element for Policies
> -----------------------------
>
> Key: TOSCA-3
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-3
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Improvement
> Components: Spec
> Reporter: Frank Leymann
> Assignee: Frank Leymann
>
> A grouping element is missing that allows to assign policies to collections of node templates. For example, a policy specifies that the energy consumption of instances of a subset of node templates must not exceed a certain threshold; this is difficult to achieve by specifying a (lower) threshold of energy consumption to each member of the subset. Another policy specifies that instances of another subset of node templates must be of a certain availability class. These subsets might have a non-empty intersection.
> We have a group element already (i.e. <GroupTemplate>) the purpose of which is to define "subtrees" of topology templates for reuse. This purpose is different from the proposed grouping element for policy assignments.
> For example, Group Templates are instantiated (specifying their minimum and maximum number of instances) while the proposed grouping element for policy assignment is not separately instantiatable. The current spec does not explicitly exclude intersecting Group Templates, but it seems to be unclear what that means: E.g. a node template in two Group Templates is target of one relationship type the specifies cascading deletion, and target of another relationship type with no cascading deletion - what is the resulting behavior? Similarly, a node template is in two Group Templates each of which specifies a maximum number of instances - do the number of instances of the node templates in the intersection sum up? N.B.: Maybe a clarification of this is worth a separate issue....
> Thus, a new language element for collective policy assignment seems to be justified.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]