On Wed, Aug 20, 2014 at 3:18 AM, Nick Coghlan <ncogh...@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
> +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 :)
>> Dan Callaghan <dcall...@redhat.com>
>> Software Engineer, Hosted & Shared Services
>> Red Hat, Inc.
>> Beaker-devel mailing list
> Nick Coghlan
> Red Hat Hosted & Shared Services
> Software Engineering & Development, Brisbane
> HSS Provisioning Architect
> Beaker-devel mailing list
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.
Beaker-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to beaker-devel-le...@lists.fedorahosted.org