This is a very long-standing request. Here is a ticket for it. :)
Oh. Fair enough! I'm building one now using this method...
https://ttboj.wordpress.com/2014/01/20/building-base-images-for-vagrant-with-a-makefile/
and this patch:
https://github.com/purpleidea/puppet-gluster/commit/e6f0bc559802abae16e06c79062f1910538fbedd
Should be ready once I get on fast internet...
Awesome!
Eventually, it'd be awesome if this would automatically fall out of the release engineering process. But let's start with whatever we can get :)
Replying to [comment:2 mattdm]:
Awesome! Eventually, it'd be awesome if this would automatically fall out of the release engineering process. But let's start with whatever we can get :)
LOL, well you are all welcome to use my scripts-- they're all "open source", but I'd rather not be the guy plugging it into release engineering. I'm happy to run "make" on my laptop whenever someone asks for a new build though.
Currently uploading, but wholly untested. Not even once!
In about two hours this should be downloadable. (Make sure the sha256sum matches!)
https://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-20/
After I get some sleep, I'll test this as soon as I can.
HTH
A few issues with that script:
Now there are two approaches.
1) Anaconda + kickstart I think this is probably the way to go, particularly as it would allow us to include Vagrant-specific content. 2) Mutate an existing qcow2 (e.g. the cloud image) For the latter, see: https://github.com/cgwalters/rpm-ostree-autocompose/commit/55af81ff04afb24429616ccb2c67b408e3a7e364 for an approach which injects a systemd unit file, rather than attempting to change the target from the outside. The advantage of this is that way we pick up the SELinux policy from the target.
Not sure how virt-builder is involved here? In any case note that virt-builder will use existing cloud images, but someone has to provide an index file (https://fedorahosted.org/rel-eng/ticket/5805)
Replying to [comment:5 walters]:
A few issues with that script: Disabling SELinux is obviously not something we can ship with Agreed. I actually forgot about this... I think it was something that was needed by vagrant boxes at some point. Easy to change this. (one-liner). virt-builder is a useful tool, but rwmjones's website is not maintained by releng. It's not going to work to bounce content to his site and then have releng download it again I agree! I do think it makes sense to build upon existing tools where appropriate. This way we have fewer different initial ways to build a base image. For the releng requirements, I'm pretty sure rwmjones tools can point at a different repo, and even work fully "offline". You typically need to set the /etc/virt-builder/repos.d/<something>.conf file to whatever you want. rwmjones is probably a great resource for info on how to build his template .xz files. Now there are two approaches. 1) Anaconda + kickstart I think this is probably the way to go, particularly as it would allow us to include Vagrant-specific content. 2) Mutate an existing qcow2 (e.g. the cloud image) For the latter, see: https://github.com/cgwalters/rpm-ostree-autocompose/commit/55af81ff04afb24429616ccb2c67b408e3a7e364 for an approach which injects a systemd unit file, rather than attempting to change the target from the outside. The advantage of this is that way we pick up the SELinux policy from the target.
Disabling SELinux is obviously not something we can ship with Agreed. I actually forgot about this... I think it was something that was needed by vagrant boxes at some point. Easy to change this. (one-liner).
virt-builder is a useful tool, but rwmjones's website is not maintained by releng. It's not going to work to bounce content to his site and then have releng download it again I agree! I do think it makes sense to build upon existing tools where appropriate. This way we have fewer different initial ways to build a base image. For the releng requirements, I'm pretty sure rwmjones tools can point at a different repo, and even work fully "offline". You typically need to set the /etc/virt-builder/repos.d/<something>.conf file to whatever you want. rwmjones is probably a great resource for info on how to build his template .xz files.
I actually prefer my makefile/virt-builder approach, but I obviously am fine with other people working on different methods.
I figured I'd step up to help with this, since it was apparently a "very long-standing request". I'm happy to continue to generate these Fedora vagrant boxes, and I think it makes sense to use this, even "officially" since it works now, and nobody for a while seemed to be doing this.
I should mention, working on this isn't really my "prime directive", so more than I anything I was trying to be helpful so that I have beverage or bug karma with mattdm :P
Cheers
Replying to [comment:7 rjones]:
Virt-builder being involved is my fault, sorry. It happened when I decided that I liked your tools enough to integrate them in my other projects. See:
For more details.
Replying to [comment:8 purpleidea]:
Easy to change this. (one-liner).
I'm not so sure it's that easy. The problem I hit with using libguestfs for this sort of stuff is that you really need to be sure the SELinux label of critical files like /etc/passwd is set. It's hard to do that from the outside - doing it inside the system on boot means we use the target policy.
The makefile versus shell versus javascript or whatever is mostly a red herring I think. The issue I see is more the second part - the semantics around how we change the contents of the target system.
I figured I'd step up to help with this, since it was apparently a "very long-standing request".
Definitely! Do you have some bandwidth to work on this/continue the conversation here?
There are a few aspects to this:
1) Content definition - what packages are installed? 2) Partition layout 3) System default configuration (vagrant user, vagrant ssh keys, sudo)
To me, Anaconda+kickstart files are the thing to use for #1 and #2. In other words we're just talking about another Fedora Cloud type image, except with Vagrant as the "hypervisor".
For #3, kickstart files are probably also the way to go. My script was just a hack because I didn't have ostree support in Anaconda, but now I do.
There's a general question here about anaconda versus virt-builder; when should you "rebuild" versus "post-customize". To me the answer comes down to the package set. If for example we wanted different packages in the Vagrant image, then it would need to be an Anaconda rebuild.
Replying to [comment:10 walters]:
Replying to [comment:8 purpleidea]: Easy to change this. (one-liner). I'm not so sure it's that easy. The problem I hit with using libguestfs for this sort of stuff is that you really need to be sure the SELinux label of critical files like /etc/passwd is set. It's hard to do that from the outside - doing it inside the system on boot means we use the target policy.
Agreed... but, I do do it inside. :) https://github.com/purpleidea/puppet-gluster/blob/master/builder/Makefile#L83
I'm not sure if this is now equivalent to the new --selinux-relabel flag for virt-builder. If it is, we can simplify this.
I actually prefer my makefile/virt-builder approach, but I obviously am fine with other people working on different methods. The makefile versus shell versus javascript or whatever is mostly a red herring I think. The issue I see is more the second part - the semantics around how we change the contents of the target system. I figured I'd step up to help with this, since it was apparently a "very long-standing request". Definitely! Do you have some bandwidth to work on this/continue the conversation here?
To be honest, not a lot, actually. If it would help, I will be in Westford next week, and I am happy to meet if you want to hack on this, or iterate quickly over some of the ideas.
There are a few aspects to this: 1) Content definition - what packages are installed? 2) Partition layout 3) System default configuration (vagrant user, vagrant ssh keys, sudo) To me, Anaconda+kickstart files are the thing to use for #1 and #2. In other words we're just talking about another Fedora Cloud type image, except with Vagrant as the "hypervisor". For #3, kickstart files are probably also the way to go. My script was just a hack because I didn't have ostree support in Anaconda, but now I do. There's a general question here about anaconda versus virt-builder; when should you "rebuild" versus "post-customize". To me the answer comes down to the package set. If for example we wanted different packages in the Vagrant image, then it would need to be an Anaconda rebuild.
So, I must say, that I love Anaconda for it's use case, however in general, it's the reason that virt-builder and vagrant are so useful. The vagrant user or really most people (IMO), don't want to have to muck around with getting every anaconda setting right... If I can build this on top of an already built base image, then there is less chance for error. IOW, I'm glad Anaconda exists, but I want to use it as little as possible.
What OS image can't you build with virt-builder? I don't know that it does anything to the template that can't be properly fixed with --flags to virt-builder... And it's easy :)
As a side note, these comments might not make much sense in light of some of the os-tree stuff you're doing, but I'm not up to speed on all the specifics, so my commentary assumes that stuff doesn't exist. My bad if that's the case.
One issue with building a vagrant image (at least for the default virtualbox provider), is that the guest additions are kernel modules that aren't upstream, so can't be included in fedora (as far as I am aware).
Agreed. Which is another reason why I built everything on vagrant-libvirt which has nothing to do with virtualbox.
When need help packaging upstream vagrant with vagrant-libvirt. If anyone can help out who has RPM+Ruby skills, it would be much appreciated!
Closing this ticket as part of trac clean up process. If you want to reopen, please reopen it after we move to pagure.io as atomic-wg.
Login to comment on this ticket.