Create "Graft" as a part of the trestle framework

[butler54]

Issue description / feature objectives

Discussions within the team have focused some need on what is called 'graft' or 'master-aggregator' a set of functionality for combining various sources of partial results into a SAR responding to a SAP.

Previous discussions have presumed graft was an independent tool. Current discussion with @degenaro suggest that a better alternative is to (until it matures or potentially permanently) fold it into trestle.

This gives us two options.

1) Create an independent trestle graft command Pros:

• Allows independent CLI args to be passed to graft
• Flexible Negatives
• More work initially
• It implies that graft will be self contained / aware of all sub options.

2) Create a trestle task for graft e.g. trestle task graft Pros:

• Simple interface to get started
• If graft does not mature / gain too much complexity it can be used as a simple interface Negatives
• Interface constrained to config files
• Effectively is constrained to a single action type.

Initially I was leaning towards (2) but I think that (1) may work acceptably well and provide a little more flexibility.

Secondary concerns:

• Graft by it's nature deals with fragmentary OSCAL artifacts without header metadata.

• Suggested solutions

  1. Create or let graft create a directory within the trestle directory tree as a landing zone. For example: TRESTLE_ROOT/graft or TRESTLE_ROOT/fragments/ Technically this approach does not conflict with what is currently in trestle, however, it does make the directory structure messier by implying it.

2. Allow graft to point to an arbitrary external directory for any fragments. This would be my preference as it can (in the future) easily be extended with the 'trestle.remote` functionality which is under development to allow fetching of remote resources on github / webservers / sftp etc.

Recommended next steps:

1. Create a barebones skeleton for trestle graft subcommand if there is agreement.

[butler54]

@degenaro - Have a read of the issue above. If it sounds reasonable to you I can implement an initial skeleton for you to work with.

[degenaro]

@butler54 - Does sounds reasonable to me. Some comments.

The ultimate goal is to produce a valid OSCAL Assessment Results (AR).

For each graft invocation,

requirements are:

1. Access to the one or more files containing the partial results, each comprising a list of OSCAL AR Observations.
2. Access to the corresponding single Assessment Plan (AP) and single Component Definition (CD) files.
3. Access to the location to store the AR file.

parameters are:

1. Locations/names of the inputs.
2. Location/name of the output.

operations are:

1. Ingest the input files.
2. Combine Observations into Findings, one for each Control specified in the CD.
3. Produce the output file, employing AP as needed.

[butler54]

I created a basic graft skeleton on this branch here: https://github.com/IBM/compliance-trestle/tree/feature/graft - there are few todos but I believe it would provide the basic skeleton.

[butler54]

@degenaro - do you think that we can break this down into a few more issues so we can track progress.

[AleJo2995]

@degenaro , @butler54 We were just reviewing stale issues and we were wondering, is this still relevant to have a look and review again?

[degenaro]

I think this can be closed. Re-open if wanted/appropriate at later date.