New cli

Glossary
The glossary here attempts to be more precise than the existing one. It would be used thoroughly in this blueprint:
resource
A single deployable configured unit.
resource spec
A configurable, reusable source of a resource. A resource without inputs.
deployment engineer
A person that is using third-party resource specs to create a complete the resource.
resource spec maintainer
A person that creates and maintains resource specs
action file
The file that is directly responsible for handling the action
file template
A template for a file that should be uploaded to node
script
A non-template file that should be uploaded to node

Scenarios

Creating a new resource spec.
The resource spec maintainer issues:
$ solar spec new nginx
Creating new type nginx...
Select handler for your spec:
handler> puppet
What configurable parameters do you want?
name > host
schema (str!) >
value >
name > port
schema (str!) >
value >
Additional actions?
action >
Creating meta file...
Creating action files...
Every point of this interactive would have it's counterpart in a command line parameter. Also every invalid response should be handled with a short, easy to read message and should never abort the process.
After this action we should have a ready directory tree:
* - nginx
    |
    * - 1.0.0
        |
        * - meta.yaml
        * - actions
            |
            remove.pp
            run.pp
            update.pp
The meta.yaml should already contain:
handler: puppet
version: 1.0.0
actions:
    remove: remove.pp
    run: run.pp
    update: update.pp
input:
    -
        name: host
        schema: str!
        value:
    -
        name: port
        schema: str!
        value:
The action files can contain a sample puppet service/package with correct ensure parameter.
The only thing the maintainer needs to do by hand here is to create the puppet manifests.

Managing the resource
There should be at least these commands:
$ solar spec newaction
$ solar spec rmaction
$ solar spec newinput
$ solar spec rminput
$ solar spec newtemplate # adds file template
$ solar spec rmtemplate
$ solar spec newscript # adds a script
$ solar spec rmscript
If the template renderers allow, we could also think about a command to parse the templates and action files and detect the inputs needed.

Version control
We can create our own simple version control like this:
$ solar spec newversion 1.0.0
Another option is to use other version control like git, but only on the dev level. On system level, the resource specs will be added in directories.

Creating new deployment
$ solar composer new openstack
Creating a new solar composition...
What resources do you want to create?
spec> xyz/nginx
Give ID to the resource
id (nginx)> nginx1
Provide value for `host`:
value> 127.0.0.1
Provide value for `port`:
value> 80
Autocompletion would be extremely important in this interactive tool. The names of resource specs should be autocompleted. The values for inputs should be validated.

Creating single resources
Creation of single resources should be similar to creation of composer files. It should differ only in the fact that there are is than one resource added in the first case. Besides it should give exactly the same UX.

Reversions
Reverting the following operations should be always available:
Creation of resource (remove should work with undeployed resources too)
Input updates (reset to the previous value)
Connections (also reset)
+Removal (unremove or reset)