https://bentoml.com logo
Join Slack
Powered by
Hello! We can no longer find the documentation for...
# ask-for-help
p
Hello! We can no longer find the documentation for the 
BENTOML_CONFIG_OPTIONS
environment variable. Is it intended?
The last reference to it currently available on docs.bentoml.com is for the 
1.1
release.
j
Yes, that options are hidden but still works. we now encourage user to work through using the decorator. https://docs.bentoml.com/en/latest/reference/bentoml/configurations.html which provides more flexibility
p
The use-case for 
$BENTOML_CONFIG_OPTIONS
was for dynamically tweaking some settings (could be latency settings, or parallelism) without requiring each application to systematically re-specify every option in the decorator, along with default values. Is the environment variable still a part of the API? Or should we expect it to be deprecated in the future?
j
systematically re-specify every option in the decorator
with the code being in the decorator, you can use your own environment variable which provides you more control. Does that make sense to you?
p
It does, but we're counting on the standardization aspect of always having the same options available between different services. If the developers have to specify it themselves, there could be a drift between implementations, or depending on the bentoml version
an example use-case is for exposing options through generic helm charts / pulumi resources reproducing a similar mechanism on our end would mean a custom wrapper for the bentoml decorators, which is a pretty high-maintenance approach when compared to a direct access like 
$BENTOML_CONFIG_OPTIONS
j
This is a good feedback. Correct me if I am wrong, you want the developers of the Bento to not care about the configuration and an easy way for the Deployment engineer to inject configuration into different Bento through a non invasive means. So even by doing
Copy code
@service({"workers" : os.environ.get("BENTOML_WORKERS")})
is not good enough?
p
Yup, basically that's what 
BENTOML_CONFIG_OPTIONS
allows us to do. Ideally the BentoML service definition should specify anything that's required for its operation, including relevant bentoml options, and do all that in a cohesive manner between all applications ; but in practice it's very helpful to be able to override these settings without rebuilding everything.
without rebuilding everything
..without requiring a code update followed by a rebuild, more precisely. It's the same idea behind configuration override mechanisms you can find in application frameworks such as spring, micronaut, etc. You're not supposed to handle all of your configuration settings that way, but in a pinch it makes it possible to tweak critical settings that may have been overlooked initially, and then endorse those tweaks properly later on.
Open in Slack
PreviousNext
Powered by