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.
-sv
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
