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
Currently my plan is to pass it in as 2 separate options: --errorsStoreType: one of [file.json, stderr, stdout] - type of errors store to write to --errorsStoreOptions: map of options for the errors store
These would be defined in the config for core feast deployment
Sorry, I realised the issue was poorly worded: I meant we should not give error stores the same treatment as other storage specs currently.
The fact that it (1) has to be registered (2) can be retrieved together with all other specs and (3) can be written to as a regular warehouse store by ingestion jobs is what i want to change.
At the same time it would be nice to retain the flexibility to add other potential error store formats in the future, which is why I've split its definition into type and options.
Would errorsStoreOptions be comma separated kvs? eg. x=1,y=2
I was thinking json e.g. {"path":"/path/to/file",...} maybe, but I'm not sure...
Activity
tims commentedon Jan 3, 2019
Can you clarify how would you like to tell ingestion where to store the errors?
zhilingc commentedon Jan 3, 2019
Currently my plan is to pass it in as 2 separate options:
--errorsStoreType: one of [file.json,stderr,stdout] - type of errors store to write to--errorsStoreOptions: map of options for the errors storeThese would be defined in the config for core feast deployment
is this ok @tims?
tims commentedon Jan 3, 2019
That looks suspiciously like a storage spec :)
If we're committed to just files and logs.. we could just log to stderr by default if a file path isn't provided?
I imagine we might want avro or parquet too though... hmm.
Would errorsStoreOptions be comma separated kvs? eg. x=1,y=2
zhilingc commentedon Jan 3, 2019
Sorry, I realised the issue was poorly worded: I meant we should not give error stores the same treatment as other storage specs currently.
The fact that it (1) has to be registered (2) can be retrieved together with all other specs and (3) can be written to as a regular warehouse store by ingestion jobs is what i want to change.
At the same time it would be nice to retain the flexibility to add other potential error store formats in the future, which is why I've split its definition into
typeandoptions.I was thinking json e.g.
{"path":"/path/to/file",...}maybe, but I'm not sure...tims commentedon Jan 6, 2019
I think json is ok, as long as it doesn't cause any shell escaping issues for the core api?
reviewing the rest now
Merge pull request feast-dev#27 from dmartinol/feast-rbac
feat: Add support for data labeling in UI (#5409)
feat: Add support for data labeling in UI (feast-dev#5409)
chore(release): release 0.50.0
chore(release): release 0.50.0
fix: Open source Feast dev sync (#295)