Future directions for the Beaker test harness

[Nick Coghlan]

A few weeks back, Amit put together a proof of concept for running the
test harness in a container, rather than directly on the host
(http://gerrit.beaker-project.org/#/c/3199).

That proof of concept relies on restraint, the new reference harness,
that is intended to eventually replace beah
(https://beaker-project.org/dev/proposals/reference-harness.html)

At the same time, I don't think restraint is currently getting the level
of review and testing that it needs to mature into a plausible
replacement for beah as the default harness.

I think Amit's proposed patch provides a possible way forward:

1. Accept the initial approach where restraint is the *only* supported
harness when running inside a container. Specifying both
"contained_harness" and "harness" as ks_meta variables should be an
error at this point (side note: 'harness' should also be documented
along with all the other ks_meta variables, with a link to
https://beaker-project.org/docs/alternative-harnesses/).

2. Recommend publishing both beah *and* restraint in the harness repos
for Beaker installations. This will not only make restraint available
for container based testing, but also make it readily available via
"harness=restraint" for normal testing, without needing to add a custom
repo definition.

3. Once we have container based testing working reliably with restraint,
drop the restriction against using alternative harnesses in containers.

The priority at the moment though is to get something working that can
run on an Atomic Host, and still provide a relatively normal execution
environment for the executed tasks. Supporting alternative harnesses
*inside* containers is a nice-to-have that can wait until later - by
flatly disallowing it, we ensure we don't have to spend any time working
on container related issues that don't impact restraint. For the initial
iteration, we can also ignore the question of choosing the base image
used to run the harness, as well as being able to start and stop other
containers on the host.

I've filed an RFE for 0.18 on that basis:
https://bugzilla.redhat.com/show_bug.cgi?id=1131388

As part of this, we may also want to move restraint from Bill's personal
account on GitHub to the main Beaker project account, but I don't think
that's particularly urgent at this point.

Regards,
Nick.

[Amit Saha]

Hi Nick,

Thanks for the notes and suggestions.

----- Original Message -----
> From: "Nick Coghlan" 
> To: "beaker-devel" 
> Sent: Tuesday, August 19, 2014 5:18:02 PM
> Subject: [Beaker-devel] Future directions for the Beaker test harness
>
> A few weeks back, Amit put together a proof of concept for running the
> test harness in a container, rather than directly on the host
> (http://gerrit.beaker-project.org/#/c/3199).
>
> That proof of concept relies on restraint, the new reference harness,
> that is intended to eventually replace beah
> (https://beaker-project.org/dev/proposals/reference-harness.html)
>
> At the same time, I don't think restraint is currently getting the level
> of review and testing that it needs to mature into a plausible
> replacement for beah as the default harness.
>
> I think Amit's proposed patch provides a possible way forward:
> Accept the initial approach where restraint is the *only* supported
>
> harness when running inside a container. Specifying both
> "contained_harness" and "harness" as ks_meta variables should be an
> error at this point (side note: 'harness' should also be documented
> along with all the other ks_meta variables, with a link to
> https://beaker-project.org/docs/alternative-harnesses/).
> Recommend publishing both beah *and* restraint in the harness repos
>
> for Beaker installations. This will not only make restraint available
> for container based testing, but also make it readily available via
> "harness=restraint" for normal testing, without needing to add a custom
> repo definition.

Yes, this will certainly make using restraint easier than it is currently.
> Once we have container based testing working reliably with restraint,
>
> drop the restriction against using alternative harnesses in containers.
>
> The priority at the moment though is to get something working that can
> run on an Atomic Host, and still provide a relatively normal execution
> environment for the executed tasks. Supporting alternative harnesses
> *inside* containers is a nice-to-have that can wait until later - by
> flatly disallowing it, we ensure we don't have to spend any time working
> on container related issues that don't impact restraint. For the initial
> iteration, we can also ignore the question of choosing the base image
> used to run the harness, as well as being able to start and stop other
> containers on the host.

Two points related to the last sentence:

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.

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.

Best,
Amit.

[Dan Callaghan]

Excerpts from Amit Saha's message of 2014-08-20 14:04 +10:00:
> 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.
> 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).

[Nick Coghlan]

----- Original Message -----
> Excerpts from Amit Saha's message of 2014-08-20 14:04 +10:00:
> > 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
> > 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 
> Software Engineer, Hosted & Shared Services
> Red Hat, Inc.
>
> Beaker-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel

[Jeffrey Burke]

On Wed, Aug 20, 2014 at 3:18 AM, Nick Coghlan  wrote:
> ----- Original Message -----
> > Excerpts from Amit Saha's message of 2014-08-20 14:04 +10:00:
> > > 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
> > > 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 
> > Software Engineer, Hosted & Shared Services
> > Red Hat, Inc.
> >
> > Beaker-devel mailing list
> > [e-mail]
> > 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
> [e-mail]
> 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

[Róman Joost]

Dear Jeff,

On Wed, Mar 07, 2018 at 08:25:47AM -0500, Jeffrey Burke wrote:
> On Wed, Aug 20, 2014 at 3:18 AM, Nick Coghlan  wrote:
> > ----- Original Message -----
> > > Excerpts from Amit Saha's message of 2014-08-20 14:04 +10:00:
>
> [...]
> > 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 :)
>
> 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.

I don't specifically know the contents of that conversation. Perhaps Dan
can give me a hint if I'm on a wrong track here.

Our current idea is to make restraint the default harness for RHEL8+ and
therefore slowly phase out beah (as the default). That includes getting
restraint to achieve feature parity with beah. I don't have an exact
time frame for this yet and how we would pull this off, since I expect
there are possibly higher priority items coming up.

Does that answer your question or at least goes in the right direction?

Kind Regards,

[Jeffrey Burke]

On Wed, Mar 7, 2018 at 10:53 PM, Róman Joost  wrote:
> Dear Jeff,
>
> On Wed, Mar 07, 2018 at 08:25:47AM -0500, Jeffrey Burke wrote:
> > On Wed, Aug 20, 2014 at 3:18 AM, Nick Coghlan  wrote:
> > > ----- Original Message -----
> > > > Excerpts from Amit Saha's message of 2014-08-20 14:04 +10:00:
> >
> > [...]
> > > 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 :)
> >
> > 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.
>
> I don't specifically know the contents of that conversation. Perhaps Dan
> can give me a hint if I'm on a wrong track here.
>
> Our current idea is to make restraint the default harness for RHEL8+ and
> therefore slowly phase out beah (as the default). That includes getting
> restraint to achieve feature parity with beah. I don't have an exact
> time frame for this yet and how we would pull this off, since I expect
> there are possibly higher priority items coming up.

That is a good plan. Do you have a list of features in BEAH that are
not in Restraint to achieve parity?
> Does that answer your question or at least goes in the right direction?

Partially, do you know who on your team will be SME for Restraint?
>

Thank you,
Jeff
> Kind Regards,
>
> Róman Joost
> Senior Software Engineer, Products & Technologies Operations (Brisbane)
> Red Hat
>
> Beaker-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Róman Joost]

Dear Jeff,

On Thu, Mar 08, 2018 at 09:00:43AM -0500, Jeffrey Burke wrote:
> > Our current idea is to make restraint the default harness for RHEL8+ and
> > therefore slowly phase out beah (as the default). That includes getting
> > restraint to achieve feature parity with beah. I don't have an exact
> > time frame for this yet and how we would pull this off, since I expect
> > there are possibly higher priority items coming up.
>
> That is a good plan. Do you have a list of features in BEAH that are
> not in Restraint to achieve parity?

At this moment we don't have a good overview of what specifically is
missing. We do however have an epic:

https://projects.engineering.redhat.com/browse/BKR-2891

in which we track bugs and tasks to figure out what else we're missing
to get feature parity. One missing feature we do know is captured in

https://bugzilla.redhat.com/show_bug.cgi?id=1206059
    support testinfo.desc Environment in restraint

That will get us change our dogfood tests to use restraint by default.
Once we have that, we will hopefully have a much better picture of what
is missing.
> > Does that answer your question or at least goes in the right direction?
>
> Partially, do you know who on your team will be SME for Restraint?

Matt Tyson  has taken the lead on restraint so he'll
be the SME for it.

Kind Regards,

[Jeffrey Burke]

On Thu, Mar 8, 2018 at 6:45 PM, Róman Joost  wrote:
> Dear Jeff,
>
> On Thu, Mar 08, 2018 at 09:00:43AM -0500, Jeffrey Burke wrote:
> > > Our current idea is to make restraint the default harness for RHEL8+ and
> > > therefore slowly phase out beah (as the default). That includes getting
> > > restraint to achieve feature parity with beah. I don't have an exact
> > > time frame for this yet and how we would pull this off, since I expect
> > > there are possibly higher priority items coming up.
> >
> > That is a good plan. Do you have a list of features in BEAH that are
> > not in Restraint to achieve parity?
>
> At this moment we don't have a good overview of what specifically is
> missing. We do however have an epic:
> https://projects.engineering.redhat.com/browse/BKR-2891

Opened 08/Apr/15 12:51 AM /me looks at calendar.  Kidding, I see it is
still assigned to Dan. Can we get that reassigned to Matt Tyson
please.
> in which we track bugs and tasks to figure out what else we're missing
> to get feature parity. One missing feature we do know is captured in
> https://bugzilla.redhat.com/show_bug.cgi?id=1206059
> support testinfo.desc Environment in restraint
>
> That will get us change our dogfood tests to use restraint by default.
> Once we have that, we will hopefully have a much better picture of what
> is missing.

OK I will talk to Bill and Ari and see if this is something that we
can get planned in the next sprint.
> > > Does that answer your question or at least goes in the right direction?
> >
> > Partially, do you know who on your team will be SME for Restraint?
>
> Matt Tyson  has taken the lead on restraint so he'll
> be the SME for it.

Thanks for the name! I can not wait to meet my new best friend Matt =)

Thank you Roman, It is always a please talking with you,

Regards,
Jeff
> Kind Regards,
>
> Róman Joost
> Senior Software Engineer, Products & Technologies Operations (Brisbane)
> Red Hat
>
> Beaker-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> <div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 6:45 PM, Róman Joost <span dir="ltr">&lt;<a href="mailto:[e-mail]" target="_blank">[e-mail]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Jeff,<br>

<span class=""><br>
On Thu, Mar 08, 2018 at 09:00:43AM -0500, Jeffrey Burke wrote:<br>
&gt; &gt; Our current idea is to make restraint the default harness
for RHEL8+ and<br>
&gt; &gt; therefore slowly phase out beah (as the default). That
includes getting<br>
&gt; &gt; restraint to achieve feature parity with beah. I don't have
an exact<br>
&gt; &gt; time frame for this yet and how we would pull this off,
since I expect<br>
&gt; &gt; there are possibly higher priority items coming up.<br>
&gt; &gt;<br>
&gt; That is a good plan. Do you have a list of features in BEAH that are<br>
&gt; not in Restraint to achieve parity?<br>
</span>At this moment we don't have a good overview of what specifically is<br>
missing. We do however have an epic:<br>
<br>
&nbsp; &nbsp; <a
href="https://projects.engineering.redhat.com/browse/BKR-2891"
data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://projects.engineering.redhat.com/browse/BKR-2891&amp;source=gmail&amp;ust=1520686353924000&amp;usg=AFQjCNEkEkDiv1RH_bAmyZmN9G7XthfmOA"
rel="noreferrer"
target="_blank">https://projects.engineering.<wbr>redhat.com/browse/BKR-2891</a><br>
<br>
in which we track bugs and tasks to figure out what else we're missing<br>
to get feature parity. One missing feature we do know is captured in<br>
<br>
&nbsp; &nbsp; <a
href="https://bugzilla.redhat.com/show_bug.cgi?id=1206059"
data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://bugzilla.redhat.com/show_bug.cgi?id%3D1206059&amp;source=gmail&amp;ust=1520686353924000&amp;usg=AFQjCNEUtpbxBIk-ysHnqwS34TSXLKOMkA"
rel="noreferrer"
target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1206059</a><br>
&nbsp; &nbsp; support testinfo.desc Environment in restraint<br>
<br>
That will get us change our dogfood tests to use restraint by default.<br>
Once we have that, we will hopefully have a much better picture of what<br>
is missing.<br>
<span class=""><br>
&gt; &gt; Does that answer your question or at least goes in the right
direction?<br>
&gt; Partially, do you know who on your team will be SME for Restraint?<br>
</span>Matt Tyson &lt;<a
href="mailto:[e-mail]">[e-mail]</a>&gt; has taken
the lead on restraint so he'll<br>
be the SME for it.<br>
<div class="HOEnZb"><div class="h5"><br>
Kind Regards,<br>
--<br>
Róman Joost<br>
Senior Software Engineer, Products &amp; Technologies Operations (Brisbane)<br>
Red Hat<br>
</div></div><br>______________________________<wbr>_________________<br>
Beaker-devel mailing list -- <a
href="mailto:[e-mail]">beaker-devel@lists.<wbr>fedorahosted.org</a><br>
To unsubscribe send an email to <a
href="mailto:[e-mail]">beaker-devel-leave@lists.<wbr>fedorahosted.org</a><br>
<br></blockquote></div><br></div>

[Róman Joost]

Dear Jeff,

On Fri, Mar 09, 2018 at 08:12:19AM -0500, Jeffrey Burke wrote:
> On Thu, Mar 8, 2018 at 6:45 PM, Róman Joost  wrote:
> > Dear Jeff,
> >
> > On Thu, Mar 08, 2018 at 09:00:43AM -0500, Jeffrey Burke wrote:
> > > > Our current idea is to make restraint the default harness for RHEL8+ and
> > > > therefore slowly phase out beah (as the default). That includes getting
> > > > restraint to achieve feature parity with beah. I don't have an exact
> > > > time frame for this yet and how we would pull this off, since I expect
> > > > there are possibly higher priority items coming up.
> > >
> > > That is a good plan. Do you have a list of features in BEAH that are
> > > not in Restraint to achieve parity?
> >
> > At this moment we don't have a good overview of what specifically is
> > missing. We do however have an epic:
> > https://projects.engineering.redhat.com/browse/BKR-2891
>
> Opened 08/Apr/15 12:51 AM /me looks at calendar.  Kidding, I see it is
> still assigned to Dan. Can we get that reassigned to Matt Tyson
> please.

Done.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1206059
> > support testinfo.desc Environment in restraint
>
> OK I will talk to Bill and Ari and see if this is something that we
> can get planned in the next sprint.

Matt almost jumped on this one right away. To avoid any collisions
perhaps don't tackle the support for the environment at the moment.

Having said that, there might be a gazillion of bugs lurking we don't
know about until we've switched our dogfood jobs to restraint. Once we
have a better picture, I'm sure we're very happy to receive some help to
get them closed quickly. I know Bill has already provided a few patches
for recently reported bugs, which was very helpful.  So I'm suggesting,
please hold up a bit and I'll reach out asking for help. Otherwise it'll
be a shame if we would collide fixing the same bug.
> > > > Does that answer your question or at least goes in the right direction?
> > >
> > > Partially, do you know who on your team will be SME for Restraint?
> >
> > Matt Tyson  has taken the lead on restraint so he'll
> > be the SME for it.
>
> Thanks for the name! I can not wait to meet my new best friend Matt =)
>
> Thank you Roman, It is always a please talking with you,

Same here, same here :)

Kind Regards,

[Jeffrey Burke]

On Mon, Mar 12, 2018 at 3:13 AM, Róman Joost  wrote:
> Dear Jeff,
>
> On Fri, Mar 09, 2018 at 08:12:19AM -0500, Jeffrey Burke wrote:
> > On Thu, Mar 8, 2018 at 6:45 PM, Róman Joost  wrote:
> > > Dear Jeff,
> > >
> > > On Thu, Mar 08, 2018 at 09:00:43AM -0500, Jeffrey Burke wrote:
> > > > > Our current idea is to make restraint the default harness for RHEL8+ and
> > > > > therefore slowly phase out beah (as the default). That includes getting
> > > > > restraint to achieve feature parity with beah. I don't have an exact
> > > > > time frame for this yet and how we would pull this off, since I expect
> > > > > there are possibly higher priority items coming up.
> > > >
> > > > That is a good plan. Do you have a list of features in BEAH that are
> > > > not in Restraint to achieve parity?
> > >
> > > At this moment we don't have a good overview of what specifically is
> > > missing. We do however have an epic:
> > > https://projects.engineering.redhat.com/browse/BKR-2891
> >
> > Opened 08/Apr/15 12:51 AM /me looks at calendar.  Kidding, I see it is
> > still assigned to Dan. Can we get that reassigned to Matt Tyson
> > please.
>
> Done.
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1206059
> > > support testinfo.desc Environment in restraint
> >
> > OK I will talk to Bill and Ari and see if this is something that we
> > can get planned in the next sprint.
>
> Matt almost jumped on this one right away. To avoid any collisions
> perhaps don't tackle the support for the environment at the moment.
>
> Having said that, there might be a gazillion of bugs lurking we don't
> know about until we've switched our dogfood jobs to restraint. Once we
> have a better picture, I'm sure we're very happy to receive some help to
> get them closed quickly. I know Bill has already provided a few patches
> for recently reported bugs, which was very helpful.  So I'm suggesting,
> please hold up a bit and I'll reach out asking for help. Otherwise it'll
> be a shame if we would collide fixing the same bug.

Agreed, Bill Peck is on this list. I will also verbally mention it to
him. Matt is the SME for Restraint. If and when he needs help he can
reach out.

Thank you,
Jeff
> > > > > Does that answer your question or at least goes in the right direction?
> > > >
> > > > Partially, do you know who on your team will be SME for Restraint?
> > >
> > > Matt Tyson  has taken the lead on restraint so he'll
> > > be the SME for it.
> >
> > Thanks for the name! I can not wait to meet my new best friend Matt =)
> >
> > Thank you Roman, It is always a please talking with you,
>
> Same here, same here :)
> Kind Regards,
>
> Róman Joost
> Senior Software Engineer, Products & Technologies Operations (Brisbane)
> Red Hat
>
> Beaker-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 12,
2018 at 3:13 AM, Róman Joost <span dir="ltr">&lt;<a
href="mailto:[e-mail]"
target="_blank">[e-mail]</a>&gt;</span> wrote:<br><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Dear Jeff,<br>
<span class=""><br>
On Fri, Mar 09, 2018 at 08:12:19AM -0500, Jeffrey Burke wrote:<br>
&gt; On Thu, Mar 8, 2018 at 6:45 PM, Róman Joost &lt;<a
href="mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; &gt; Dear Jeff,<br>
&gt; &gt;<br>
&gt; &gt; On Thu, Mar 08, 2018 at 09:00:43AM -0500, Jeffrey Burke wrote:<br>
&gt; &gt;&gt; &gt; Our current idea is to make restraint the default
harness for RHEL8+ and<br>
&gt; &gt;&gt; &gt; therefore slowly phase out beah (as the default).
That includes getting<br>
&gt; &gt;&gt; &gt; restraint to achieve feature parity with beah. I
don't have an exact<br>
&gt; &gt;&gt; &gt; time frame for this yet and how we would pull this
off, since I expect<br>
&gt; &gt;&gt; &gt; there are possibly higher priority items coming up.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; That is a good plan. Do you have a list of features in
BEAH that are<br>
&gt; &gt;&gt; not in Restraint to achieve parity?<br>
&gt; &gt; At this moment we don't have a good overview of what
specifically is<br>
&gt; &gt; missing. We do however have an epic:<br>
&gt; &gt;<br>
&gt; &gt;&nbsp; &nbsp; &nbsp;<a
href="https://projects.engineering.redhat.com/browse/BKR-2891"
data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://projects.engineering.redhat.com/browse/BKR-2891&amp;source=gmail&amp;ust=1520942745405000&amp;usg=AFQjCNHovM5Ds4An0MtCRoRz_UdWhjjm7A"
rel="noreferrer"
target="_blank">https://projects.engineering.<wbr>redhat.com/browse/BKR-2891</a><br>
&gt; &gt;<br>
&gt; Opened 08/Apr/15 12:51 AM /me looks at calendar.&nbsp; Kidding, I
see it is<br>
&gt; still assigned to Dan. Can we get that reassigned to Matt Tyson<br>
&gt; please.<br>
</span>Done.<br>
<span class=""><br>
&gt; &gt;&nbsp; &nbsp; &nbsp;<a
href="https://bugzilla.redhat.com/show_bug.cgi?id=1206059"
data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://bugzilla.redhat.com/show_bug.cgi?id%3D1206059&amp;source=gmail&amp;ust=1520942745405000&amp;usg=AFQjCNELJg9zrqxXyuup9wz1EN7OWWHh8A"
rel="noreferrer"
target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1206059</a><br>
&gt; &gt;&nbsp; &nbsp; &nbsp;support testinfo.desc Environment in restraint<br>
&gt; &gt;<br>
</span><span class="">&gt; OK I will talk to Bill and Ari and see if
this is something that we<br>
&gt; can get planned in the next sprint.<br>
</span>Matt almost jumped on this one right away. To avoid any collisions<br>
perhaps don't tackle the support for the environment at the moment.<br>
<br>
Having said that, there might be a gazillion of bugs lurking we don't<br>
know about until we've switched our dogfood jobs to restraint. Once we<br>
have a better picture, I'm sure we're very happy to receive some help to<br>
get them closed quickly. I know Bill has already provided a few patches<br>
for recently reported bugs, which was very helpful.&nbsp; So I'm suggesting,<br>
please hold up a bit and I'll reach out asking for help. Otherwise it'll<br>
be a shame if we would collide fixing the same bug.<br>
<span class=""><br>
&gt; &gt;<br>
&gt; &gt;&gt; &gt; Does that answer your question or at least goes in
the right direction?<br>
&gt; &gt;&gt; Partially, do you know who on your team will be SME for
Restraint?<br>
&gt; &gt; Matt Tyson &lt;<a
href="mailto:[e-mail]">[e-mail]</a>&gt; has taken
the lead on restraint so he'll<br>
&gt; &gt; be the SME for it.<br>
&gt; &gt;<br>
&gt; Thanks for the name! I can not wait to meet my new best friend Matt =)<br>
&gt;<br>
&gt; Thank you Roman, It is always a please talking with you,<br>
</span>Same here, same here :)<br>
<div class="HOEnZb"><div class="h5"><br>
Kind Regards,<br>
--<br>
Róman Joost<br>
Senior Software Engineer, Products &amp; Technologies Operations (Brisbane)<br>
Red Hat<br>
</div></div><br>______________________________<wbr>_________________<br>
Beaker-devel mailing list -- <a
href="mailto:[e-mail]">beaker-devel@lists.<wbr>fedorahosted.org</a><br>
To unsubscribe send an email to <a
href="mailto:[e-mail]">beaker-devel-leave@lists.<wbr>fedorahosted.org</a><br>
<br></blockquote></div><br></div>