forked from Yelp/paasta
-
Notifications
You must be signed in to change notification settings - Fork 0
/
paasta_serviceinit.feature
131 lines (118 loc) · 8.55 KB
/
paasta_serviceinit.feature
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
Feature: paasta_serviceinit
Scenario: marathon_serviceinit can run status
Given a working paasta cluster
And I have yelpsoa-configs for the marathon job "test-service.main"
And we have a deployments.json for the service "test-service" with enabled instance "main"
When we run the marathon app "test-service.main"
And we wait for it to be deployed
Then marathon_serviceinit status_marathon_job should return "Healthy" for "test-service.main"
Scenario: marathon_serviceinit can restart tasks
Given a working paasta cluster
And I have yelpsoa-configs for the marathon job "test-service.main"
And we have a deployments.json for the service "test-service" with enabled instance "main"
When we run the marathon app "test-service.main"
And we wait for it to be deployed
Then marathon_serviceinit restart should get new task_ids for "test-service.main"
Scenario: paasta_serviceinit can run status on chronos jobs
Given a working paasta cluster
And we have yelpsoa-configs for the service "testservice" with disabled scheduled chronos instance "testinstance"
And we have a deployments.json for the service "testservice" with disabled instance "testinstance"
When we run setup_chronos_job for service_instance "testservice.testinstance"
Then we should get exit code 0
When we store the name of the job for the service testservice and instance testinstance as myjob
And we wait for the chronos job stored as "myjob" to appear in the job list
Then paasta_serviceinit status for the service_instance "testservice.testinstance" exits with return code 0 and the correct output
Scenario: paasta_serviceinit can run status --verbose on chronos jobs
Given a working paasta cluster
And we have yelpsoa-configs for the service "testservice" with disabled scheduled chronos instance "testinstance"
And we have a deployments.json for the service "testservice" with disabled instance "testinstance"
When we run setup_chronos_job for service_instance "testservice.testinstance"
Then we should get exit code 0
When we store the name of the job for the service testservice and instance testinstance as myjob
And we wait for the chronos job stored as "myjob" to appear in the job list
Then paasta_serviceinit status --verbose for the service_instance "testservice.testinstance" exits with return code 0 and the correct output
Scenario: paasta_serviceinit can run status -vv to tail a mesos task stdout/stderr
Given a working paasta cluster
And I have yelpsoa-configs for the marathon job "test-service.main"
And we have a deployments.json for the service "test-service" with enabled instance "main"
When we run the marathon app "test-service.main"
And we wait for it to be deployed
Then paasta_serviceinit status -vv for the service_instance "test-service.main" exits with return code 0 and the correct output
And paasta_serviceinit status -s "test-service" -i "main" exits with return code 0 and the correct output
And paasta_serviceinit status -s "test-service" -i "main,test" has the correct output for instance main and exits with non-zero return code for instance test
Scenario: paasta_serviceinit can run emergency-stop on an enabled chronos job
Given a working paasta cluster
And we have yelpsoa-configs for the service "testservice" with enabled scheduled chronos instance "testinstance"
And we have a deployments.json for the service "testservice" with enabled instance "testinstance"
When we run setup_chronos_job for service_instance "testservice.testinstance"
Then we should get exit code 0
When we store the name of the job for the service testservice and instance testinstance as myjob
And we wait for the chronos job stored as "myjob" to appear in the job list
And we paasta_serviceinit emergency-stop the service_instance "testservice.testinstance"
Then the job stored as "myjob" is disabled in chronos
And the job has no running tasks
Scenario: paasta_serviceinit can run emergency-start on an enabled chronos job
Given a working paasta cluster
And we have yelpsoa-configs for the service "testservice" with enabled scheduled chronos instance "testinstance"
And we have a deployments.json for the service "testservice" with enabled instance "testinstance"
When we run setup_chronos_job for service_instance "testservice.testinstance"
Then we should get exit code 0
When we store the name of the job for the service testservice and instance testinstance as myjob
And we wait for the chronos job stored as "myjob" to appear in the job list
And we paasta_serviceinit emergency-start the service_instance "testservice.testinstance"
Then the job stored as "myjob" is enabled in chronos
And the job has running tasks
Scenario: paasta_serviceinit can run emergency-start on a disabled chronos job
Given a working paasta cluster
And we have yelpsoa-configs for the service "testservice" with enabled scheduled chronos instance "testinstance"
And we have a deployments.json for the service "testservice" with enabled instance "testinstance"
When we run setup_chronos_job for service_instance "testservice.testinstance"
Then we should get exit code 0
When we store the name of the job for the service testservice and instance testinstance as myjob
And we wait for the chronos job stored as "myjob" to appear in the job list
And we paasta_serviceinit emergency-start the service_instance "testservice.testinstance"
Then the job stored as "myjob" is enabled in chronos
And the job has no running tasks
Scenario: paasta_serviceinit can run emergency-restart on an enabled chronos job
Given a working paasta cluster
And we have yelpsoa-configs for the service "testservice" with enabled scheduled chronos instance "testinstance"
And we have a deployments.json for the service "testservice" with enabled instance "testinstance"
When we run setup_chronos_job for service_instance "testservice.testinstance"
Then we should get exit code 0
When we store the name of the job for the service testservice and instance testinstance as myjob
And we wait for the chronos job stored as "myjob" to appear in the job list
When we set the "cmd" field of the chronos config for service "testservice" and instance "testinstance" to "sleep 60m"
And we paasta_serviceinit emergency-start the service_instance "testservice.testinstance"
And we store the name of the job for the service testservice and instance testinstance as mynewjob
Then the job stored as "myjob" is enabled in chronos
And the job stored as "mynewjob" is enabled in chronos
And the old job has no running tasks
And the new job has running tasks
Scenario: paasta_serviceinit can run emergency-stop on a marathon app
Given a working paasta cluster
And I have yelpsoa-configs for the marathon job "test-service.main"
And we have a deployments.json for the service "test-service" with enabled instance "main"
When we run the marathon app "test-service.main"
And we wait for it to be deployed
And we run paasta serviceinit "stop" on "test-service.main"
And we wait for "test-service.main" to launch exactly 0 tasks
Then "test-service.main" has exactly 0 requested tasks in marathon
Scenario: paasta_serviceinit can run emergency-stop on a marathon app via appid
Given a working paasta cluster
And I have yelpsoa-configs for the marathon job "test-service.main"
And we have a deployments.json for the service "test-service" with enabled instance "main"
When we run the marathon app "test-service.main"
And we wait for it to be deployed
And we run paasta serviceinit --appid "stop" on "test-service.main"
And we wait for "test-service.main" to launch exactly 0 tasks
Then "test-service.main" has exactly 0 requested tasks in marathon
Scenario: paasta_serviceinit can run emergency-scale on a marathon app
Given a working paasta cluster
And I have yelpsoa-configs for the marathon job "test-service.main"
And we have a deployments.json for the service "test-service" with enabled instance "main"
When we run the marathon app "test-service.main"
And we wait for it to be deployed
And we run paasta serviceinit scale --delta "1" on "test-service.main"
And we wait for "test-service.main" to launch exactly 2 tasks
Then "test-service.main" has exactly 2 requested tasks in marathon
# vim: tabstop=2 expandtab shiftwidth=2 softtabstop=2