#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by purpleidea):

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...

#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by purpleidea):

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.

#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by walters):

A few issues with that script:

* Disabling SELinux is obviously not something we can ship with * 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

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.

#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by rjones):

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)

#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by purpleidea):

Replying to [comment:7 rjones]:

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)

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:

https://ttboj.wordpress.com/2014/01/20/building-base-images-for-vagrant- with-a-makefile/

For more details.

#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by purpleidea):

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.

#44: hey we should have a vagrant base box --------------------+--------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | --------------------+---------------------

Comment (by purpleidea):

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!