Event details


  1. Roll Call
  2. Scribe nomination
  3. Review minutes of previous meeting
  4. Change Management topics
  5. Configuration Management topics
  6. Any other business


Chat transcript from room: oslc-ccm 2016-07-14 GMT-08:00

[07:04] Nick Crossley (IBM): Nick to scribe

[07:04] List of attendees: Brian Steele (IBM), David Honey (IBM), Jim Amsden (IBM), Nick Crossley (IBM), Peter Hack (IBM)

[07:04] Nick Crossley (IBM): Minutes of last meeting at

[07:05] Nick Crossley (IBM): Minutes of previous meeting approved

[07:05] Nick Crossley (IBM): Change Management topics

[07:05] Nick Crossley (IBM): Jim: issue 26

[07:05] David Honey (IBM):

[07:05] Jim Amsden (IBM):

[07:06] Nick Crossley (IBM): Changes made, and reviewed: issue to be closed

[07:06] David Honey (IBM):

[07:07] Nick Crossley (IBM): Discussion to be deferred until Martin is present

[07:07] David Honey (IBM):

[07:07] Nick Crossley (IBM): Same with issue 29

[07:08] Nick Crossley (IBM): Configuration Management

[07:11] David Honey (IBM):

[07:11] David Honey (IBM): Sections 5.1 and 5.2

[07:13] Nick Crossley (IBM): On default configuration:

If a configuration context is not provided or implied, the server MAY provide a default configuration, or the request MAY fail. A provider MAY include an <code>oslc_config:configurationSettings</code> link in the OSLC Service resource, referencing an <code>oslc:ConfigurationsSettings</code> resource. That resource MAY contain an <code>oslc_config:defaultConfiguration</code> property whose value is the URI of the default configuration to be used by that service. An <code>oslc_config:defaultConfiguration</code> property with an rdf:nil value implies there is no default configuration, so requests with no context will fail. Servers MAY support a PUT on <code>oslc:ConfigurationsSettings</code> resource as a way to set the default configuration. Servers MAY provide other ways for users to set the default configuration.</p>

[07:20] Nick Crossley (IBM): Nick to review overall structure of Config Management spec, to see if compliance requirements could/should be each in separate numbered sections.

[07:22] Nick Crossley (IBM): Third sentence should be: "An <code>oslc_config:defaultConfiguration</code> property with an rdf:nil value implies there is no default configuration, so requests with no context MUST fail."

[07:23] Nick Crossley (IBM): Next part of this concerns the identification of which config was used for a request:

[07:24] Nick Crossley (IBM): Identifying the configuration used by a request

Where the response to a GET is a single versioned resource, the server SHOULD include a <code>Configuration-Context</code> header indicating the precise configuration in which that resource was found. Note this is frequently not the same as the context on the request: the context on the request is likely to be a global configuration, while the context on the response, if present, MUST be the leaf-level provider-specific configuration used to resolve the version. This could be either a direct or indirect contribution to the requested context, or it could be the default configuration.

[07:36] Nick Crossley (IBM): There are difficulties in this proposal - the language about 'precise configuration' is not precise, and does not address the case where a resource is split across multiple local configurations.

[07:36] Nick Crossley (IBM): Suggest we drop this part.

[07:36] Nick Crossley (IBM): Will discuss in a future meeting.

[07:38] Nick Crossley (IBM): Last part marked in red: on deletion of baselines.

[07:38] Nick Crossley (IBM): Since providers may support deletion of baselines, clients must not assume that references to baselines can be resolved; like any other resource, clients must be prepared to handle 404 errors. Since baselines are normally linked into a provenance chain using the <code>oslc_config:previousBaseline</code> property, servers may elect to leave a stub resource behind instead of truly deleting a baseline.

[07:47] Nick Crossley (IBM): Discussion about lifetime of baselines: Jim wondered if there should be a property to indicate the 'release' state of a baseline

[07:50] Nick Crossley (IBM): Nick described how the early TC discussions explicitly decided not to include workflow/lifecycle attributes

[07:50] Nick Crossley (IBM): ACTION: Nick will explain the 'stub resource' more.

[07:51] Nick Crossley (IBM): Any other business?

[07:51] Nick Crossley (IBM): Meeting adjourned.

Meetings/Telecon2016.07.14 (last edited 2016-07-14 16:55:00 by ndjc)