On Wed, Aug 20, 2014 at 3:18 AM, Nick Coghlan <ncoghlan(a)redhat.com> wrote:
----- Original Message -----
> Excerpts from Amit Saha's message of 2014-08-20 14:04 +10:00:
> > 1. If we do not allow selecting the base image, we are effectively
> > *not* obeying
> > the distro selection in the job unless of course both are the same.
>
> Right, so I think there are just two parameters which were hardcoded in
> your experiment but which need to be adjustable if we implement the
> feature for real: Docker base image to run the harness inside of (e.g.
> fedora/20), and Docker registry URL to pull from (expectation being that
> the user will supply a lab-local one to avoid pulling huge images over
> the WAN).
>
> To begin with we could just have ksmeta variables for those both. It's
> not great (no way to automatically pick a local registry automatically
> for each lab, no way to make Beaker pick the right distro using filter
> criteria like <distroRequires/>, etc) but it would be okay as a first
> cut.
+1 from me
> > 2. If we start the container with /run volume mounted, running other
> > containers on
> > the host will be possible and so will be restarting the host. We *could*
> > make this
> > always the case or have an option to enable it.
>
> For things like this I think we should just pick some sane defaults and
> leave them like that to start with. Privileged container, as little
> isolation as possible, and any useful filesystems bind-mounted (/run and
> /etc at least).
Yep, lets start with some permissive "you can do whatever you want" defaults
(it's a test harness after all), and if we get requests to be able to run tests in a
locked down container instead... well, part of the reason for giving the default container
lots of power is so people can start their *own* locked down containers if they want them.
If people want the harness container to be more configurable, they're gonna have to be
*real* persuasive in order to successfully argue that starting a second container
doesn't make more sense :)
Cheers,
Nick.
>
> --
> Dan Callaghan <dcallagh(a)redhat.com>
> Software Engineer, Hosted & Shared Services
> Red Hat, Inc.
>
> _______________________________________________
> Beaker-devel mailing list
> Beaker-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
>
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Hi All,
I wanted to see if I could revive this thread. It has been several
years now. We still have two harnesses in Beaker. Roman do you have a
roadmap of the Beaker Harness plan.
Thank you,
Jeff