Write user stories

[michelleN]

No description provided.

[carolynvs]

These are notes from a conversation with @michelleN and @jeremyrickard

Dev Loop

tight dev loop against the current directory

1. edit the run script / dockerfile / duffle manifest
2. duffle build ./foo
3. duffle install ./foo

Should not have to push to docker, the local store or any other commands than what's above. Signing should magically work, and not require --insecure

Signed Bundles in Local Development

How does a user get started with signing? Maybe this works already out of the box, and just needs to be documented?

CI Steps

What would a typical CI look like?

1. duffle build ./foo
2. docker push fooinvocationimage
3. duffle sign mycorps-keys ./foo (not sure what this looks like, maybe it's part of build)
4. duffle push ./foo myregistry

Managing a company's keys and key distribution

How are public keys for a company distributed so that when people isntall their bundle, that the bundle can be verified?

Install a third-pary bundle

As an end user, how do I add bundle repo and install bundles from it, working off of the local store only

[michelleN]

First time bundle author

As someone who looks at duffle/CNAB for the first time, I want to be able to get started with it by making something useful for myself. I have an application that I already know how to deploy in the cloud but I want to package that install script inside of a bundle and make it available to my peers (teammates or other folks in my company).

User is just getting their feet wet here

# download duffle binary and put it in path

$ duffle init     # get my local env ready / prep my keys for signing
$ duffle create mybundle   # scaffold mybundle directory with all the bits that make up a bundle
$ duffle build && duffle install someName .    # builds invocation image, install, see some magic

User wants to customize install a little bit

Jump right on in; the water is warm

$ duffle uninstall someName          # delete the claim
# ... iterate on bundle by changing the run script install instructions, etc.
$ duffle build && install someName .        # re-install to see your custom install logic work
# ... iterate until you have an install step that works the way you want

User is thinking this might actually be useful for me. 🤔

$ vi duffle.toml                             # edit the duffle.toml to include your registry info/name/version/descr
$ duffle build --push-artifacts

User is like... wait this is actually useful and I want to show it off! 🎉

The following steps would be in line with whatever the scenario for distributing bundles looks like but at this point, this user can take the bundle file they created and distribute that any way they choose and their teams can try it out. Might be as simple as committing the bundle.json file to a github repo

[technosophos]

(Note: duffle init is now done automatically)

I totally agree that this is what basic user example ought to be.

This workflow (which is just about identical) is what I had in mind:

$ duffle create mything
$ cd mything
$ # edit
$ duffle build
$ duffle install mything
$ duffle uninstall mything
$ duffle build
$ duffle push

I do think, though, that we also want to cover the case where a developer grabs an existing bundle and works on that:

$ duffle pull --maybe-flags some/thing:1.2.3
$ # edit
$ duffle build
$ duffle install thing

[technosophos]

Also, in my mind this is how a project goes if the user is writing application code and not just building bundles:

$ # edit the code
$ duffle create myproject
$ # edit the configuration
$ docker build myapplication/Dockerfile # this is building application images, not Duffle invocation images
$ duffle build

In other words, duffle does not care about the user's application, and makes only one assumption: that their configuration can be expressed in the CNAB.

[technosophos]

On 432, I ask whether if we use local storage, we can just eliminate the duffle.toml and use a basic bundle.json (cc @itowlson ). From a UX perspective, this works well in the local storage model (though not well in the filesystem story) for two reasons:

• The bundle.json the user sees is only used for dev
• The bundle.cnab, which is in the store, is NOT user-editable

So there's no real room for confusion like there was before.

So in that case, the user story for editing a description or a version field goes like this:

$ cd mybundle
$ open ./bundle.json # edit and save
$ duffle build

[technosophos]

Also, yesterday I had brain-dumped on user stories on this issue: #424 (comment)

[michelleN]

• Rename the components --> invocation images
• components map 1:1 with invocation images
• duffle build --> each invocation image should built and the references should be updated in the bundle.json/.cnab file
• new section in duffle.toml called images or image refs will just be
• updates docs to reflect duffle build only builds invocation images and not application images

[michelleN]

original reasoning for the: don't want people to be hand editing the bundle.json. we've never handled the docker manifest before.

[michelleN]

relevant issue comment around user stories: #424 (comment)

[astrieanna]

When I have used duffle to develop a new bundle, I used the following workflow:

docker build . -t mybundle/invocation-image
$i=1; duffle install attempt$i ./cnab/bundle.json --bundle-is-file -p parameters.yml -c my-creds
duffle claim show attempt$i -o myoutput

Because we're creating/editing the bundle.json by hand and are already familiar with creating docker images using docker directly, we only involve duffle when we want to execute the bundle.

Because we started by implementing only install & making it work completely (on a bundle where install and upgrade will eventually be identical), it is not obvious that you should run uninstall (/make uninstall work on your bundle just to get rid of old claims). Adding the indexing variable is to get around not being able to re-run install. Using a variable makes it as easy as possible to get new, predictable claim names; sometimes we started the line with i=$((i+1)); duffle install .... The variable needs to be present for later steps so that duffle claim show can be consistently pointed at the latest install attempt without editing that command at all (i.e. just up-arrow to pull it directly from the shell history).

Due to #866, when we wanted to add a custom action, we had to get our bundle into duffle bundle list. We achieved this by manually editing the ~/.duffle directory and changed the duffle install command to reference the same. When we edited the bundle.json, we had to remember to copy it to ~/.duffle/bundles/mybundle.