I think the readme has gotten a bit stale

Mixins need to be able to provide info at build time (for porter build), such as binaries to copy into the invocation image.

The porter configuration file (porter.yaml) could really be in any markup language, and should be up to the bundle author to select. There isn't anything stopping us from having everyone use a different language.

Let's switch to viper for reading in that file so that @radu-matei can use HCL.

we always look for a source leaf node - and plug in the real values

$ mixin-runtime install -- STDIN
name: parsed name
command: bash -c "Hello, $CNAB_P_NAME"
parameters:
name: susie

• Write a draft of a CNAB Authoring Spec based on porter.
• Define the goal of having an authoring spec, what does having a spec help us accomplish.
• Identify key elements from porter that would be necessary for other authoring tools to adhere to in order for them to work together. For example being able to author a bundle that depends upon another bundle that was authored with a different tool. (Not sure if this should be in scope?)

• porter run porter.yaml
• figure out the action
• running the steps for each action, calling to the mixin-runtime
  • porter-runtime needs to check the exit code from the mixin and stop if necessary
  • porter-runtime needs to include the mixin's stderr in our stderr
  • mixin runs in a separate process (not exec'd)
  • porter-runtime echoing out the step description

https://hackmd.io/fK6Mc2iKTfqNxFfwwowNbQ?view

• copying in stuff for helm, arm
• generating dockerfile

An important part of the CNAB spec is the use of referenced images. We need to have a way to handle this with Porter. It would be nice for the mixins to be able to report what they will use at bundle generation time per #70 , however in the interim we can make this a declarative feature and include it in the porter manifest.

• make a porter.yaml
• make the run script

Once we have build and run, let's add a simple end to end test to our CI (essentially expanding on the test that is already there for porter run) so that it follows our workflow and tries out all the pieces)

• porter init
• porter build
• docker push
• duffle install

When I use the mysql helm chart, the host isn't one of the outputs (in the secrets). If the helm mixin made the services available in the outputs, I could piece together the proper host connection string.

Currently we only resolve dependencies down a single level. Eventually more complicated bundles will want to have dependencies that have dependencies too. Resolve and apply them from the bottom up.

porter should have a command like init that sets up your "Porter Home" with cross compiled binaries for porter and the mixins to support building invocation images.

For example, I download the Windows porter binary. porter init should create a directory structure under %HOME%/.porter/ and %HOME%/.porter/mixins with appropriate cross platform binaries. These will be used to populate the Docker invocation images when created.

https://github.com/deis/duffle/pull/413/files

Replace the source: bundle.dependencies.foo.parameters.bar with the actual value from the dependency.

• read the porter.yaml, pick the mixins (DONE)

• make the dockerfile, entrypoint must be /cnab/app/run (DONE)

• put in the FROM (DONE)

• copy in porter.yaml + run (DONE)

• call the mixin's, let them add more stuff

• pick a FROM

  • start with debian: for POC (DONE)
  • pare it down (eventually it's configurable)

• add the porter binary (DONE-ish)

  • exec mixin (standalone executable + stuff) (DONE-ish)
  • /porter/bin/porter-runtime (DOEN-ish)
  • /porter/mixins/NAME/mixin-runtime (assume executable is named mixin) (DONE-ish)

Should be able to apply manifests and delete.

https://docs.google.com/document/d/1-xyWdwoXGOeeoM_e45u-KpCnYTodKk5-nX9d4f88nu0/edit#

The answer is put them in the cnab/app directory but let's document that.

Implement an Azure mixin that is capable of provisioning a CosmosDB suitable for the MySQL + Wordpress example.

We should handle our errors in the main cobra cli wiring of cmd/porter so that help text isn't printed for every error, just cli validation errors.

GOT

duffle install PORTER-HELLO -f bundle.json --insecure
Executing install action...
executing porter install configuration from /cnab/app/porter.yaml
Install Hello World
Hello World
Try Helm
Error: Get http://localhost:8080/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: dial tcp 127.0.0.1:8080: connect: connection refused
Error: exit status 1
err: exit status 1
Usage:
  helm install [flags]

Flags:
  -h, --help   help for install

Error: mixin execution failed: exit status 1
Usage:
  porter run [flags]

Flags:
      --action string   The bundle action to execute (Defaults to CNAB_ACTION)
  -f, --file string     The porter configuration file (Defaults to porter.yaml) (default "porter.yaml")
  -h, --help            help for run

Global Flags:
      --debug   Enable debug logging

WANT

duffle install PORTER-HELLO -f bundle.json --insecure
Executing install action...
executing porter install configuration from /cnab/app/porter.yaml
Install Hello World
Hello World
Try Helm
Error: Get http://localhost:8080/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: dial tcp 127.0.0.1:8080: connect: connection refused
Error: mixin execution failed: exit status 1

For Helm Mixin and others, implement "copy on build" to populate invocation image and referenced images in bundle.json

Exec mixin should take "string" args or source references.

Porter should have a way to update mixins that are installed.

See full instructions on what needs to be implemented #30 (comment)

• azure and helm mixins initially
• build time mixin (handles copying stuff into the invocation image)
• runtime mixin (handles executing instructions from the porter.yaml)

Create the skeleton Porter CLI:

• porter init - makes porter.yaml
• porter build - (re)generate Dockerfile
• porter version - Prints Ralpha 0.1

Right now the porter manifest lets a bundle author template out values for certain things, bundle.parameters.NAME, bundle.credentials.NAME, etc.

But metadata about the bundle can't be substituted in yet. I would like to be able to do something like this in my porter manifest:

bundle.name

We have a view pieces of information in our bundle metadata that would be nice to make available:

• Name
• Description
• Version
• Image

It may help you when you implement this to move those fields into a new embedded struct on the Manifest. If you need to do that, feel free.

This is the function that would need to be modified:
https://github.com/deislabs/porter/blob/9eed13889d855c5665c42b9b4b2ac8153a8feae4/pkg/config/manifest.go#L647

That would let someone use bundle.*

There is another function

https://github.com/deislabs/porter/blob/9eed13889d855c5665c42b9b4b2ac8153a8feae4/pkg/config/manifest.go#L83

That lets someone use bundle.dependencies.NAME.*, for example to access metadata about one of their dependencies, bundle.dependencies.mysql.version.

It would be nice (though not required), if both were updated.

See https://porter.sh/authoring-bundles/ for more context on the porter manifest.

The run script is created at porter create but really it's a boring file that we don't encourage people to modify. Let's make it so that if its not present during porter build, we recreate it for them. That way you can just check in the run script if you modified it.

When a Dockerfile is in the bundle directory, porter will use that as the base, instead of starting from our template, and then layer its new lines on top of that. When you provide your own Dockerfile, then it is your own responsibility to take care of ca certificates and generally have a working base image.

If all you care about is setting the base image, but don't want to customize it further, like copying in extra files, then you can do that in the porter config file

Update: Turns out what I originally suggested wouldn't work. So instead I added a new field to the manifest dockerfile so the user can specify a custom Dockerfile template.

We should rename the new init command to allow init to be used to setup porter for the first time.

New command could be something like porter create or porter new.

This just populates the bundle dependencies section, and then merges the porter.yaml's together when building the image. Wiring the dependencies is another issue.

Right now we are still using a GH token because duffle used to be private. Let's switch to using the public repo and stick with a known tagged release.

Implement a mixin for helm charts

• Buildtime
• Runtime
• Support common helm install flags
  • namespace
  • version
  • set
  • replace
  • values

The parameters and output format for the Mixins can vary so we should provide a way for users to interrogate the mixins to get the schema.

Let's switch to whatever duffle is doing so that I don't have to set these environment variables anymore and it just uses my existing docker login.

hugo + netlify FTW

Right now the mixin output isn't piped, so it always prints to stdout/stderr. It needs to be piped back through into our stdout/stderr, so that when we are running in a docker container that it is being logged appropriately.

Host our docs site on porter.sh. Cute landing page encouraged! 🚀