[jboss-jira] [JBoss JIRA] (WFLY-10438) Create a domain testsuite test for a missing host-exclude

[James Perkins (Jira)]

     [ https://issues.jboss.org/browse/WFLY-10438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-10438:
---------------------------------
    Fix Version/s: 15.0.0.Final


> Create a domain testsuite test for a missing host-exclude
> ---------------------------------------------------------
>
>                 Key: WFLY-10438
>                 URL: https://issues.jboss.org/browse/WFLY-10438
>             Project: WildFly
>          Issue Type: Task
>          Components: Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Yeray Borges
>            Priority: Major
>              Labels: domain-mode
>             Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources.
> I had a complicated slow approach in mind that I wrote here before; it's stricken out below.
> Much simpler approach:
> Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions.  Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version.
> If we add a new extension and don't host-exclude it, this will fail.  This really is all that's needed to avoid completely skipping the host-excludes.
> If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail.  This will help ensure the test isn't completely unmaintained.
> It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful.
> Original complicated approach:
> -We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension.
> Something like:
> Base domain config must be the standard one we ship. It will include all extensions.
> Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version.
> Slave host.xml has 1 server only, and in that server group.
> Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.-



--
This message was sent by Atlassian Jira
(v7.12.1#712002)