Repository navigation
Allow for registering feature that doesn't have warehouse store #5
Description
Registering feature that doesn't have warehouse store will currently return error.
There is a use case that some feature doesn't need warehouse store, so the restriction could be removed.
Additionally, ingestion will need to be updated to do no operation for warehouse storing operation.
Activity
woop commentedon Dec 14, 2018
So the question here is
I think we should have the option to both disable warehouse storage on specific features, as well as deploy a Feast instance without a warehouse (serving only)
tims commentedon Dec 26, 2018
My pull request fixes a typo.. But basically ingestion already supports setting a "no operation" store, for either serving or ingestion. The core api would still need to implement sending it of course.
woop commentedon Jan 3, 2019
So the next step is a PR which adds this functionality to
core?@zhilingc, possible to have a look at this?
tims commentedon Jan 3, 2019
I'm also working on a PR to make ingestion accept an empty storage spec. Though in reality, that will interpreted as a StorageSpec.defaultInstance(). With empty string as the storeid. Ingestion will then treat this as a noop store.
zhilingc commentedon Jan 3, 2019
Ok. You might want to remove the validation check that makes declaring a store mandatory when registering a feature as well.
tims commentedon Jan 3, 2019
Aren't you worried people will register features and they will just all go to noop when they leave it out though? We do need to implement inheriting a system default first.
And then a user needs to be able to override the default to a noop.
Which now that I think about might be a pain. As if they set the store id to an empty string, it will look the same as the default instance, so how will you know when to override it with the default or not?
Remember protos not having optional values means that there's no such thing as a null store id.
woop commentedon Jan 3, 2019
Isn't a better approach simply to have an option to switch off either store? That we we don't have to look at the value and try to guess whether it should be on or off. I think the default should be inheritance.
zhilingc commentedon Jan 3, 2019
When is the default declared? Should it be in the configuration when deploying core Feast? Or is it a necessary step that has to be done by the user before registering features (but after deployment)?
woop commentedon Jan 3, 2019
I think it should be done during initial installation. That way the user could theoretically have all data storage abstracted away from them.
tims commentedon Jan 3, 2019
@zhilingc yes it should be a system default. So it should come with the system.
Users shouldn't even be creating new stores? I think we made store specs creatable accidentally to be honest, because all the others are. They should probably only ever be created by the person who deploys a feast instance.
tims commentedon Jan 9, 2019
Can we close this issue now?
tims commentedon Jan 9, 2019
Closing, but reopen if I missed something.
5 remaining items
pradithya commentedon Jan 18, 2019
Apparently the ingestion job succeed but all feature row didn't pass validation
GitBook: [#5] Fix Gitbook artifacts in 0.15 and update roadmap with S…
Merge pull request feast-dev#5 from dmartinol/remote_offline
# This is a combination of 7 commits.
# This is a combination of 7 commits.
Feature/lrangine master (#6)
Feature/lrangine master (#7)
feat: Snyk vulnerability issues fix. (#4867)
feat: Snyk vulnerability issues fix. (feast-dev#4867)
try feast-dev#5
try feast-dev#5