tools for building cloud images in the buildsystem

Nick Bebout nick at bebout.net
Tue Nov 13 02:22:17 UTC 2012


>
>
>
>> 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure




More information about the infrastructure mailing list