Provide VAT Team with proposed container naming workflow

Background

During the latest TaD talk (7/20/21) we discussed how new container names are created w/in VAT, and the currently known issues with this process. At the moment, new container records are created when someone pushes a previously unused combination of container name and container tag. The problems with this process are the folling

• There is no process to re-name an existing VAT container, or carry over its findings and their approval state
• We do not check if a name exists before the pipeline attempts to push data to VAT or Registry1. This means one project can override the findings of another project if there is a naming conflict

Proposal

If container names were to be created before a project pipeline is ever run, we could address these issues. First, we could check to make sure that new containers will not have colliding names with existing containers. Second, we could easily re-name containers if this process were followed. The main idea for this is to create a container record in VAT via an API endpoint that first checks if the container name exists, before creating a record in the VAT DB. This VAT DB record would have a unique auto-incrementing ID (its primary key (PK)), a Unique container name and tag combination, an associate GitLab project name, and an associated GitLab project ID. Internally, VAT would link records via the container's PK. When an update to the container name or GitLab project location is desired, an API endpoint could be used to send the existing container name, GitLab project name, and GitLab project ID, along with the desired update, to update the container record. All scans and log info are linked via the container PK, so an update to the other info will not cause approvals to be lost.