Do we know when this will be addressed? Currently this blocks any RHEL6 test updates. Also we run the risk of test being silently excluded from KT1.

Thanks,
Jeff

(In reply to comment #1)
> Do we know when this will be addressed? Currently this blocks any RHEL6 test
> updates. Also we run the risk of test being silently excluded from KT1.
> 
> Thanks,
> Jeff

Jeff, I propose it for 1.1.

This turned out to be a little more intrusive than I'm comfortable with for a maintenance release, so bumping to 0.14. The fact that it is a change designed to prevent future mistakes rather than to fix a current problem makes the conservative approach the better option here :)

Dan's original report suggested two alternative behaviours, and we didn't say which we're going to do.

As per the discussion in Gerrit, distros should *always* report their real name in their metadata. If they report an alias instead, then there's something wrong with the metadata and refusing to import the tree is a valid response (only viable distros should be imported and bad metadata = not viable).

Accordingly, importing a distro under an alias will always fail, but the error message will indicate what the real name was expected to be. That should help users figure out the appropriate response for themselves (whether that's abandoning the distro build as broken, regenerating the metadata or going into the Beaker UI and removing the existing alias)

(In reply to Nick Coghlan from comment #6)
> Dan's original report suggested two alternative behaviours, and we didn't
> say which we're going to do.
> 
> As per the discussion in Gerrit, distros should *always* report their real
> name in their metadata. If they report an alias instead, then there's
> something wrong with the metadata and refusing to import the tree is a valid
> response (only viable distros should be imported and bad metadata = not
> viable).
> 
> Accordingly, importing a distro under an alias will always fail, but the
> error message will indicate what the real name was expected to be. That
> should help users figure out the appropriate response for themselves
> (whether that's abandoning the distro build as broken, regenerating the
> metadata or going into the Beaker UI and removing the existing alias)

ok, i.e. we choose this one:
* refuse to import the distro if its OS version matches an existing alias;

and my comprehension is:
importing a distro by Specifying an existed alias as family will always fail, refuse to import and return error message indicating what the real name was expected to be.

Yes, that's the plan. It should start working that way in 0.14 (in 0.13 the answer is still "Don't do that, it may break things")

Patch: http://gerrit.beaker-project.org/#/c/2097/

Beaker 0.14.1 has been released.

For anyone attempting to clean up a previous bad import from a pre-0.14 release.

If the distro has never been provisioned, it can be purged using the following SQL:

DELETE FROM osversion USING osversion
INNER JOIN osmajor ON osversion.osmajor_id = osmajor.id
WHERE osmajor.osmajor = 'RHEL6';
DELETE FROM osversion_arch_map USING osversion_arch_map
INNER JOIN osversion ON osversion_arch_map.osversion_id = osversion.id
INNER JOIN osmajor ON osversion.osmajor_id = osmajor.id
WHERE osmajor.osmajor = 'RHEL6';
DELETE FROM exclude_osmajor USING exclude_osmajor
INNER JOIN osmajor ON exclude_osmajor.osmajor_id = osmajor.id
WHERE osmajor.osmajor = 'RHEL6';
DELETE FROM osmajor WHERE osmajor = 'RHEL6';

If it has been provisioned, cleaning out the activity history is rather complicated, so it's easier to just rename it to something relatively innocuous:

update osmajor set osmajor = 'BadRHEL6Import' where osmajor = 'RHEL6';