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
|
Return-Path: <ick-discuss-bounces@ick.liw.fi>
X-Original-To: distix@pieni.net
Delivered-To: distix@pieni.net
Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221])
by pieni.net (Postfix) with ESMTPS id C131843376
for <distix@pieni.net>; Thu, 30 Aug 2018 15:22:32 +0000 (UTC)
Received: from platypus.pepperfish.net (unknown [10.112.101.20])
by yaffle.pepperfish.net (Postfix) with ESMTP id 93201415BB
for <distix@pieni.net>; Thu, 30 Aug 2018 16:22:32 +0100 (BST)
Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net)
by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian))
id 1fvOmG-0002aQ-Hm; Thu, 30 Aug 2018 16:22:32 +0100
Received: from koom.pieni.net ([88.99.190.206] helo=pieni.net)
by platypus.pepperfish.net with esmtpsa (Exim 4.80 #2 (Debian))
id 1fvOmF-0002aF-KC
for <ick-discuss@ick.liw.fi>; Thu, 30 Aug 2018 16:22:31 +0100
Received: from exolobe3 (62-78-212-250.bb.dnainternet.fi [62.78.212.250])
by pieni.net (Postfix) with ESMTPSA id 221A040529
for <ick-discuss@ick.liw.fi>; Thu, 30 Aug 2018 15:22:31 +0000 (UTC)
Message-ID: <86bf91e609a4e96d53d7eff272be189d589f2ae4.camel@liw.fi>
From: Lars Wirzenius <liw@liw.fi>
To: ick discussions <ick-discuss@ick.liw.fi>
Date: Thu, 30 Aug 2018 18:22:29 +0300
User-Agent: Evolution 3.29.92-1
Mime-Version: 1.0
X-Pepperfish-Transaction: 2fc4-bda7-ec4f-a57b
X-Pepperfish-Transaction-By: platypus
Subject: Federated CI
X-BeenThere: ick-discuss@ick.liw.fi
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: discussions about the ick CI system <ick-discuss-ick.liw.fi>
List-Unsubscribe: <https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi>,
<mailto:ick-discuss-request@ick.liw.fi?subject=unsubscribe>
List-Archive: <http://listmaster.pepperfish.net/pipermail/ick-discuss-ick.liw.fi>
List-Post: <mailto:ick-discuss@ick.liw.fi>
List-Help: <mailto:ick-discuss-request@ick.liw.fi?subject=help>
List-Subscribe: <https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi>,
<mailto:ick-discuss-request@ick.liw.fi?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8348942345006944693=="
Mime-version: 1.0
Sender: ick-discuss-bounces@ick.liw.fi
Errors-To: ick-discuss-bounces@ick.liw.fi
--===============8348942345006944693==
Content-Type: multipart/signed; micalg="pgp-sha512";
protocol="application/pgp-signature"; boundary="=-1eQMbzR54IKbfTBNQXA2"
--=-1eQMbzR54IKbfTBNQXA2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
(Also posted as https://blog.liw.fi/posts/2018/08/30/federated_ci/ if
that's easier to read.)
In the modern world, a lot of computing happens on other people's
computers. We use a lot of services provided by various parties. This
is a problem for user freedom and software freedom. For example, when
I use Twitter, the software runs on Twitter's servers, and it's
entirely proprietary. Even if it were free software, even if it were
using the Affero GPL license (AGPL), my freedom would be limited by
the fact that I can't change the software running on Twitter's
servers.
If I could, it would be a fairly large security problem. If I could,
then anyone could, and they might not be good people like I am.
If the software were free, instead of proprietary, I could run it on
my own server, or find someone else to run the software for me. This
would make me more free.
That still leaves the data. My calendars would still be on Twitter's
servers: all my tweets, direct messages, the lists of people I follow,
or who follow me. Probably other things as well.
For true freedom in this context, I would need to have a way to
migrate my data from Twitter to another service. For practical
freedom, the migration should not be excessively much work, or be
excessively expensive, not just possible in principle.
For Twitter specifically, there's free-er alternatives, such as
Mastodon.
For ick, my CI / CD engine, here is my current thinking: ick should
not be a centralised service. It should be possible to pick and choose
between instances of its various components: the controller, the
workers, the artifact store, and Qvisqve (authentication server).
Ditto for any additional components in the future.
Since users and the components need to have some trust in each other,
and there may be payment involved, this may need some co-ordination,
and it may not be possible to pick entirely freely. However, as a
thought experiment, let's consider a scenario.
Alice has a bunch of non-mainstream computers she doesn't use herself
much: Arm boards, RISCV boards, PowerPC Macs, Amigas, etc. All in good
working condition. She'd be happy to set them up as build workers, and
let people use them, for a small fee to cover her expenses.
Bettina has a bunch of servers with lots of storage space. She'd be
happy to let people use them as artifact stores, for a fee.
Cecilia has a bunch of really fast x86-64 machines, with lots of RAM
and very fast NVMe disks. She'd also be happy to rent them out as
build workers.
Dinah needs a CI system, but only has one small server, which would
work fine as a controller for her own projects, but is too slow to
comfortably do any actual building.
Eliza also needs a CI system, but wants to keep her projects separate
from Dinah's, so wants to have her own controller. (Eliza and Dinah
can't tolerate each other and do not trust each other.)
Fatima is trusted by everyone, except Eliza, and would be happy to run
a secure server with Qvisqve.
Georgina is like Fatima, except Eliza trusts her, and Dinah doesn't.
The setup would be like this:
* Alice and Cecilia run build workers. The workers trust both Fatima's
and Georgina's Qvisqves. All of their workers are registered with
both Qvisqves, and both Dinah's and Eliza's controllers.
* Bettina's artifact store also trusts both Qvisqves.
* Dinah creates an account on Fatima's Qvisqve. Eliza on Georgina's
Qvisqve. They each get an API token from the respective Qvisqve.
* When Dinah's project builds, her controller uses the API token to
get an identity token from Fatima's Qvisqve, and gives that to each
worker used in her builds. The worker checks the ID token, and then
accepts work from Dinah's controller. The worker reports the time
used to do the work to its billing system, and Alice or Cecilia uses
that information to bill Dinah.
* If a build needs to use an artifact store, the ID token is again
used to bill Dinah.
* For Eliza, the same thing happens, except with another Qvisqve, and
costs from he builds go to her, not Dinah.
This can be generalised to any number of ick components, which can be
used criss-cross. Each component needs to be configured as to which
Qvisqves it trusts.
I think this would be a nicer thing to have than the centralised
hosted ick I've been thinking about so far. Much more complicated, and
much more work, of course. But interesting.
There are some interesting and difficult questions about security to
solve. I don't want to start thinking about the details yet, I'll play
with the general idea first.
What do you think?
--=-1eQMbzR54IKbfTBNQXA2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAluIC7UACgkQbC+mFux6
IDFNyBAAwR7rsZZxKXEHxPJA45KMeirHPcvPQNUxTEjKLWDh4te/vKZTYK/eGUrD
l2WV/C5ZqwTieXCjEM0ke9Mxr5p9WY1VICp6Elq6yPob3zxKhrq4dULH2UknS4m3
aEChP42GPtomfsbOgp9Y1z7hksfpiH8LpyJh6Og73E/5oJQERDKPAX8X62RL+eud
H6qX3VVkFu/dWDEuEdHDY67A40TtvPPe/Kg2dcWn8KVSQLsOsA0DhWqCwpTU5luo
/4H/6O16wNTN2V/rKt/dtXvl/uNrDQX3QPMdI6oyACr59oZ95NohgXMo6rfhr0X3
SLcpyNCScS1BRWu50YuLogJMV66zAtqIjHaawIysynzcAFsi8zDbMDNu3mhJAFpQ
3iXEIsxJlJOnAd9Gcf6MRBE8g3fx38lgJq5SjLJTIXSPn28AM5LUf+nPdTiAxEgw
C0coksHF2Rjjl3BLdTa3dOoLEkUNJKbJNQHJYcJ3PqTA6ZhMgfep7hRWl35I/1h8
lLpiUWANl5ciAZgVGy5mIeGC05HjXCYZM0k3+ahlaciv8rnV0k/JieE8XSpN4rR9
2dXLrf07jUqcZw2VQr2Lz98EwPhG0JIRFMk/UyoBtROuJuYAOUeeqWujTDF6XlsD
l0vdO1nOe+eGrf9BIc/axzmnH/KLfhdYH73Mst/79Iue23z0wqw=
=Mgz3
-----END PGP SIGNATURE-----
--=-1eQMbzR54IKbfTBNQXA2--
--===============8348942345006944693==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
ick-discuss mailing list
ick-discuss@ick.liw.fi
https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi
--===============8348942345006944693==--
|
