Meetings/Telecon2016.07.14

Event details

https://www.oasis-open.org/apps/org/workgroup/oslc-ccm/event.php?event_id=41639

Agenda

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

Minutes

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 https://wiki.oasis-open.org/oslc-ccm/Meetings/Telecon2016.06.30

[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): https://issues.oasis-open.org/browse/OSLCCCM-26

[07:05] Jim Amsden (IBM): https://issues.oasis-open.org/browse/OSLCCCM-26

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

[07:06] David Honey (IBM): https://issues.oasis-open.org/browse/OSLCCCM-27

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

[07:07] David Honey (IBM): https://issues.oasis-open.org/browse/OSLCCCM-29

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

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

[07:11] David Honey (IBM): https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt/config-resources.html

[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)