1 |
On 02-04-2009 20:32:21 +0000, ethankhall@×××××.com wrote: |
2 |
> Online Image Builder |
3 |
> |
4 |
> Objective: To provide the ability for the Gentoo users to have |
5 |
> installable images built by a web server that would contact them when |
6 |
> it was ready to be downloaded. |
7 |
> |
8 |
> Abstract: Using example front ends create a way to deliver a generic |
9 |
> Gentoo system without having to have a user there to do the |
10 |
> installation. The delivery would then be provided in several formats |
11 |
> (zip, tar.bz, bootable iso). The user would be expected to install |
12 |
> their own kernel, a genkernel will be shipped with the installation |
13 |
> image but will not be suitable for every user so they *should* go and |
14 |
> recompile it with their own options. |
15 |
|
16 |
Just in case you don't have enough work. The "prefix" files on |
17 |
tinderbox.d.g.o do not come with a kernel or libc, as they are no |
18 |
standalone systems. Though you still can build an image out of them, |
19 |
mounted/extracted to a given place (/var/tmp?). They are even |
20 |
unprivileged by default, so no root rights involved. |
21 |
|
22 |
> Deliverable's: |
23 |
> |
24 |
> • A website (in PHP or Python) with the ability to take orders from |
25 |
> users, que them, and notify users when their build is ready to be |
26 |
> downloaded. |
27 |
|
28 |
Do you think of AJAX based strategies, or e.g. notification per e-mail |
29 |
for busy times? It's a waste if a user reloads or never picks up the |
30 |
generated image that hold up others in your queue, of course. |
31 |
|
32 |
> • User documentation in an easy to understand format. |
33 |
> • A modular design so new things can be put into place with ease. |
34 |
> • A generic base system for x86 and amd64 (server and desktop of |
35 |
> each). |
36 |
> |
37 |
> |
38 |
> Timeline: |
39 |
> May 10th - 24th: |
40 |
> |
41 |
> • Get a standard set of use flags that will be applied to every |
42 |
> package (will be different for each system). |
43 |
|
44 |
USE-flags are not really within your control, IMO. You can only use the |
45 |
USE-flags as used in each individual binpkg. The most you can do is to |
46 |
suggest default USE-flags for the builders. In that area I see some |
47 |
opportunities to spend some time, since you'll have to trade-off |
48 |
usefullness of a package against how many you're going to need (and |
49 |
possible unwanted features/dependencies). Nice example is PHP which |
50 |
might not be really usefull with most flags turned off. |
51 |
|
52 |
> • Get a standard set of packages that will be installed on each |
53 |
> system. |
54 |
|
55 |
@system perhaps? |
56 |
|
57 |
> • Decide on standard CFLAGS to be used, most likly CFLAGS="-O2 -march |
58 |
> =i686 -pipe" |
59 |
|
60 |
You will *have* to use very modest flags since you target a generic |
61 |
arch. So your example is fine, I think catalyst/portage-make.conf comes |
62 |
with some sane defaults for the other arches. |
63 |
|
64 |
> • Begin work on Python script to do the install. |
65 |
> • Decide what platform will do the building. |
66 |
|
67 |
Something fast, probably x86_64 ;) |
68 |
|
69 |
> May 24th - June 8th: |
70 |
> |
71 |
> • Have Python script done and work on debugging it. |
72 |
> • Have the finalized set of packages that will be available to be |
73 |
> installed though the online tool. |
74 |
|
75 |
Doesn't that depend on what is available to you (or what you can get |
76 |
built) |
77 |
|
78 |
> • Begin work on the que system. |
79 |
> • Begin front end mock up/decide what mock up to use. |
80 |
> |
81 |
> June 8th - June 22nd: |
82 |
> |
83 |
> • Do a build via the online (protected) front end and debug w/ que |
84 |
> utility. |
85 |
> • Decide what to include with each delivery. |
86 |
> • Prepare a bootable iso template. |
87 |
> • Have everything that is build saved in a binary form (to save time |
88 |
> for each build). |
89 |
> |
90 |
> June 22nd - 29th: |
91 |
> |
92 |
> • Flex time for unanticipated problems. |
93 |
> |
94 |
> June 29th - July 20th: |
95 |
> |
96 |
> • Have multiple people build systems concurrently(while website still |
97 |
> protected). Test system tax's. |
98 |
> • Work out any bugs on the delivery system's. |
99 |
> • Find and fix system bottlenecks. |
100 |
> |
101 |
> July 20th - August 10th: |
102 |
> |
103 |
> • Have the site open to the gentoo population with a request for |
104 |
> error's that happen on build. |
105 |
> • Fix error's. |
106 |
> • Generate a time from request to delivery time sample. |
107 |
> • Be able to predict (withing an hour or two) when a user's build |
108 |
> will be ready. |
109 |
> • Find and fix system bottlenecks. |
110 |
> |
111 |
> August 10th - Onward: |
112 |
> |
113 |
> • Improve delivery system. |
114 |
> • Find and fix system bottlenecks. |
115 |
> • Fix error's. |
116 |
> • Make build system portable (so it can be taken to different |
117 |
> location ie. university, and have builds done by there servers with |
118 |
> even more customizability). |
119 |
|
120 |
The coolest thing of course would be when you could select a predefined |
121 |
image to be created for your arch, which then allows you to download a |
122 |
preconfigured Gentoo installation that runs the image builder website :) |
123 |
|
124 |
|
125 |
-- |
126 |
Fabian Groffen |
127 |
Gentoo on a different level |