> > > >> What I mean is: when I build a package for Fedora, I go through the Koji >> build system. I can't just kludge up a binary RPM and have it get sent >> out >> into the mirror. And, anyone can go into Koji and see the packages I've >> built -- and see how they were built, if they want. And although the GPG >> package signing process is also a black box to some degree, Bodhi gives >> pretty good transparency into the path an update takes. > > They can see what happened, they may not actually be able to get the > pkg... We don't keep pkgs forever. > > > >> This isn't just good for distribution security, but it's also good for >> repeatability, and it's convenient for me as a packager. I want all of >> that >> for the cloud images. Any (technically-minded) end user should be able >> to >> work back from the image checksum to the actual build logs. > > For purposes of repeatability it seems like you just need: > 1. the pkgs+checksums on the system you are running ami-creator from > 2. the pkgs+checksums used in the ami-creation itself. > 3. the set of pkgs+checksums available at creation time > > All of the above mock stores now. > > >>> 'known clean'? What kind of clean do you want? If we use a new >>> instance to build a new image is that clean enough? I'm certain I >>> could do all of it in a single ansible playbook: spin up a new >>> instance in euca, attach a set of disks, run ami-creator, retrieve >>> the results. It's not very difficult at all, actually. >> >> Yes that kind of clean. > > > This is, ultimately, the same process we're using for spinning up build > instances for coprs. > > > After this week, hopefully, if you want some help setting this up for your > ami-creator runs I can help. It's really not difficult at all anymore. > > > >> I think: >> >> * all input to the build command should be recorded >> - save exact command-line arguments > > - wouldn't be any command line arguments at all, I hope. > >> - either collect the kickstart file provided or require it to be pulled > > - exactly - also I'm not sure why it should NOT go into the created > img > itself in /root or some other path. > >> * checksums of the output should be generated and recorded > > not sure where you want to record them - but that's a detail. > > > >> * no opportunity for the person doing the build to write anything into >> the >> build process while it's in progress, and no opportunity to alter the >> above records. > > > There's always an opportunity. If you can spin up an instance you can also > get to that instance. Otherwise you wouldn't be able to run ami-creator > sensibly. > > > But whereever we decide to draw the line - storing the state information > is not very hard (or even very large) > >> does that seem sound? Also build logs should be stored, but that's more >> for >> information, debugging, and convenience than anything else. > > again - stored where? > > >> If the person doing the build normally has admin access on Fedora build >> systems, they shouldn't on this one. Trust but verify and all that. > > this criteria may be tricky... There's just not that many of us. > Plus a lot of the releng people like kevin and dgilmore are in sysadmin-main which has admin access everywhere. > -sv > > _______________________________________________ > infrastructure mailing list > infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/infrastructure _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
