-
Notifications
You must be signed in to change notification settings - Fork 994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subscription configuration #390
Comments
I suppose it'll be common to want this, and it's a major use case that this issue will support: {
"project": "myproject",
"name": "*",
"version": "latest"
} It seems less obvious to me to have two fields with the stipulation that "All feature sets must be located within these projects" than to require a qualified feature set reference, e.g. A subscription config like this is also supported, I assume: {
"project": "*",
"name": "customer_*",
"version": "latest"
} This is where it becomes slightly confusing / potentially more error-prone to me than a single value like It's mostly cosmetic and subjective though I guess, and something users don't interact with very often. It could be a way to evolve without the breaking change of a new required field: a There's also probably some benefit to structured fields, although I have the feeling feature references will become a pervasive mini language and discrete fields to construct them will start to feel tiresome. Version is particularly troublesome in the second (albeit contrived) example (probably only
I'm not certain what this part means, could you clarify? |
* Project namespacing refactoring * Update Feast Core API and data model to support project namespacing * Update Python SDK to support project namespacing * More refactoring of e2e tests and added uniqueness constraint for features * Fix typo in comment of Field * Update ListFeatureSetRequest to support new subscription logic defined here: #390 * Update subscription logic in Feast Ingestion to support: #390
Thanks for the feedback @ches. I am a bit split on the reference. On the one hand I feel like creating a string reference makes it easier to understand, on the other hand we would be baking this reference into the code base and it would be harder to reverse later. I think that keeping it as individual fields for now makes it more flexible. Otherwise if we introduce new keys to the string it might break the parsers. What I am thinking of settling on is
Allowed
Allowed
Allowed
Allowed
Allowed
Allowed
Allowed
Not allowed (must define project and feature set explicitly)
Not allowed (must define project explicitly)
Not allowed (must define feature set explicitly)
What I meant by consistency is to remove the comparator |
Closing this since it was implemented in Feast 0.4 |
Serving deployments that subscribe to feature sets define their subscriptions as follows
With the introduction of project name spacing, we'd need to include a
project
subscription as well. This would serve to differentiate feature sets across projects. As part of this change, we'd also recommend altering the subscription logic forversions
, mostly to make the subscription more consistent with theproject
name and feature setname
keys.The text was updated successfully, but these errors were encountered: