Quickstarters should be able to announce what fields they export for MRO

[clemensutschig]

Is your feature request related to a problem? Please describe.
Today the mro expects three fields to be present in the buildArtifactUri map - Build Id, Docker Image and Deployment ID. While this holds for std ods components, the more we go to support pieces like IAC or the existing e2e test - that will not work.

Describe the solution you'd like
tbd

[metmajer]

I see this as part of a bigger challenge:

1. Ideally, the orchestrator has no expectations on the specific fields a single component has to report. To avoid expectations in terms of a contract in a configuration file, the component would simply provide the data it wants to share in a name-to-value mapping. That said, the map would be the contract.
   Given the name part is human-readable, the orchestrator could simply pick up the data structure as we do it today and apply the contents to the document template as-is. This approach provides best flexibility to a component designer. Since test results are exchanged via an xUnit XML document, I believe that such contents will always go into an installation report.

2. Here's a related challenge on top: assuming that some component B depends on component A in a way that B can only be delivered if it has received data from A. An example is the deployment of VMs with some cloud provider (by A) that shall be configuration (by B). Here, we need some output-to-input mapping that can either use the same or a similar approach sketched out in 1). Obviously, this is a perfect fit for the orchestrator.

@clemensutschig @michaelsauter Thoughts?

[metmajer]

A very interesting topic indeed, especially the part where the MRO would provide the outputs of a component as inputs to a dependent component.

Question: currently, we load a component's Jenkinsfile as a job into the MRO pipeline using Jenkins' load step. Looking at the way our component Jenkinsfiles look today, there is no entry-point that I could use to provide these inputs. Example:

def job = load("a-component/Jenkinsfile")
job.run(inputs)

In an approach that would not change the existing behaviour of a component, the MRO would wrap a Jenkinsfile's invocation of odsPipeline in a run() method on the fly just before load inside a newly created Jenkinsfile.

What appears to be a hack, is maybe not the best, but an OK way so our existing components wouldn't have to change their internal structure. Also, this way, they would remain independent (loosely coupled) from any assumptions of the MRO. Downside: wrapping code and injecting support for an inputs variable is brittle by nature and will need maintenance whenever the internal structure of a component's Jenkinsfile changes.

Thoughts anyone?

[michaelsauter]

As the concept is not clear yet, we will have to move this to ODS 3.

[michaelsauter]

Looking at the timeline and the priorities, I am moving this to ODS 4.