Open Stack

Hi, Dmitry

1) In my opinion, we should not have any hardcoded stages in task list.
These should be virtual roles, that you can use as a vertex in dependency
graph to aggregate and group tasks. Just like it is done in puppet with
anchors.

Also, we may need to look into some meta-data related approach, e.g. using
tagging of tasks, nodes and roles. For example, we could mark rabbitmq,
pacemaker and galera installation with "ha" tags and then use this tag when
specifying dependency for other tasks.

2) Also, we need to use generic approach for dependencies specification:
"before" and "after" for tasks. There is no need to use integer values for
priorities, as all we need to do is just provide an ordered set of tasks -
there is no need for particular numeric values.

3) Regarding roles - role is just an aggregational entity that combines
several tasks

4) Regarding dependency and role keywords: I think, we need to look into
some kind of query language that can satisfy our requirements. E.g., I can
easily imagine a usecase when we need to do some dynamical calculation of
nodes on which to execute the particular task. I think, we could look into
Mistral and Murano projects doing some of the similar stuff and decide
whether their approach fits our needs.  As an example, we may need to
exclude the node being added from a particular set of tasks. Imagine, we
just added a controller. After we deployed it, all we need is to just
update several configs on the nodes and restart/reload particular services,
e.g. haproxy on controllers and nova-compute services on the computes. In
this case, you will need to tag a node with, let's say "new-node" tag and
then exclude it from execution list by using something like
"!tags.include("new-node")"



On Fri, Oct 10, 2014 at 10:21 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/1d8d7cb5/attachment.html>