Make it easier to get started with stacker

[mwildehahn]

I used stacker for a small project over break and it was painful to get up and running with it. A part of this was some unmerged PRs like stacker blueprint info as well as the dynamodb blueprint, but it was also annoying to have to remember the following:

• create an env file
• create a config file
• invoke stacker
• install private blueprints

i had to read through some existing projects use of stacker to remember the env/config file setup. setting up the virtualenv was annoying because it wasn't a python project. i didn't even attempt to install private blueprints because i didn't want to have to have to write a script to install them before running stacker.

my thoughts on how we might make this easier:

stacker init

something similar to npm init where we ask some questions with defaults that sets up the bare minimum file system that stacker depends on:

• conf directory
• yaml config
• dev env file

i think this would make it easier to get stacker running within new projects faster

invoking stacker

I think this would have taken care of my last two points (invoking and installing private blueprints): https://github.com/remind101/stacker/blob/master/scripts/docker-stacker

but the stacker version within the docker image isn't release-1.0

it might be cool to have these live within a stacker docker namespace? so i could have just run something like:

stacker docker build <namespace> <config> --private-stacks stacks? and it would take care of running these within docker for me.

using stacker

stacker blueprint info was really useful when getting back into stacker after being away from it for awhile. I think adding first class support for explaining troposphere types as well as maybe even discovering community blueprints would make this even better.

[troyready]

After you mentioned coming back to stacker in Slack, I started thinking about the on-boarding experience and came to many of the same conclusions.

Strongly agree about the init subcommand in particular. Hardest part will probably be the color of the bike...I mean the exact directory layout to do.

For the stacker-docker, you should be able to reference the release-1.0 tag to use the current version (maybe that was something fixed after your post here)

The only thing I'd like to do differently is handling private stacks. Installing them as python packages seems fine enough to me in docker, but handling the different versions of an blueprints via a python install in general isn't appealing to me. I'd rather have the ability to reference them directly (#332) or something akin to it.

[russellballestrini]

I'm currently on-boarding with stacker myself and have been running in similar feels. I plan to look into developing the init command over the next few weeks.

In the meantime, checkout https://github.com/russellballestrini/stacker-helloworld

[russellballestrini]

Another update: I converted my stacker-helloworld into a Cookiecutter project template: https://github.com/remind101/stacker_cookiecutter

Assuming Cookiecutter is installed the usage is really simple:

cookiecutter gh:remind101/stacker_cookiecutter

A new project directory will be created in your present working directory.

[dkondratovych]

init would help a lot, it's not clear that python setup.py install should be executed or Readmy should be updated with detailed steps.