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
|
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 6670942EEC
for <distix@pieni.net>; Sun, 1 Apr 2018 11:37:11 +0000 (UTC)
Received: from platypus.pepperfish.net (unknown [10.112.101.20])
by yaffle.pepperfish.net (Postfix) with ESMTP id 0B725417C5
for <distix@pieni.net>; Sun, 1 Apr 2018 12:37:11 +0100 (BST)
Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net)
by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian))
id 1f2bIM-0004FR-Vt; Sun, 01 Apr 2018 12:37:10 +0100
Received: from [10.112.101.103] (helo=mx3.pepperfish.net)
by platypus.pepperfish.net with esmtps (Exim 4.80 #2 (Debian))
id 1f2bIL-0004FD-RI
for <ick-discuss@ick.liw.fi>; Sun, 01 Apr 2018 12:37:09 +0100
Received: from mail.steve.org.uk ([176.9.183.102] helo=ssh.steve.org.uk)
by mx3.pepperfish.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steve@steve.org.uk>)
id 1f2bII-0004oH-Cm
for ick-discuss@ick.liw.fi; Sun, 01 Apr 2018 12:37:09 +0100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=steve.org.uk; s=20150726; h=References:In-Reply-To:Message-ID:Date:Subject:
From:Cc:To:Sender:Reply-To:MIME-Version:Content-Type:
Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=tai3oUY8wIGE9uoKrRpALz4Jsr7wkkb9GjT+IeETq9c=; b=R1hOKe5R5wlGuhh2dPlbbc9JF
YdutDBOrrXzIKPLxfxziEs+xlZJV2VC33e21PBJKntu9Xt9WcKbmWeZPpxZ1Phv2K0ja6YD8JGR/A
UOdy8IDgO+kR2JYHgPdmVmeOIIfS+TR34wkd67hOI/pPMNfVmRvdBt0w/33sB5tf8i5zM=;
Received: from steve by ssh.steve.org.uk with local (Exim 4.89)
(envelope-from <steve@steve.org.uk>) id 1f2bI6-0002mi-FH
for ick-discuss@ick.liw.fi; Sun, 01 Apr 2018 11:36:54 +0000
To: ick-discuss@ick.liw.fi
Cc:
From: Steve Kemp <steve@steve.org.uk>
Date: Sun, 01 Apr 2018 11:24:37 +0000
Message-ID: <1522581877.10476.1@ssh.steve.org.uk>
In-Reply-To: <1522571699.2971.5.camel@liw.fi>
References: <1522571699.2971.5.camel@liw.fi>
X-added-header: steve.org.uk
X-Pepperfish-Transaction: a5f2-dac9-60da-1ebe
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Scanned-By: pepperfish.net, Sun, 01 Apr 2018 12:37:09 +0100
X-Spam-Report: Content analysis details: (-1.9 points)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-ACL-Warn: message may be spam
X-Scan-Signature: 3e0b2c8d84541a19cffce3c5c0904f3a
Subject: Re: What's needed before ick is ready for others to use?
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>
Sender: ick-discuss-bounces@ick.liw.fi
Errors-To: ick-discuss-bounces@ick.liw.fi
> This morning I've been pondering on the following question: should I
> try to achieve "ready for others to use" as soon as possible, or
> should I concentrate on making sure all existing functionality is of
> high quality?
I think there are pros and cons to either approach, but one thing
that I'm struggling with myself is the documentation.
I would love to see an overview of all the moving parts:
* There is one ick-server / controller.
* This is what it needs
* This is how you configure it.
* There is one artifact server.
* This is what it needs.
* This is how you configure it.
* There are N-workers / worker-managers.
* This is what they need.
* This is how you configure them.
Right now I've spent more time than I'd enjoy getting the
package(s) installed - in the end I resorted to your debian repository
but even that wasn't sufficient.
Getting the artifact-server running, for example, required installation
of `python3-requests`. There was also some confusion about
`python-cliapp` being a dependency, but the code using `python3-cliapp`,
the latter of which couldn't be installed without forcing, as it
overwrote a file in the previous package.
The ansible role helps, but the random start-scripts in the top-level
are a distraction.
> I am leaning towards the former. Perfectionism is good, but it makes
> things take a really long time and if things take too long, I get de-
> motivated. "Write shit, but fix it quickly."
> What do you all think? Is there something you can think of that ick
> must do before you'd be willing to give it a try?
I think your list is good, but I'd add documentation. Right now
I suspect there is a security problem with the artifact server, but
despite reading the architecture guide I'm missing the ability to
confirm it.
I suspect these requests are both problems:
GET /blobs/../../../etc/passwd
PUT /blobs/../../../etc/owned
But the GET/PUT both require authentication that I don't know how
to handle.
Looking at `blob_store.py` we see the code mostly boils down to:
prefix + name
Where name is user-submitted. But of course I might be missing
the obvious, maybe bottle is filtering ahead of this code. If that
is the case then things are probably OK, but there is an obvious
design-decision: Should names be unique? If two jobs both upload
an artifact called "latest-amd64.tar.gz" what happens? Should
uploads be namedspaced on job? Or should the second artifact upload
fail?
Steve
--
https://www.steve.org.uk/
_______________________________________________
ick-discuss mailing list
ick-discuss@ick.liw.fi
https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi
|
