I was very excited to learn about the Ansible crew’s intention for Galaxy; kind of a marketplace for re-usable roles from what I understand. This can be very successful and useful, and I’m looking forward to see what standards form around it.
Personally I’ve been working on an ansible “framework” with a focus on convention and avoiding redundant code (e.g. all applications share a common “application” role, services a “service” role, and systems/machines a “system” role). The common roles provide boiler plate wiring (e.g. vars, handlers, and task workflow) that instills the convention and reduces redundancy. Everything is separated via tags into either a “prepare” phase, and a “deploy” phase.
Anyway; as part of this we also have written playbooks that generate new (application) roles, handling the tie-in with the common role functionality. In the past we used shell scripts to aid in the creation and execution of playbooks. A big part of this was to remember values passed to playbooks via --extra-vars…
[TL;DR]
I thought it would be nice to do entirely away with complicated shell scripts; and to extend ansible’s vars_prompt functionality with the ability to remember values that were passed in to prompted variable. It could be as feature-full as a history (allowing up, down arrow keys to cycle through history), or as simple as leaving the value blank to use the last value. Any consensus around this?
Playbooks to generate roles feels a bit too meta to me (or too inverted), unless I’m misunderstanding the purpose.
I will say Ansible when Galaxy comes out will have a CLI command to generate the scaffolding of a new role, but you seem to be discussing something a bit deeper?
Help me understand more perhaps?
Also to be clear, Galaxy content is going to be 100% free.
But yeah, you can think of it as an iTunes or BeerAdvocate for Ansible role content, backed heavily by github, with a package manager for getting beer^W roles.
Playbooks to generate roles feels a bit too meta to me (or too inverted), unless I’m misunderstanding the purpose.
Roles consist of a ton of boiler plate code; e.g.
mkdir -p roles/$role/tasks roles/$role/vars roles/$role/handlers
template-out tasks:/roles/$role/tasks/main.yml
template-out vars:/roles/$role/vars/main.yml
etc. etc.
All I am saying is I use an ansible playbook to create strucute and populate according to vars that I prompt for. Think it’s natural for this so we all speak “1 language”.
My feature idea was to have interactive history added to prompted for by vars_prompt
But yeah, you can think of it as an iTunes or BeerAdvocate for Ansible role content, backed heavily by github, with a package manager for getting beer^W roles.
Good thing it’s winter and we can now move to stouts… Saison’s doing the damage 
!
We talking GPL or BSD role content?
Since roles are mostly content, I was figuring a CC- license would be more appropriate, but there is a field in the metadata for specifying the license.
“My feature idea was to have interactive history added to prompted for by vars_prompt”
I’ll say right now that I’m not going to add this, lots of people would not want this history, and vars_prompt can be used to prompt for sensitive items. Seems like a lot of code for something not many would use.
You could of course implement your own by way of a lookup plugin that only runs against localhost.