Page MenuHomePhabricator

Sequential execution should be per-deployment, not per-phase
Closed, ResolvedPublic

Description

Scap supports limiting the number of hosts on which the operations are executed. However, that is interpreted on a stage bases, not overall. For example, given 10 deployment targets and batch_size: 1, Scap will execute each phase sequentially (for each of the 10 hosts) before proceeding to the next stage. However, the expect outcome should be for Scap to execute the complete deployment for one host, i.e. execute all of the phases, before proceeding to the next one.

Event Timeline

mobrovac created this task.Aug 15 2016, 1:40 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 15 2016, 1:40 PM
dduvall added subscribers: thcipriani, dduvall.EditedAug 15 2016, 5:32 PM

(Following up on @thcipriani's suggestion in our meeting to rename this to group_size, but with some explanation of how we might implement this internally.)

I think Scap supports this to some extent already via server_groups. All stages are executed over each group in a serial fashion, so if you wanted to deploy fully to each of the 10 targets in the given example, you would define one group per target host.

server_groups: one, two, three, ...
one_dsh_targets: /etc/dsh/group/one
two_dsh_targets: /etc/dsh/group/two
...

We could make this easier by supporting a per-group parameter that internally splits the group by a given size, resulting in the behavior you're describing but without the extra steps of manually defining separate groups.

server_groups: canary, main
canary_group_size: 1

In this example, if there were 10 canary hosts, each one would be represented internally by a single group (canary-1, canary-2, canary-3, etc.) and all stages of the deployment would be executed over each host in a serial fashion.

dduvall claimed this task.Aug 15 2016, 5:49 PM
dduvall triaged this task as High priority.
dduvall moved this task from Needs triage to Services improvements on the Scap board.

We could make this easier by supporting a per-group parameter that internally splits the group by a given size, resulting in the behavior you're describing but without the extra steps of manually defining separate groups.

server_groups: canary, main
canary_group_size: 1

+1, yes, please, let's introduce (canary_)?group_size. There are 40+ Parsoid and 25+ RB hosts, so defining one-by-one groups manually is pretty cumbersome and error-prone.