Tim Jenness says on DM-27174: ":to propagate the instrument label to all products it's a one line patch to https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/makeRawVisitInfoViaObsInfo.py#L106". However, the ObservationInfo object does not have an Instrument that we can call getName() on, and I don't know that I trust that e.g. the "INSTRUM" header (or whatever it is in FITS) will match Instrument.getName(). There is a TestMakeRawVisitInfoViaObsInfo to test it, if we go that route. VisitInfo is immutable, so we can't populate it after the fact.

I'm not really following you. The instrument property of ObservationInfo is guaranteed to match the instrument name used by the Instrument class and the gen3 butler. Gen3 butler uses the instrument property when ingesting data so they must match otherwise ingest would fail. Do not use the INSTRUME header directly – the entire purpose of astro_metadata_translator is to give you a standardized instrument name from a FITS header.

Krzysztof Findeisen and Tim Jenness: do you both mind having a look? This ended up being a 3 line change, including tests.

Jenkins: https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/33420/pipeline

I did not add any tests of this in obs_base ingest_test.py because it all happens in makeRawVisitInfoViaObsInfo.py and the ingest code doesn't directly affect any of it. Let me know if you think explicit per-obs tests of the name that gets assigned to visitInfo.instrumentLabel are warranted.

Looks good to me.