That makes sense, using something that will almost certainly be in use in any system we ever launch (for the foreseeable future). I would, however, counter with chrony being a similar service that will most likely be in use for a long time in all of our systems and is likely to be fixed very quickly, should it ever have a problem. At this point, switching to chrony as the default service here would solve this problem and be ubiquitous across all our platforms.
What don't you support? Creating a separate test case specific to systems tested via remote login, or keeping one singular testcase across all platforms?
Geoff Marr
IRC: coremoduleOn Wed, Apr 15, 2020 at 10:58 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Wed, 2020-04-15 at 10:48 -0600, Geoffrey Marr wrote:
> Hi all,
>
> The testcase in question is the base service manipulation test [0]. This
> testcase is a Final-milestone test for x86_64, ARM, and cloud in the
> validation test matrix [1][2][3]. It is also an optional testcase for
> non-release-blocking spins [4][5].
>
> In many of the testing scenarios that this testcase is used, the tester is
> logged into and testing the machine remotely via ssh. As the testcase
> stands now, the default service that is listed to test with is sshd. Since
> this test requires the tester to continually enable/disable/start/stop the
> sshd service, doing so on a machine that is remotely logged into will cause
> problems with ssh and could leave the tester stuck out of their system. In
> many cases where the tester does not have access to the hardware to login
> physically, this requires spinning up a new image to test remotely
> (thinking particularly of AWS), and can be quite a hassle.
>
> Currently, there is a note listed at the beginning of the testcase that
> warns the tester of these adverse effects, should the testcase be followed
> explicitly on a system being used remotely [6]. It suggests using a
> different, non-critical service to test the functionality, such as chronyd.
>
> I would like to propose that we change the default service that this
> testcase lists to use in the examples to something less critical to a
> tester who is logged in remotely over ssh. I propose we change the service
> to chronyd, but am open to other suggestions. As it stands, I don't see a
> reason to use ssh over another service, especially if using ssh can
> introduce some problems. The only reason I could possibly see as to why ssh
> was used in the first place was that it's enabled on all spins of Fedora,
> but I'm not certain of that. If someone wants to inform me as to why ssh
> was originally used, please do.
I picked sshd because it's really important, basically.
The reasoning being: it's almost certainly going to be baked into just
about anything we ever build, and it's also very unlikely ever to be
broken *in itself* for very long, because, well, it's sshd. If it
breaks it's gonna get fixed, in a hurry.
> This would make it easier to find a service to test with for those logged
> into systems remotely while also keeping the test uniform across all arches
> and spins of Fedora, as the same service could be used across all platforms.
>
> It has been suggested to create a separate testcase specifically for
> systems that are tested via remote logins, but if there is no reason to
> continue using ssh in this testcase, I think it would be a good idea to
> change it and keep just one testcase for all in this instance.
I definitely don't support that. I'd prefer to either just leave it as
it is, or find another service we have similar confidence will always
be present in any Fedora edition and will very rarely be broken.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
