Support a NOP run mode beyond virtual chalking #224
Comments
nettrino
changed the title
|
Well, before too long, the con4m code will always be pre-executed, except
for the command line flag parsing, the user's config and a few other very
minor things.
We could potentially skip user config loading there, but not the command
line parsing.
And, if people want to disable across an entire machine, it seems like we'd
WANT to respect that in the config file? The config file can (e.g.,
through a parameterized module) implement the environment variable
semantics, but also let people just hardcode it off without worrying about
the environment if necessary.
That to me seems like the best overall approach; using the info can happen
before any other docker-related stuff happens (where bugs that need to be
worked around are likely to be).
…On Wed, Feb 28, 2024 at 4:18 AM Theofilos Petsios ***@***.***> wrote:
Description
There are cases where for whatever reason a chalk bug could be affecting
the build or execution of an image / binary etc. While we can do our best
to safeguard against errors (see #188
<#188> and similar issues), we
should offer a well-tested, robust nop mode of execution, where chalk
only passes execution to the underlying command (e.g., if doing chalk
docker build <args> to just do docker build <args>). This will be
different than standard chalk operations like virtual chalking, in the
sense that there will be
- no con4m related initialization or code executing
- no requirement for setup/env etc.
- no chalk flag like trace etc. respected
This will offer an easy escape path for users in case of critical bugs, as
well as a quick debug flag to pinpoint whether an issue is related to
chalk's side effects vs not.
Result
Define an environment variable (e.g., __CHALK_NOP), which, when set, will
result in a completely separate path of execution, which is dependency
free, and only calls execve with the underlying arguments passed to chalk.
—
Reply to this email directly, view it on GitHub
<#224>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABELGQKNDGKUSBHTDI7V2SLYV3Y65AVCNFSM6AAAAABD5UHD7CVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2TQNBXHE3TSNA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
You mean that con4m code will always be pre-executed before anything else in chalk? The DoD for this request was to completely bypass as much as possibly from the con4m or chalk codebase |
|
100%. 99% of the con4m code is data structure setup that can all run statically, and then be frozen in memory until needed basically. My point is that it soon will not be bypassing much actual work to bypass the con4m execution, and it's unclear there are benefits from doing so, since that's currently responsible for the user interface for options like this... It's very easy to avoid all of the work Chalk would do though, so I see it as very reasonable to add a I think for skipping the user-defined con4m config load, what's in place already would also suffice. So for me, |
|
right, with con4m v2 it will remove a lot of the loading complexity. for now I guess we can def add support for some env var to bypass things like loading custom configs, sinks/etc. basically with that env var chalk should not do anything error-prone such as doing network calls/etc once we have v2 I think we can make the bypass a lot more comprehensive |
|
Is it critical to address before we migrate???
…On Thu, Feb 29, 2024 at 2:22 PM Miroslav Shubernetskiy < ***@***.***> wrote:
right, with con4m v2 it will remove a lot of the loading complexity.
for now I guess we can def add support for some env var to bypass things
like loading custom configs, sinks/etc. basically with that env var chalk
should not do anything error-prone such as doing network calls/etc
once we have v2 I think we can make the bypass a lot more comprehensive
—
Reply to this email directly, view it on GitHub
<#224 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABELGQK2DGYLCJEC5ZFHE5LYV57XVAVCNFSM6AAAAABD5UHD7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRHAYDSMRWGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Description
There are cases where for whatever reason a chalk bug could be affecting the build or execution of an image / binary etc. While we can do our best to safeguard against errors (see #188 and similar issues), we should offer a well-tested, robust
nopmode of execution, where chalk only passes execution to the underlying command (e.g., if doingchalk docker build <args>to just dodocker build <args>). This will be different than standard chalk operations like virtual chalking, in the sense that there will betraceetc. respectedThis will offer an easy escape path for users in case of critical bugs, as well as a quick debug flag to pinpoint whether an issue is related to chalk's side effects vs not.
Result
Define an environment variable (e.g.,
__CHALK_NOP), which, when set, will result in a completely separate path of execution, which is dependency free, and only calls execve with the underlying arguments passed to chalk.The text was updated successfully, but these errors were encountered: