• Move the logic in codiusd related to the manifest into the codius-manifest module.
• Validation of the manifest
• Handle all backwards compatiblity
• Return object that codiusd can use with hyperd

Add support for manifest versions in codius-manifest which will be where all manifest version logic lives. Codiusd and codius will use the codius-manifest npm module for verification of version and for generation of manifests.

• New optional field added to codius manifest called manifestVersion
• manifestVersion field uses format of YYYY-MM-DD` where YYYY is the year, MM is the month, and DD is the current day.
• Codius Manifest versions will be stored in json schema files with an individual file used for each version.
• Manifest Validation (codiusd & codius)
  • A function will be exposed to codiusd & codius which allows the validation of a manifest.
  • This function will only validate the manifest based on the version and if errors our found return informative errors on why validation failed.
  • If no manifestVersion is present the validation will be performed against the oldest version in codius-manifest module.
  • If the manifestVersion is present validation will be performed against that exact version. If that version is not found an error will be returned with information about which versions are valid.
• Codius Manifest Generation (codius)
  • During the codius cli generation of a manifest if no version if provided it will use the latest and add that version to the generated manifest.
  • manifestVersion will be a supported field for the codius.json file in the codius cli
  • If manifestVersion is set in the codius.json file then only that version of the manifest will be used for validation and manifest generation.

How do we supply private information that cannot be altered/tempered with inside a manifest that can only be set by the vendor or customer?

I am looking at codius as two ways:

1. Software Vendor - Do a SaaS per manifest to purchase or use my code as a service so, code must be private? how do we actually enforce that if we can just do docker pull and get it?
2. Customer - Use manifest as to do something, how to we generate some code to send prior of deploying it, like a private key?

In both cases I end up as not being able to trust the manifest data as private.

• Add nonce to the codius manifest during generation so that each generated manifest is unique even if the codius.json and codiusvars.json match.

It's not clear from the spec as to where the images come from.

"image": "hello-world@sha256:f5233545e43561214ca4891fd1157e1c3c563316ed8e237750d59bde73361e77"

Where is the hello-world image stored (eg docker hub)?

Is there an example repository for building images?

It would be best to include:

• Require resources (space ie. 5GB free, or cpu ie. 4 cores)
• Require functionality (Outgoing requests or Incoming )
• Require Minimum Run time (ie. 1 year)

This way a host can select which manifest to accept prior of installing docker image.