raw chatlog day 3 april 2013 f2f

[Martin Chapman <martin.chapman@oracle.com>]

Anish Karmarkar ping
Scribe (Tom): Scribe- Tom Rutt
Scribe (Tom): Topic: New Issues
Scribe (Tom): Issue 58 - Justification for the common "created attribute is unclear
Scribe (Tom): Anish: why is created date more important than last modified date?
Scribe (Tom): Adrian: It created more problems to have it than to remove it as common attribute.  Actually Last Modified is more important in many cases.
Scribe (Tom): Jacques:  a facility for logging would cover the case for created date.  There is no use case for having a created date attribuge.
Scribe (Tom): Adrian moves to open Issue 58, Anish seconded.
Scribe (Tom): Panagiotis:  I think that last modified is more important.
Scribe (Tom): Adrian moves to ammend that this issue should be opened as P3 Issue.  Anish seconded ammendment.  No objection to ammendment.
Gil: Last-Modified is an HTTP header - not clear we need to put redundant info in our model
Scribe (Tom): No objections to ammended motion.  Issue 58 opened as P3 issue.
Scribe (Tom): Adrian: content negotiation in HTTP, is enabled by a last modified header in HTTP.  We could require the last modified header as a way to resolve this issue.
Scribe (Tom): Anish: we should be careful to overspecify the use of http in this spec.
Scribe (Tom): Adrian: since most REST protocols are underspecified, we should consider adding more guidance.
Scribe (Tom): Issue 59:  Inconsistent definition of link attributes to point at templates used to instantiate resource types.
Scribe (Tom): Anish:  There are differences, assembly always has a template, but components do not always need to have a template.
Scribe (Tom): Anish moves to open Issue 58 with priority P3, and assign to Tom, seconded by Tom
Scribe (Tom): Anish: The instantiated from template attribute could be optional for components, but it is always there for Assembly.
Scribe (Tom): No objection to open Issue 59 as P3.
Scribe (Tom): Issue 60: ApplicationComponentCapability is not linked by any resource type.
Ashok Malhotra (Oracle): Why not pointed to from Application Component?
Scribe (Tom): Anish: perhaps we could just remove this resource.
Scribe (Tom): Tom moved to open Issue 60 as P2, Adrian Seconded.
Scribe (Tom): No objection, Issue 60 opened as P2, with Gil as owner.
Scribe (Tom): Camp 61: Camp is vague about which HTTP methods each resource supports.
Scribe (Tom): Gil moves to open Issue 61 as P2 with Gil as owner, Adrian seconded.
Scribe (Tom): Adrian: we could ship without this, but it would be better to include this in the spec.  That is why P2 is appropriate.
Scribe (Tom): Anish: we could have a section with a small table.
Scribe (Tom): No objection, Issue 61 opened as P2, with Gil as owner.
Scribe (Tom): Gil: we should clearly deliniate what http methods a resource must support, but have no additional method support restrictions for resources.
Scribe (Tom): Gil: However, we might want to have some resource types that have a GET only restriction.
Scribe (Tom): Panagiotis:  What happens if you do a put on a get only resource?
Scribe (Tom): Anish:  A concise table would make this more readable.
Scribe (Tom): Tom: we should try to avoid negative testing assertions that the resource should reject non mandatory methods.
Scribe (Tom): Topic: Planning and milestones
Scribe (Tom): End March - Deadline for new P1 issues
Scribe (Tom): End May - Start 1st PR
Scribe (Tom): End July - All issues closed, 2nd PR
Scribe (Tom): End August - Start CS ballot
Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48314/CAMP%20sched.pdf
Scribe (Tom): Anish: rather than a deadline for P1 issues, after this F2F we need to raise the bar for accepting a new P1 issue.
Scribe (Tom): Anish: I support raising the bar to require support of more than 2/3 of TC to accept a new P1 issue.
Scribe (Tom): Duncan:  Any issues discovered during interop need to be dealt with.  However we should be careful to avoid scope creep thru accepting new issues.
Scribe (Tom): Martin: we could have a last call date after which no new issues will be accepted without a large super majority.
Scribe (Tom): Adrian: we need at least one more meeting before we have the last call for P1 issues.
Scribe (Tom): Adrian: all P1 and P2 issues need to be closed out before shipping spec, some P3 issues can be deferred.
Scribe (Tom): Anish: Criteria for start 1st PR is closing all P1 issues.  Criteria for 2nd PR is all V1.1 issues closed.
Scribe (Tom): Anish: we should have an interop event in this schedule.
Scribe (Tom): Adrian: test assertions may bring up bugs, resolving such bug improvement issues would be critical.
Scribe (Tom): Martin: some persons but might be another person's improvement.  We should treat all issues with the same criteria.
Scribe (Tom): Anish: for PRs we should decouple the TA spec and the base spec.  However we need the TA spec ready before a target date for interop.
Scribe (Tom): Jacques: We should have the TA doc ready for review during the 1st PR for the main spec.
Scribe (Tom): Martin: does main spec reference the TA spec?
Scribe (Tom): Anish: we could put either in non-normative refs section, or on the cover page as "related spec" url
Scribe (Tom): Anish: we need to put in dates for the TA doc in the timeline
Scribe (Tom): Anish: June F2F, if during Public review, could focus on implementation/interop activities.
Scribe (Tom): Martin: I do not think we should hold up the 1st PR because the TA doc is not complete.  We can fill out the TA doc during the 1st PR for the base spce.
Scribe (Tom): Gil: I have a concern that end of MAY for 1st PR is, under assumption that the spec is complete, is unrealistic.  End of June is more realistic goal.
Scribe (Tom): Anish: the 1st PR should be there to get feedback from the general community on the spec.
Scribe (Tom): Martin: I think the end Aug CS ballot is the most unrealistic.
Scribe (Tom): Anish moves we have a 1st PR at end of June, with a 1st PR for TAs one month later
Anish Karmarkar: For the TA document 1st PR is end of June and all issues closed 2nd PR is end of Aug
Scribe (Tom): Seconded by Gil
Scribe (Tom): Jacques: need to consider maximizing the PR feedback.  I am concerned about how much attention people will give to TA spec if the main spec has already been reviewed.  I would strive to have the TA spec reviewed at the same time as the base spec.
Scribe (Tom): For interop could be done with the TAs evaluated using human eyes, rather than test tools.
Scribe (Tom): Jacques: I would like to ammend this motion to more closely synchronize the TA 1st PR with the base spec 1st PR.
Scribe (Tom): Duncan: pushing the 1st PR back to end of June will have a knock on effect to push everything else out.  However this would give a June F2F a greater importance as a focal point.
Scribe (Tom): Martin: moving everything out by one month is disastrous.
Scribe (Tom): Clarification: motion on table is to have TA spec 1st PR end of june, and all issues closed second PR at end of august.
Jacques (Fujitsu): ammend Anish motion: 1st TA PR to be initiated sometime between 1st PR of main specification (end May) and end of June.
Alex Heneveld (Cloudsoft): please confirm:  1st PR for spec _remains_ at end of May
Duncan Johnston-Watt (Cloudsoft): @Alex - That is _now_ my understanding
Scribe (Tom): Alex seconds Jacques motion.
Alex Heneveld (Cloudsoft): confirming:  the motion I second is that "1st TA PR initiated sometime between 1st PR of main spec and end of June"
Duncan Johnston-Watt (Cloudsoft): What we are discussing is an amendment to the current timeline to add a deadline for 1st TA PR that is end of June
MarkCarlson: Keep in mind this a goal setting exercise. We can change our minds at anytime in the future based on circumstances.
Duncan Johnston-Watt (Cloudsoft): And a second amendment to the timeline to add a second deadline for all TA issues to be closed by end of August
Anish Karmarkar: @alex 1st PR for spec does remain end of may regardless of the main motion or amendment
Duncan Johnston-Watt (Cloudsoft): ... so that a second TA PR can be initiated
Scribe (Tom): Clarification the ammendment is "1st PR for TA issued by the end of June"
Scribe (Tom): No objections.
Duncan Johnston-Watt (Cloudsoft): +1
Scribe (Tom): Amended motion" 1st PR for TA issued by end of June.
Scribe (Tom): No objection, motion passed.
Gil: have we stop wasting time?
MartinC : maybe
Scribe (Tom): Martin: is it feasable to have an implementation interop by the end of June?
Scribe (Tom): Anish: we should tailor the next interop to focus on implementation
Scribe (Tom): Alex: since interop will bring up new issues, be should have it between June and end of July.
Scribe (Tom): Adrian: suggest Interop sessions July 8 and 9 with regular TC conf call on July 10 to discuss results from inerop.
Adrian Otto (Rackspace): yes
Gil: "CAMP Hack"
Scribe (Tom): test
Scribe (Tom): Action item: Oracle to investigate hosting interop in Broomfield CO July 8 and 9.
Scribe (Tom): July 8, 9 , 10 with con call on 10th.
Scribe (Tom): Action item: Rackspace to investigate hosting interop July 8, 9, 10 around Colorado/Texas area.
Scribe (Tom): Action Item: all members to investigate hosting July 8, 9, 10 in colorado area.
Scribe (Tom): Topic: Issue list review
Scribe (Tom): Martin: 8 P1 issues
Scribe (Tom): Martin: issues 45 and 56 should have proposals from the editors with high priority
Alex Heneveld (Cloudsoft): discussion -- Issues 4, 45, and 9 are the high-effort ones.  (PDP, normative statement overhaul, and sensors+effectors)
Scribe (Tom): As group we need to resolve Camp 4
Gil: Can the Chair give me control of WebEx ?
Scribe (Tom): Camp 4 Adrian
Scribe (Tom): Camp 3 Anish
Scribe (Tom): Camp 9 Alex
Scribe (Tom): Adrian: owners  of P1 issues focus with priority, 4, 9, 56, 45, 55, 30, 3, 17
Scribe (Tom): Break for Lunch
Adrian Otto (Rackspace): https://oracleconferencing.webex.com/oracleconferencing/j.php?ED=229742602&UID=0&PW=NZGEwNTYzYWRm&RT=MiM0
Duncan Johnston-Watt (Scribe): Resumed - Topic PDP
Duncan Johnston-Watt (Scribe): Discussing https://gist.github.com/ahgittin/5311818
Duncan Johnston-Watt (Scribe): Drilling down on 2-cluster.json.txt
Duncan Johnston-Watt (Scribe): Now looking at more complex example 3-fairly-advanced-withDB-and-VM-config.json.txt
Duncan Johnston-Watt (Scribe): Introducing notion of "fulfilment"
Duncan Johnston-Watt (Scribe): Gil: What is purpose of AssemplyTemplate lined 5-12?
Duncan Johnston-Watt (Scribe): Alex: Illustrative in this example
Duncan Johnston-Watt (Scribe): Highlighting lines 41-42 dependency injection
Duncan Johnston-Watt (Scribe): Alex: Borrowing from TOSCA concepts - adding fulfilment
Duncan Johnston-Watt (Scribe): Alex: PDP could just be a reference to TOSCA, Checkmate, CloudFormation or some other descriptor
Duncan Johnston-Watt (Scribe): Martin: PDP has to conform to a format
Duncan Johnston-Watt (Scribe): Alex: Valid issue but one that also affects output of server
Duncan Johnston-Watt (Scribe): Jacques: Is fulfilment just a link to a requirement?
Gil: Jackson or GSON would have no trouble parsing Alex's DP (camp.json)
Duncan Johnston-Watt (Scribe): Gil: ACT generates AC and PC requirements; PC requirement fulfilled by PCT (Picture)
Duncan Johnston-Watt (Scribe): Alex has posted comment https://gist.github.com/ahgittin/5311818#comment-811570
Duncan Johnston-Watt (Scribe): Gil: Do we need ACT -> PCT link?
Duncan Johnston-Watt (Scribe): Issues being raised will be addressed/discussed as part of proposal
Duncan Johnston-Watt (Scribe): Adrian: If we aren't an orchestration spec why are we describing what is inside an application?
Duncan Johnston-Watt (Scribe): Gil: Minimalist approach
Duncan Johnston-Watt (Scribe): Alex: This is explicit wiring only
Alex Heneveld (Cloudsoft): for reference:  https://gist.github.com/ahgittin/5311818
Duncan Johnston-Watt (Scribe): Alex: without fulfilment you can only do toy examples
Duncan Johnston-Watt (Scribe): Gil: that's not necessarily an issue
Duncan Johnston-Watt (Scribe): Alex: Suggest we let people digest this and review at next call
Duncan Johnston-Watt (Scribe): Alex: Happy to write up full proposal if TC thinks this valuable having reflected on it
Duncan Johnston-Watt (Scribe): Adrian: There is merit in this or something like it (Adrian - please elaborate)
Duncan Johnston-Watt (Scribe): Gil: What fulfilment teaches us is that abstract config/wiring has little or no value without this additional information (paraphrase)
Duncan Johnston-Watt (Scribe): Gil: Declarative
Duncan Johnston-Watt (Scribe): Gil: No ordering; no attempt to come up with implementation
Duncan Johnston-Watt (Scribe): Adrian: Three buckets: PDP Format (CAMP-4); PDP API (CAMP-3); PDP Deployment Description / Meta-DSL
Duncan Johnston-Watt (Cloudsoft): Alex/Duncan exit stage left with elephants
MartinC - webex: AOB: none
MartinC - webex: meetign adjourened