Is your feature request related to a problem? Please describe.
Configuration for feast is currently done using environment variables only. As the number of parameters grows in size, this method of configuring the deployment becomes increasingly unwieldy.
Describe the solution you'd like
We want to move away from KVs, which are limited when it comes to nested config, eg. for job options. Currently we set it as a json string.
Describe alternatives you've considered
If we use yaml, it would potentially look something like this:
---
# CORE CONFIG #
grpc.port: 6565
http.port: 8080
feast.jobs:
coreUri: localhost:6565
runner: DataflowRunner
options:
project: my-dataflow-runner-project
region: asia-east1
tempLocation: gs://feast-temp-bucket #also required for bq ingestion
subnetwork: regions/asia-east1/subnetworks/default
executable: feast-ingestion.jar
errorsStore:
type: file.json
options:
path: gs://feast-errors
monitoring:
period: 5000
initialDelay: 600000
statsd:
host: localhost
port: 8125
# DB CONFIG #
spring.jpa.properties.hibernate.format_sql: true
spring.datasource.url: "jdbc:postgresql://localhost:5432/postgres"
spring.datasource.username: postgres
spring.datasource.password: password
spring.jpa.hibernate.naming.physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
spring.jpa.hibernate.ddl-auto: update
# APP METRICS #
management.metrics.export.simple.enabled: false
management.metrics.export.statsd.enabled: true
management.metrics.export.statsd.host: localhost
management.metrics.export.statsd.port: 8125
We can still continue to support env vars for overriding config.
Is your feature request related to a problem? Please describe.
Configuration for feast is currently done using environment variables only. As the number of parameters grows in size, this method of configuring the deployment becomes increasingly unwieldy.
Describe the solution you'd like
We want to move away from KVs, which are limited when it comes to nested config, eg. for job options. Currently we set it as a json string.
Describe alternatives you've considered
If we use yaml, it would potentially look something like this:
We can still continue to support env vars for overriding config.