Excerpts from Nick Coghlan's message of 2013-01-16 11:48:31 +1000: > On 01/16/2013 11:31 AM, Dan Callaghan wrote: > > Excerpts from Nick Coghlan's message of 2013-01-16 11:11:05 +1000: > >> - Retained explicit mention of Beah (now as a separate trailing > >> paragraph), as I want to start down the path to supporting other test > >> execution frameworks like STAF and autotest (as mentioned in Dan's > >> email last year about defining a harness API). Actually making that > >> happen is going to require that we draw a sharper distinction between > >> Beaker-the-lab-management-tool and > >> Beah-the-task-execution-environment, and the blurb is an easy place to > >> start that process. > > > > I think this is a false distinction, or not the right distinction > > anyway... Beah does not define the task execution environment, RHTS > > does. Beah just provides an RHTS-compatible environment (by literally > > emulating RHTS). > > From the perspective of someone using Beaker though, do they really > care that the API published by Beah was originally defined by RHTS?
Well the commands are all named rhts-*, so maybe :-) > Essentially, we need a name for "the parts of Beaker that run on the > system under test", as opposed to the parts that run on the main server > and the lab controllers. I'm proposing we use "Beah" as that name, even > if the term has historically been used in a narrower sense. After all, > the RHTS compatibility layer and the beakerlib project rely on Beah to > actually talk to the Beaker infrastructure. This is backwards. By "RHTS compatibility layer" I assume you mean the code in the rhts package.. that isn't a compatibility layer, it is the actual original test environment bits from RHTS, mostly unchanged. Beah is the one with the compatibility layers to emulate an RHTS scheduler on localhost, and all the other stuff. > All the stuff in the beah and rhts repos, as well as the stuff we set up > server side through the kickstart templates, could then be described as > the "Beah execution environment", opening the door for us to have > *other* execution environments on the systems under test in the future. Right so this is purely a naming debate. But I think the name should not be "Beah execution environment" but rather "RHTS-compatible execution environment" or "execution environment for RHTS-format(ted) tasks" or something like that. Reasons: - All the commands are called rhts-* - Beah doesn't define anything itself, it just emulates RHTS - RHTS predates Beaker and Beah I see beah's existence as purely an implementation detail of supporting RHTS-formatted tasks (or an "RHTS-compatible execution environment") in Beaker. Some theoretical alternative/future harness might also support RHTS-formatted tasks, without having anything in common with Beah. -- Dan Callaghan <dcall...@redhat.com> Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
signature.asc
Description: PGP signature
_______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
