---
tags: Discussion
---
# PhaseManifest

Generate a phase manifest to be delivered to the cluster every time a phase is applied: https://go.gliffy.com/go/publish/13358010

## Is PhaseManifest a ConfigMap or is it a Kind/CR document?
Needs to contain rendered manifests and some sort of versioning for history including a timestamp
Rendered manifests should be a zipped bundle Base64-encoded.
Phase Manifest is appended to rendered bundle prior to executing the phase executor

kind: PhaseManifest
metadata:
    namespace: 
    name: [Name of the Phase].[version incremental number]|[timestamp in msecs is here]
    timestamp:
spec:
    phaseManifestsSecret: 
        name: foo
        namespace: foobar
    repositories:
      [repo name]:
        commit: 6bedc2029911e2dd5cb5b863934ca91593a371c6
        dirty: false
        tag: ....
    status:
      results: successful
      status: completed
      user: M35881  
        
kind: Secret
metadata: 
    name: phaseManifestsSecret
spec:
    <Encrypted and Zipped Manifest Bundle>

This is the older version of these in Airship 1.

deployment:
  action: 01EMYT9TK855YG8H5R6BMY3TYK
  context-marker: 98f34a82-224e-4382-9aa8-6ae165563e34
  date: '2020-10-18 21:36:59.496455'
  document_url: deckhand+http://deckhand-int.ucp.svc.cluster.local:9000/api/v1.0/revisions/1/rendered-documents
  results: successful
  status: completed
  user: M35881
documents:
  aic-clcp-manifests:
    commit: 6bedc2029911e2dd5cb5b863934ca91593a371c6
    dirty: false
    tag: 2020-10-18_10-35-42_stable_deployment_unstable_tests, auk59z_stable_deployment_master,
      auk59z_stable_master, mtn57a_stable_deployment_master, mtn57a_stable_deployment_unstable_tests_master,
      stable_deployment_unstable_tests
  aic-clcp-security-manifests:
    commit: da0c31dc281ee558b09c8aa6f6580ff991b90474
    dirty: true
    tag: Detached HEAD
  aic-clcp-site-manifests:
    commit: fae3eaa2f9f35bbfc7ff7b3526a792dddae2dfa6
    dirty: false
    tag: Detached HEAD
  nc-network-manifests:
    commit: 19f6cdc99c1a1e2c5e0c5bb9d13a7f1918e64e5e
    dirty: false
    tag: Detached HEAD
site_type: cruiser
version: master

## Where does the PhaseManifest live?
Whichever cluster you delivered a phase to, that is where we would store the appropriate PhaseManifest,

## Is there a size problem with the ..

## Use git for history
What if when we run apply.. and store the manifests in to git withouth gate...
No we will cnstruct the repo section from the .git information to extract the details

Target/Repo nameA/<git>/a/b/c/d/phaseA
Target/Repo nameB/<git>/a/b/c/d/phaseb
Target/Repo nameC/a/b/c/d/phasec
Target/Repo nameD/a/b/c/d/phased

Phase run <xyz>
* Identify Target
* Navigate through all repos.
* Gather the aporpriate git info

This is not always feasible i.e. baremetal redfish stuff , the Phase docment and the executor may need some knowledge about what or when to do something with the PhaseManifest.,
Log local copy of phase manifest in a log or directory.

Expectation is that the source of truth is the PhaseManifest in the Cluster. Disagreements between PhaseManifest on local and not existing on Cluster will mean that the phase was never successfull.

## Further design questions which could become new issues:
* is there a history of these Phase Manifest documents

* Cleanup of this artifacts over time?
* What does using this document look like for Auditing prposes?
* What was the last phase delivered to the site? Timestamp should be easily useful, like part of the metadata perhaps.
* How does Plan provide a status/history using the combination of teh PhaseManifests , is there a Plan Manifest