Is this ticket still relevant?

Why wouldn't it be? We somehow need to ensure we can store everything the Gen2 Butler can.

Ah. I read "Define Storage Classes for Butler" as defining how storage classes work, not defining what storage classes we need.

Starting work on this.  I may spin off some StorageClass work to another ticket, but we need to add a few more to run the ci_hsc integration tests we'd planned.

Is DM-12617 really blocking this?

Good catch; no.  Looks like it may still be worth doing in the future, so I won't WontFix it, but it does not need to be a blocker.

This ticket brings us near-complete coverage of the Gen2 DatasetTypes used in ci_hsc in terms of concrete StorageClasses and Formatters.  All we're missing are:

• metadata DatasetTypes: these are PropertySets/PropertyLists, persisted via Boost.Serialization, and their persistence is tied up with daf_persistence at a level I didn't want to try to unravel now for datasets that are basically write-only. (I'd rather not try to unravel it ever; see RFC-482).
• Stuff that may be stored in calibration repositories (which are not yet converted at all).
• Complete coverage of the components of composites (namely Exposure).  This simply hasn't been tested, and I want to defer the kind of testing infrastructure that would be required to another ticket.

I considered trying to reduce the set of concrete StorageClasses by removing the isinstance check on their pytypes; in practice we have a lot of StorageClasses that map to some Python duck-typing interface that doesn't actually have a base class.  I did not proceed with this right now because I think it'd be a distraction from higher-priority things, but we should think about it in the future.

Good as is.