What makes a spin a Spin?
mmcgrath at redhat.com
Tue Feb 26 14:18:12 UTC 2008
On Tue, 26 Feb 2008, Josh Boyer wrote:
> On Tue, 26 Feb 2008 04:09:30 -0600 (CST)
> Mike McGrath <mmcgrath at redhat.com> wrote:
> > On Tue, 26 Feb 2008, Jeremy Katz wrote:
> > > On Mon, 2008-02-25 at 22:39 -0600, Mike McGrath wrote:
> > > > On Mon, 25 Feb 2008, Josh Boyer wrote:
> > > > > On Mon, 25 Feb 2008 18:19:53 -0900
> > > > > We _are_ dealing with it. Infrastructure was kind enough to provide
> > > > > xen instances for spins to be created on. I'm volunteering to do the
> > > > > actual spin creation. Rel-eng is working out a proposal (which I know
> > > > > various Board members have seen drafts of) for how to handle this.
> > > > >
> > > > Side note about this, if anyone wants to try to get the cd creation
> > > > working in a chroot or via mock it would be greatly appreciated. As it is
> > > > we've got a dedicated i386 and x86_64 machine that just sit there waiting
> > > > for spins, we should be able to do it on the builders.
> > >
> > > If only it were as simple as "get it going in mock". Unfortunately,
> > > with how SELinux policy works in chroots (hint: it affects outside the
> > > chroot), this is pretty non-trivial and is going to require getting
> > > SELinux upstream on-board with allowing contexts to be set which aren't
> > > known by the kernel or per-namespace policy.
> > >
> > That's why I'm asking someone else to do it :) Shouldn't it just work if
> > we just have all the builders in permissive mode? Needless to say
> > maintaining whole machines just to build cd images seems silly, especially
> > for something like SELinux.
> I was under the impression that they were on-demand Xen guests. Is
> this not the case?
They're up right now, and we can take them down, but bringing them back up
they still need updates, maintanence, backups from time to time. And for
what? Because we're making another excuse for SELinux? /me not a fan of
that. There's a right way to make spins, its on the builders in a chroot.
More information about the fedora-advisory-board