Agenda

1. Review of recent core activities ( change log, baselines).
2. Dicsuss recent baselines discussions at core, compare with recent context discussions.

Attendance

Regrets: Brenda Ellis, John Crouchly

Atendees: Dave Johnson, Alanna Zito, Clyde D. Iscuspit, Jim Amsden, Eldad Palachi, Dan Berg, Sandeep Kohli, Tom Picolli, Steve Speicher, Jim Conallen

Minutes

We continued our discussion of baselines, specifically examining the current Core proposal for baselines in the context of AM.

In this proposal the term "configuration" is defined, and from System Architect's point of view roughly corresponds to a workspace, and from Design Manager's corresponds to a project or stream. A baseline in this proposal corresponds to a snapshot in DM and a baseline in SA.

Baselines are created for the most part to provide an immutable configuration for clients. Another scenario involves baseline comparison.

The overall proposal defines a camera capability which is used by a client to tell the server to prepare a snapshot (frozen version) of a resource(s). The snapshot'd resource is represented with a new URI. Implied in this approach is the rewriting of all internally referenced URIs, should the snapshot be part of a collection of interrelated resources. The client then prepares a baseline resource with all the snapshot references in it and POSTs it to the server.

While this proposal does not exclude cross service provider baselines, it does not attempt to solve the problems of synchronizing snapshots of resources across service providers and domains. Jim Amsden noted that the only right solution is to not have separate projects/providers where resources of different types are managed by different providers. He argued that by dealing with this specification we are not only perpetuating the problem, but hardening in capabilities that may be difficult to change later.

In AM domain, due to issues creating transitive closure, we typically create a snapshot of entire configuration. AM projects may contain 100s of thousands resources to millions of resources.

This places a great burden on the client assembling the baseline resource, since they must GET the entire list of snapshot URIs and then POST them back in the baseline document.

We need a way in which a client can request a snaphot, but not be required to explicitly add each and every resource URI individually to the baseline resource. It would be nice if the client could get some other 'project snapshot URI' from the camera action that represents the entire closure of resources and can be passed into the baseline resource. We currently do something like this when we create baselines with JFS. There we can create a baseline resource by passing it a query instead of a list of resources.

Assuming we can get something like this to work in the proposed baseline approach, Tom verified that System Architect's approach for baselining is compatible with this. In SA when a workspace (configuration) is baselined (snaphot'd) all the resources and the URIs are frozen. If/when a new workspace is created from the baseline the resources can change, and only when they do, does their URI also change.

In this scenario it is possible for the same resource URI to be part of multiple baselines. The current baseline proposal does not seem to forbid this.

For Design Manager this proposal is a little more problematic. Since DM is a Jazz application and uses JFS for storage and baselines, its current approach is to use the JFS baseline API to freeze the resources without URL rewriting. A baseline in JFS is basically moved to a separate index. DM uses the convention of appending a query part to the URL to specify baselined content.
This means that DM will have to either manually do the URL re-writing as part of the baseline process (not sure how that will work with the JFS baseline API), or we will have post-process all GETs on baselined resources and update the URIs there.

Regarding baseline comparison, it is not clear that a client can do baseline comparison easily. Since the URLs are changed for each snapshot of a resource. A client would have to GET each and every resource in both baselines, and use the dcterms:identifier property to determine that two resources were in fact just different versions of the same resource. For AM baselines that contain hundreds of thousands of resources (due to transitive closure issues), this is quite a burden.

It may be useful to define some services that a client can use to more easily map a resource URI to the re-written URL in a baseline.

I think we still have more to discuss with the approach, and I am hoping we can keep up the conversation in the mailing list.