#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.
>
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/44#comment:11>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
