Actions - Traceability Schema about k8s-deploy HOT 9 CLOSED

Discussion Notes:

1. Schema needs a version, so that we can handle back compatibility as we rev this.
2. Is Provider a Mandatory or Optional? Would you have predefined providers (Azure, AWS, GCP, OnPrem) listed or will any 'string' be ok?
3. Would Target resource type be a URI or String? Is it String because we need the schema to scale to On-premise targets?
4. I am assuming we are supporting only GitHub provider for Workflow. This seem like a good scoping call.
5. I am assuming that schema validation will look for "String : String" in Property bag for TargetResource, but will have rich strongly type schema validation for GitHub property bag in Workflow properties.
6. Remove the bootstrapconfiguration property from Workflow properties
7. Can you rephrase the "Purpose" column to explain the real need of those properties, instead of just explanation on their names.
8. Do we need to take traceability down all the way till Actions. Example: Multiple Action with same job can target same resource with different deployment status. How do we uniquely trace that?
9. Should Artifacts also have Provider, type and Property bag instead of flat properties?
10. Can we add one example for IaaS (VM Deployment) and one example for PaaS (AWS Beanstalk) with different artifact sources (Build drop and NPM or Nuget Package)

from k8s-deploy.

Here are few more open questions that came up in review with @smalpani-gh

1. DockerFileUrl demands that Docker image be downloaded so that we can inspect the tag. This will be extra step during CD. Should this download be done just for traceability?
2. Clarify where the k8s Deployment object traceability belongs, is it in targetResource properties or within the artifact properties?
3. Why do we need Manifest Url? Who is the consumer?
4. What is modified timestamp for a workflow run?
5. Does jobName belong to workflowRun or workfFlow? Clarify.
6. Why is workflow properties not a Uri but instead name/path etc?
7. Why does dockerFile, Helm and Manifest Url all under artifact and not in Workflow inputs?
8. How can user start from Azure and trace the information to which k8s deployment applied the configuration and which workflow deployment applied the configuration. Clarify the flow and which properties will be used in those cases.

cc: @rachitb777 , @ammohant , @azooinmyluggage , @pulkitaggarwl , @DS-MS

from k8s-deploy.

1. Yes, traceability would need this step to surface the Docker file against the deployment resource. The Docker file path is stored as a label in the docker image.
2. K8s Deployment is the run time kubernetes object create in the cluster. It belongs to the Target resource.
3. The AKS deployment centre spec demanded surfacing the manifest in the UI. In general if there is an intent to see if the desired and the current state differ, manifest can help in deriving that information along with the cluster state.
4. Inherited the definition from the proposed workflow resource. Modified timestamp can be done away with
5. JobName belongs to workflow
6. Artifact we have URIs as the source of the same can vary and hence URI, workflow path is the workflow identifier
7. Open item for discussion , can consider moving it to action context within workflow section or target resource k8s context
8. Details of the entry point to our experience can be found here

from k8s-deploy.

What is the right naming : Is it Microsoft/GitHub/........?
Examples https://github.com/opencontainers/image-spec/blob/master/annotations.md. http://label-schema.org/rc1/

from k8s-deploy.

Artifact: What other types will be there and why everything for K8s is of type container artifact.

from k8s-deploy.

Design question : How can we work around the need to download image and running docker inspect

from k8s-deploy.

Design question : How can we work around the need to download image and running docker inspect

Two ways that we have discussed earlier. One is store it somewhere just like ADO but we understood from GH is building some sort of a store that we can leverage. Second is to have an environment variable store the Docker file path , this is not a full proof way.

from k8s-deploy.

@smalpani-gh - This the final schema for the traceability we are closing on. Pls let us know of comments if any.

@rachitb777 @rohit-batra We can commit the final version of the schema once Sanjay gives the go ahead.

from k8s-deploy.

@rachitb777 Can I close this issue since we have deferred this work? We can open a new issue when we plan to pick this up.

from k8s-deploy.