[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: raw notes day 1
Jacques (Fujitsu): icecream
Alex Heneveld: if anyone needs git access at fujitsu:
Alex Heneveld: https://help.github.com/articles/using-ssh-over-the-https-port
Alex Heneveld: (default git access is blocked)
Jacques (Fujitsu)1: Going on lunch break ... (right now 12:30), back in 1 hour (1:30pm UK time)
Alex Heneveld: https://docs.google.com/document/d/15GQYc6MEyj2kn-zps6WidEwTdsJs6s7ObjHMmNH8lZc/edit?usp=sharing
Alex Heneveld: btw https://tools.oasis-open.org/issues/browse/CAMP-80 is where we discuss PDP/DP by-ref by-value
MartinC1: Prepping for the formal call:]
MartinC1: GOAL of the F2F: Ensure we have directions/resolutions for all P1s and all PR comments, and as many P2 issues as we can
Intro:
Scribe appointment: call for volunteers starting from top of the list [1]
Roll Call
Agenda approval
Minutes:
9th October 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00069.html
Action Items:
Jacques Durand: Coordinate Editing team meeting to discuss the challenges document referenced in CAMP-83.
Gilbert Pilz: Get input from Martin (email) on what publications he thinks we should release between our PRs.
Administrivia:
Status:
Timeline: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=50034
Current open issues: 82 in total; 7 P1, 68 P2, 7 P3.
Editing Team Update:
New Issues:
Issue Discussion:
Triage of PR issue:
Adrian: 85-97
Martin: 98-115 https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00034.html
Tom: 116-130
Ashok: 131-141 https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00013.html
https://tools.oasis-open.org/issues/browse/CAMP-83 Labeling of Normative Statements is incomplete (aka overhaul V2)
new proposal from Gil in JIRA
https://tools.oasis-open.org/issues/browse/CAMP-29 "Application Component" and "Platform Component" should be collapsed into a single "Component"; "Application Component Template" and "Platform Component Template" should be collapsed into a single "Component Template"
Proposal in JIRA
https://tools.oasis-open.org/issues/browse/CAMP-44 Clarify resource type issues and API
Proposal in JIRA
AOB:
-----
[1] Scribe rotations:
Roshan, Agrawal (1)
Yendluri, Prasad (2)
Krishna Raman (3)
Otto, Adrian (6)
Johnston-Watt, Duncan (3)
Malhotra, Ashok (3)
Carlson, Mark (4)
Karmarkar, Anish (5)
Heneveld, Alex (4)
Byreddy, Bhaskar Reddy (3)
Rutt, Tom (4)
Pilz, Gilbert (10)
Durand, Jacques (6)
Behrens, Michael (2)
MartinC1: Under issues discussion lead with CAMP-145 https://tools.oasis-open.org/issues/browse/CAMP-145
Ashok Malhotra (Oracle): Martin is the phone line open?
Mark Carlson: Phone quality is poor. Humm on the line. Can't hear anyone clearly...
MartinC1: yes ashok
Adrian Otto (Rackspace)1 morphed into Adrian Otto (Rackspace) [scribe]
Adrian Otto (Rackspace) [scribe]: We solved the voice bridge trouble.
Adrian Otto (Rackspace) [scribe]: 64% of voting members in attendance, meeting is quorate.
Adrian Otto (Rackspace) [scribe]: Topic: Agenda Review
Adrian Otto (Rackspace) [scribe]: no opposition raised to proposed Agenda
Adrian Otto (Rackspace) [scribe]: Minutes for Oct 9th 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00069.html
Adrian Otto (Rackspace) [scribe]: Motion: m=Gil s=Anish
Adrian Otto (Rackspace) [scribe]: no objections, Minnutes accepted
Adrian Otto (Rackspace) [scribe]: action item for Gil OVE
Adrian Otto (Rackspace) [scribe]: Topic: Aministrivia
Adrian Otto (Rackspace) [scribe]: Current open issues: 82 in total; 7 P1, 68 P2, 7 P3.
Adrian Otto (Rackspace) [scribe]: Topic: Editors Update
Adrian Otto (Rackspace) [scribe]: WD25 released
Adrian Otto (Rackspace) [scribe]: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51007/camp-spec-v1.1-wd25.doc
Adrian Otto (Rackspace) [scribe]: Topic: New Issues
Adrian Otto (Rackspace) [scribe]: no new issues from last week to process
Adrian Otto (Rackspace) [scribe]: Topic: Issue Triage
Adrian Otto (Rackspace) [scribe]: this will be ongoing during our F2F
MartinC1: CAMP-145 https://tools.oasis-open.org/issues/browse/CAMP-145
Adrian Otto (Rackspace) [scribe]: discussion artifact: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51025/camp-spec-v1.1-RMR.doc
Tom Rutt (Fujitsu): no content shared yet
Adrian Otto (Rackspace) [scribe]: Martin is setting up to share
Adrian Otto (Rackspace) [scribe]: Platform Resource is changed
Adrian Otto (Rackspace) [scribe]: links from Platform are adjusted to URIs of collections of resources
Adrian Otto (Rackspace) [scribe]: rather than arrays of resources
Adrian Otto (Rackspace) [scribe]: assembliesUri, servicesUri, and plansUri are the key differences
Adrian Otto (Rackspace) [scribe]: Assemblies: Collection of Assembly Resources
Adrian Otto (Rackspace) [scribe]: Assembly Resources are mostly the same, but they refer to components rather than platformComponents
Adrian Otto (Rackspace) [scribe]: Services is a collection of Service Resources
Adrian Otto (Rackspace) [scribe]: Plans is a collection of Plan resources
Adrian Otto (Rackspace) [scribe]: A Plan resource is an optional _expression_ of a DP, in JSON rather than YAML
Adrian Otto (Rackspace) [scribe]: If you POST a Plan to an Assemblies resource, an Assembly results
Adrian Otto (Rackspace) [scribe]: If you POST a Plan to a Plans resource, a Plan results
Adrian Otto (Rackspace) [scribe]: If you POST to a Plan, you get an Assembly
Adrian Otto (Rackspace) [scribe]: Components is a collection of Component resources
Adrian Otto (Rackspace) [scribe]: Component resources have a "relatedComponents" attribute so you can generate a hierarchy of components (parents, children, etc.)
Adrian Otto (Rackspace) [scribe]: artifact refers to an Artifact from a Plan
Adrian Otto (Rackspace) [scribe]: service refers to a Service (formerly known as PCT)
Adrian Otto (Rackspace) [scribe]: Issues 29, 23, 5, 22, 37, 64, 66, 74, 82 all addressed by this proposal.
Adrian Otto (Rackspace) [scribe]: Alignment of terminology is most of the proposed approach
Adrian Otto (Rackspace) [scribe]: Making the creation of an Assembly into a one step process is an additional feature of the contemplated Platform
Adrian Otto (Rackspace) [scribe]: Ashok: When do the components go away when the Assembly is acted upon by a DELETE request?
Adrian Otto (Rackspace) [scribe]: Martin: it would be possible to delete an Assembly and all related Components without impairing other Assemblies
Adrian Otto (Rackspace) [scribe]: Alex: Platform implementers can decide when Containers are shared, if at all
Adrian Otto (Rackspace) [scribe]: Alex: suggests that observing what implementations do should guide future spec work on this. Try not to over-specify this.
Alex Heneveld: (& this was an issue pre-refactoring, if anything this simplifies discussion on the issue)
Adrian Otto (Rackspace) [scribe]: Gil: Simplifying the spec to have fewer component types is a significant reduction in complexity
Adrian Otto (Rackspace) [scribe]: Gil: Section 4 does not change
Adrian Otto (Rackspace) [scribe]: Gil: Section 6 does not change
Adrian Otto (Rackspace) [scribe]: Gil: Extensions and metadata does not change. Only the resource model is adjusted.
Adrian Otto (Rackspace) [scribe]: Gil: Section 1.3 can be adjusted to show a more simple workflow to more closely track how today's PaaS systems work (go directly to a running Application in a one-step process)
Adrian Otto (Rackspace) [scribe]: Gil: The original two-step process is also possible by using a new feature (Plans)
Tom Rutt (Fujitsu): leave seperate URI resources for each type of container
Adrian Otto (Rackspace) [scribe]: Additional discussion: Adrian, Alex, Gil, Martin, Tom
Adrian Otto (Rackspace) [scribe]: touched on backpointers
Adrian Otto (Rackspace) [scribe]: touched on types, and possible consolidation for collections
Adrian Otto (Rackspace) [scribe]: Justification for this work: Adoption >> Window of Opportunity >> Interop + Portability
Adrian Otto (Rackspace) [scribe]: helps us strike a balance of Adoption and WoO
Adrian Otto (Rackspace) [scribe]: Tom: text about DP generated comment(s), there may be some editorial work to address that.
Adrian Otto (Rackspace) [scribe]: words "node" and "type" may not be used consistently
Adrian Otto (Rackspace) [scribe]: we will address this during the F2F within the scope of issue triage.
Tom Rutt (Fujitsu): I do not hear anything on the phone
MartinC1: 10 minutes recess
MartinC1: we are back
Adrian Otto (Rackspace) [scribe]: Topic: Triage Issues, identifying each issue flagged for TC discussion
Adrian Otto (Rackspace) [scribe]: https://tools.oasis-open.org/issues/browse/CAMP-98 discuss -editorial
Adrian Otto (Rackspace) [scribe]: sections 2 and 3 could be merged.
Adrian Otto (Rackspace) [scribe]: Gil: Yes, we can merge them.
Adrian Otto (Rackspace) [scribe]: Alex: instance diagrams are not the same as the type diagrams
Adrian Otto (Rackspace) [scribe]: Tom: We do need two different diagrams, but we could decide to just describe them with words, and not use a diagram.
Adrian Otto (Rackspace) [scribe]: Martin: Suggests we revisit this after our resource refactoring effort
Adrian Otto (Rackspace) [scribe]: https://tools.oasis-open.org/issues/browse/CAMP-99 discuss (with 98 maybe merge section 2 and 3) - editorial
Adrian Otto (Rackspace) [scribe]: Martin: Gil's proposal for CAMP-83 would address this.
Adrian Otto (Rackspace) [scribe]: Gil: confirms, yes.
Adrian Otto (Rackspace) [scribe]: Looking at CAMP-83 proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50879/camp-spec-v1.1-wd20-r1-NewNormTags-f3.doc
Adrian Otto (Rackspace) [scribe]: text in section 1.6 may resolve CAMP-99
Adrian Otto (Rackspace) [scribe]: + a minor editorial adjustment to the sentence about 'These tables appear in Appendix C, "Normative Statements"'
Tom Rutt (Fujitsu): I agree with adding the sentenced "all examples are informative?
Tom Rutt (Fujitsu): s/?/"/
Adrian Otto (Rackspace) [scribe]: Tom: Perhaps the table of "Normative Statements" are actually "Conformance Statements"?
Adrian Otto (Rackspace) [scribe]: Jacques: THey are Normative Statements, not Confirmance Statements
Adrian Otto (Rackspace) [scribe]: we can add "Examples are all informative, not normative"
Adrian Otto (Rackspace) [scribe]: Martin is updating CAMP-99 with an excerpt from the proposal for CAMP-83 to address the normative statement concern.
MartinC1: The statements that use these keywords have been highlighted as per this sentence, and each such statement has been given a unique tag in the following manner: [EX-00] For conveininece these statements have been tabulated and cross-indexed by their tags and appear in Appendix C, Normative Statements. All examples in this document are non-normative.
Adrian Otto (Rackspace) [scribe]: We will add "This section is informative." to the start of Sections 2 and 3.
MartinC1: mark section 2 and 3 as being informative.
Tom Rutt (Fujitsu): rfc 2119 is avout marking "requirements" Key words for use in RFCs to Indicate Requirement Levels
Adrian Otto (Rackspace) [scribe]: MOTION: m=Adrian s=Gil to resolve CAMP-99 with a direction to the editors to make changes outlined by Martin's proposal added to CAMP-99 as a comment.
MartinC1: Proposal:
In section 1.6, terminology, add the following text after the 2nd para:
The normative statements that use these keywords have been highlighted as per this sentence, and each such statement has been given a unique tag in the following manner: [EX-00][{note to editor highlight the sentence} For convenience these statements have been tabulated and cross-indexed by their tags and appear in Appendix C, Normative Statements. All examples and notes in this document are informative. Unless marked otherwise text in this specification is normative.
In addition add the following text as the first line of section 2 and section 3.
"This section is informative."
Editors discretion to mark other sections/appendices as informative.
Adrian Otto (Rackspace) [scribe]: No discussion.
Adrian Otto (Rackspace) [scribe]: No objections.
Adrian Otto (Rackspace) [scribe]: Motion passed.
Adrian Otto (Rackspace) [scribe]: https://tools.oasis-open.org/issues/browse/CAMP-102 discuss - technical
Adrian Otto (Rackspace) [scribe]: MOTION: m=Adrian s=Gil to close CAMP-100 with no action in accordance with resolution to CAMP-99.
Adrian Otto (Rackspace) [scribe]: No discussion.
Adrian Otto (Rackspace) [scribe]: No onjections.
Adrian Otto (Rackspace) [scribe]: s/onjections/objections/
Adrian Otto (Rackspace) [scribe]: Motion passes.
Adrian Otto (Rackspace) [scribe]: https://tools.oasis-open.org/issues/browse/CAMP-101
Tom Rutt (Fujitsu): could close as accomodated by resolution to 99
Adrian Otto (Rackspace) [scribe]: https://tools.oasis-open.org/issues/browse/CAMP-109 discuss - editorial
Adrian Otto (Rackspace) [scribe]: https://tools.oasis-open.org/issues/browse/CAMP-113
Adrian Otto (Rackspace) [scribe]: The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the CAMP specification to which this Deployment Plan conforms. The value of this node SHALL be "CAMP 1.1" as defined in Section XX [PDP-18]
Adrian Otto (Rackspace) [scribe]: The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the CAMP specification to which this Deployment Plan conforms. For this specification, the value is "CAMP 1.1" as defined in Section XX [PDP-18]
Adrian Otto (Rackspace) [scribe]: The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the CAMP specification to which this Deployment Plan conforms. [PDP-18]
NOTE: The value of this node SHALL be "CAMP 1.1" as defined in Section XX
Tom Rutt (Fujitsu): we need to wait to see if 1.2 is backwards compatible to 1.1
Jacques (Fujitsu)1: just remove PDP-18
Tom Rutt (Fujitsu): perhaps this campVersion node should be a sequence node, that way a dp maker could state which versions they are compatible with. They may only use the crossection of features from both versions
Tom Rutt (Fujitsu): futureproof the dp syntax
Tom Rutt (Fujitsu): qqqqqqqqqqqqqqq
Tom Rutt (Fujitsu): the array has the versions that this dp conforms to. They would only be able to put two values in if they conform to both sver
Adrian Otto (Rackspace) [scribe]: meeting is in recess until tomorrow
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]