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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
