You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The lsst.artifact_path configuration value affects where the application writes its filesystem artifacts at runtime. This has problems:
It's not really a "lsst" configuration value. While it may be relevant for a specific LSST manifest to influence this path, the root of the path is tightly coupled to the deployment (site).
The root portion of the artifact path is not user-settable. The root portion of the path should be part of the site manifest (falling back to deployment configuration), and only the last path components should be set via the LSST manifest.
The availability of the artifact path value in a user-editable manifest is problematic from the start: the root path should always be set at the deployment level and only some relative final path component set by manifest (if that).
The behavior of the application using the artifact path value is too dependent on the existence of the path as an actual mounted filesystem. The path should instead be a URI (file://...., s3://...) and designed to support other types of locations.
The artifact path is part of the lsst manifest but the fallback deployment configuration setting is bps.artifact_path which is a backward-compatiblility naming issue.
lsst.artifact_pathconfiguration value affects where the application writes its filesystem artifacts at runtime. This has problems:The behavior of the application using the artifact path value is too dependent on the existence of the path as an actual mounted filesystem. The path should instead be a URI (
file://....,s3://...) and designed to support other types of locations.The artifact path is part of the
lsstmanifest but the fallback deployment configuration setting isbps.artifact_pathwhich is a backward-compatiblility naming issue.