tools for building cloud images in the buildsystem

[Seth Vidal]

> 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