Open Stack

Hi team,
After several discussions i want to propose generic format
for describing deployment tasks, this format is expected to cover
all tasks (e.g pre-deployment and post-deployment), also it should cover
different actions like upgrade/patching

action: upload_file
id: upload_astute
roles: *
parameters:
    input: $.data - this is internal mistral thing
    timeout: 50

action: tasklib
id: generate_keys
stages: [pre-deployment]
roles: master
parameters:
    timeout: 60
    command: generate/keys
    type: puppet
    manifest: /etc/puppet/manifests/key_generator.pp

action: tasklib
id: rsync_puppet
stages: [pre-node]
requires: [upload_astute]
parameters:
    timeout: 100
    command: rsync/stuff
    type: shell
    cmd: python rsync.py

action: tasklib
id: ceph
roles: [ceph-osd, ceph-mon]
requires: [rsync_puppet]
parameters:
    timeout: 100
    command: deployment/ceph
    type: puppet
    manifest: /etc/puppet/manifests/ceph.pp

action: tasklib
id: glance/image
roles: [controller, primary-controller]
stages: [post-deployment]
parameters:
    timeout: 100
    command: deployment/glance/image
    type: shell
    cmd: python upload_image.py

Let me provide some clarifications:
1. As example, we want to generate keys strictly before deployment, and the
1st way to solve
it is to introduce concept of stages, e.g pre-deployment, main, upgrade,
post-deployment.
Another one would be to use virtual roles and/or virtual tasks like
deployment_started, deployment_ended.
We need to consider both, but stages it is what we are using now, and i am
just trying to generalize and make it data-driven.
2. Another internal thing is roles. As you can see in this configs there is
2
specific keywords for roles:
    * - means task should be executed on all roles
    master - task should be only executed on fuel master node
All other roles should be entities from fuel. If you know other exceptions
- lets discuss them.

I would like to ask team for 2 things:
1. Examine approach and ask questions about any specific tasks, in order to
test
this approach for sanity.
2. If you think that some of the keywords in configuration is not
appropriate, lets discuss it. For example we can not agree on term "stage",
because it is too widely used and basically we need another one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/e934d390/attachment.html>