• Describe what you need us to do:
  Very similar to #6730... we are bitten by garbage data inserted into stage once again. Ironically this time it was me who inserted it :grimacing:

Deploying the latest Waiverdb in stg is failing currently:

2018-06-28 05:21:28 [pid     1] alembic.env INFO Starting migrations.
2018-06-28 05:21:28 [pid     1] alembic.runtime.migration INFO Running upgrade ce8a1351ecdc -> f6bc296ba966, Replace waiver.subject dict with subject_type and subject_identifier
[...]
  File "/usr/lib/python3.6/site-packages/waiverdb/migrations/versions/f6bc296ba966_subject_dict_to_type_identifier.py", line 38, in upgrade
    subject_type, subject_identifier = subject_dict_to_type_identifier(subject)
  File "/usr/lib/python3.6/site-packages/waiverdb/models/waivers.py", line 23, in subject_dict_to_type_identifier
    raise ValueError('Unrecognised subject type: %r' % subject)
ValueError: Unrecognised subject type: {'type': 'nothing'}

It's due to a few old waivers inserted by me a while ago, with subject values that do not fit any of the expected structures.

https://waiverdb.stg.fedoraproject.org/api/v1.0/waivers/16
https://waiverdb.stg.fedoraproject.org/api/v1.0/waivers/17
https://waiverdb.stg.fedoraproject.org/api/v1.0/waivers/18

Can someone with access to the stg Waiverdb Postgres database please run the following, to adjust the bogus values to be slightly less bogus (and acceptable to the data migration):

UPDATE waiver SET subject = '{"item":"nothing","type":"koji_build"}' WHERE id IN (16, 17, 18);

I have reviewed all the other waivers in stg and the rest should be fine with the migration.

• When do you need this? (YYYY/MM/DD)
  ASAP but only because it is blocking Waiverdb deployment in stage -- nothing is broken in prod

• When is this no longer needed or useful? (YYYY/MM/DD)
  heat death of the universe?

• If we cannot complete your request, what is the impact?
  Waiverdb deployments can't proceed