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 >> 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 <dcall...@redhat.com> >> Software Engineer, Hosted & Shared Services >> Red Hat, Inc. >> >> _______________________________________________ >> Beaker-devel mailing list >> Beaker-devel@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@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 _______________________________________________ Beaker-devel mailing list -- beaker-devel@lists.fedorahosted.org To unsubscribe send an email to beaker-devel-le...@lists.fedorahosted.org
