Fix abstraction of hiera constants |
||||||
Issue descriptionIt is currently possible to fail presubmit tests because an imported constants file requires a hiera lookup and you lack the private key. This breaks the assumption that constants are constants and hiera is simply a way of storing those constants more conveniently when different machines need different values. This assumption is a valuable abstraction and should be restored. Possible approaches: * Wrapper to make hiera lookups lazy (probably hard) * Wrapper to suppress errors for failed lookups due to access control issues. (probably medium-hard, underspecified, might make some failures harder to diagnose) * Something else entirely
,
May 10 2018
If we could just rely on the external dependency, then the fix would be trivial and we'd have already done it. I agree that we shouldn't do that, so we should add logic to handle the use of hiera to store constants.
,
May 10 2018
Okay, I can't really triage this bug like this though, it doesn't have a clear implementation plan I can hand off to someone nor a clear owner Can you design this out? Or mark it Available
,
May 29 2018
,
Jul 24
I recall some solution for this was made.
,
Jul 25
I don't think it ever was, no. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ayatane@chromium.org
, May 10 2018Status: Unconfirmed (was: Untriaged)
Ignoring whether or not Hiera values should be considering constants, Hiera is an external dependency and Python modules shouldn't be relying on external dependencies at import time. Import time logic has already caused huge headaches in the Autotest code base. I'm also against lazy lookup on attribute lookup. It's all too easy to regress into a import time dependency. Example: foo.py --- bar = hiera('some_key') # lazy, only calls hiera when accessed spam.py --- import foo eggs = foo.bar.split('-') # Now this calls hiera at import time