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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
production monitor
===================
Should branch rather than mount the byoc and secrets branches.
refine launchpad ballot
=======================
byoci should check that a review specifically asked by the dev to a member
of the review team counts as a review from the review team.
Launchpad count the asked-for review as a different one and leave the
team-needed review pending. Strictly counting the launchpad votes leads to
the situation where the approved MP is not landed for lack of votes.
From the dev point of view, this is frustrating, the reviewer was chosen
because he is the expert so his vote counts more than one from another team
member, yet, the MP is not landable.
the identity provider used by jenkins needs a better design
===========================================================
sso was hidden behind launchpad until now. It's now clearer that it's mostly
a jenkins requirement (gicing at least read access to all devs) and to a
lesser extent needed for the landing bot (access to code bases and artifacts
servers).
tests
=====
Implementing tests for monitor commands highlighted a nasty issue: some code
(and its tests) requires dependencies. Those dependencies are specific to
each vm. So far, all tests (including the slave ones) have been adapted to
run on the host because the dependencies align (so far). This isn't true for
monitor nor master where tests (so far) have been against vms from the host.
Finally, test execution should be aligned too, including running them from
the host in a user provided vm (hence the need to make those vms cheap to
start, in turn requiring images (see below) to be provisioned before hand.
launchpad parametrization
-------------------------
As explained in byoci/tests/slave/features.py for 'launchpad_token', tests
should be parametrized against production and qastaging. Yet, because
qastaging has been in bad shape (and as such unsuable for tests) for an
extended period of time, tests are now running against production only.
images
======
Images should be defined for monitor, master and slave.
This requires defining a workflow to build them and take them into account
in the variants (production, testing, selftest). This will allow some
optimizations for several tests and also open the door to running tests
inside the vms. This ability to run tests inside vms is needed to not force
installing the vm test dependencies on the host itself (which is asking for
trouble ;).
all
===
* Support different kind of branches between host and guests:
* pulled public branch: DONE
* client knows server ssh key
* 'definition=dir', 'definition.branch=url'
* create: bzr branch
* update: bzr pull
* pushed public branch: ?
* server is ssh authorized on client
* 'definition=dir', 'definition.branch=url'
* create: bzr push
* update: bzr push and update
* bound branch:
* client knows server ssh key
* 'definition=dir', 'definition.bound_branch=url'
* create: bzr branch --bind
* update: bzr pull
* mounted filesystem: DONE
* 'definition=dir', 'host.definition.dir=dir'
* create: nil
* update: nil
* branch with uncommitted changes: BAD IDEA
* create: bzr push-tree
* update: bzr push-tree
This a bad idea as this forbids concurrent tests (they share the working
tree (so they will try to lock it for the temporary commit) and the
fallouts are (too) hard to address).
* The component (monitor, master, slaves) life cycle is [seed,] install,
update. 'seed' used to be required for slaves. Monitor, master and slaves
should follow this cycle (and scripts/hooks renamed accordingly).
ssh slaves
==========
* Consider different unix users for setting up the slave (ubuntu) and
running project jobs (jenkins) ?
* Address FIXMEs in setup/templates/jenkins/start-slave-via-ssh
master setup
============
* Write a script to setup the master that can also be used to upgrade it
(similar to setup/seeded-slave). 'init.groovy.d' should be good enough but
tests are missing. Or implement the install/update described above.
* Use systemd ?
See (or at least track progress at)
https://issues.jenkins-ci.org/browse/JENKINS-41218
* Is a dev group needed to handle workspaces and run jobs ?
* For testing (the namespace), it would be nice if the sso integration was
optional. The dev should already have a user created (via the access
rights setup).
slave setup
===========
* Each slave should create its own byov ssh key to setup/connect to the
containers.
* All slaves should be setup with ssh server public keys from the `secrets`
branch.
project scripts
===============
The scripts under the 'project' directory need to be rewritten in python and
tests written (only detect-changes is left, it's 34 lines long and is
trivial to rewrite).
From the slave it should be possible to::
- wipe a workspace (done)
- setup a tree from a branch/repo in a workspace (done for {bzr,git})
- merge a proposal (done for launchpad)
- commit (done)
- push (done)
- detect changes on a branch (still to do, see above)
In a worker, it should be possible to::
- run a command (including a pipeline), with support for an optional
subunit stream output
This covers current usage::
byo-ci-slave approved-{vcs}-proposals {deps-trunk}
byo-ci-slave land-approved-{vcs}-proposal {trunk} {workdir} {container}
byo-ci-slave run-tests [--output subunit (NIY)] {workdir} {container}
byo-ci-slave setup-{vcs}-tree {trunk} {workspace}/{workdir}
project/detect-changes {jenkins-url} {vcs} {trunk} byoci trigger-{name}-devs-test
commands
========
The following are missing:
* byo-ci-{host,monitor}? update-slave-access
When a slave is added/removed/changed, the master needs to learn how to
connect (or not) to them.
When the master ssh key changes, the slaves need to learn about it.
host
----
byovm {setup,config,shell,teardown} {master,monitor,slave}
monitor
-------
jenkins-job {update,delete} (may be encapsulated once all use cases are clear)
byo-ci-monitor update-{slave,plugins,slave-access}
byo-ci-monitor run-job
slave
-----
byo-ci-slave setup-{bzr,git}-tree
byo-ci-slave approved-{bzr,git}-proposals
byo-ci-slave land-approved-{bzr,git}-proposal
byo-ci-slave run-in-worker
byo-ci-slave run-tests
scenarios
=========
install
-------
./setup/byoci [testing] byoci-install [testing]
./setup/byoci production byoci-install production
updates
-------
byovm setup --force monitor byoci-monitor update
run update-slave job byoci-slave update
./byo-ci-slave update-slave <slave>
|