OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (TOSCA-207) postconfigure operation on Standard operation should be renamed in poststart


    [ https://issues.oasis-open.org/browse/TOSCA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52640#comment-52640 ] 

Matthew Rutkowski  commented on TOSCA-207:
------------------------------------------

During the YAML WG call additional issues were captured that go beyond the initial proposal for a "rename".

Here is my summary:
1)  general agreement "postconfigure" is misleading name, "poststart" makes sense from a tactical perspective (Matt would like to change 

2) Derek questioned need for function as we can "override" start operation to achieve use case <or> use relationship operations to inject external information.  In general, revisited original use case (inject user or other data in DB after started, before general available to other components/users). Matt asked Derek to capture original use case and describe how it could be done using today's spec. and NOT postconfigure.
2a) Matt indicated the concept of "override" (and calling a parent's scripts as part of the override) is NOT in spec. and has never been discussed IF would be the means to preserve granularity of operational scripts (and avoid rewrites every-time a parent type's scripts changes).  Matt indicates this would be yet another issue.  
2b) It was also discussed that Postconfigure (as it exists today after start operation) also is confusing since most postconfigure use cases should be "run once".   Matt indicates this is a problem even if we override start operation for "one time" configuration and we clearly need use cases in the spec. to decribe our approach.  These new issues  IMO fall outside v1.0 time constraints.  

!!!Our only option may be to rename Postconfigure or delete it for v1.0 timeframe.!!!

3) Derek then saw option #3 and indicated we may still need a Postconfigure operation, but after any (new) external configure operations as a "last word" for the Node to address any changes it has on-top of external changes. Matt indicated this would be a new issue.  Matt asked for a use case

> postconfigure operation on Standard operation should be renamed in poststart
> ----------------------------------------------------------------------------
>
>                 Key: TOSCA-207
>                 URL: https://issues.oasis-open.org/browse/TOSCA-207
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Bug
>          Components: Profile-YAML
>            Reporter: Luc Boutier
>
>   postconfigure:
>     description: Standard lifecycle post-configure operation (post-start)
> That will be much more clear (simple if it was called poststart as this is actually a poststart operation).



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]