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
Is your feature request related to a problem? Please describe.
Feast has a concept of a project that can be used to host several completely isolated resources in a shared registry. This can be used to co-host registry objects for unrelated teams or environments like dev, test, prod. (honestly, not sure why would anybody do that though, a separate registry for each sounds a lot better, there's not much of an overhead). This doesn't address the use case when a user might want to host a shared pool of resources with various ownerships, for example some core objects (entities) that are managed by a core team, with additional feature views and feature services that are owned by different teams.
This is hard to achieve with normal feast apply workflow as applying a subset of feast objects will lead to the removal of other objects.
Describe the solution you'd like
Introduce a concept of a subproject (or maybe call this something else, happy to consider alternatives) which will be used to mark feast objects that are managed as a whole from a single git repository. The user should be able to run feast apply --subproject team-1 that will overwrite only existing objects that were part of this subproject. Any attempt to apply a change that will break the integrity of a registry as a whole (trying to remove an entity that's referenced by a feature view that belongs to another subproject) should lead to an error.
Another option is to repurpose the existing project label for this, but this might be too big of a breaking change.
P.S. Subprojects should eventually also fit into the overall security model #4198.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Feast has a concept of a
project
that can be used to host several completely isolated resources in a shared registry. This can be used to co-host registry objects for unrelated teams or environments like dev, test, prod. (honestly, not sure why would anybody do that though, a separate registry for each sounds a lot better, there's not much of an overhead). This doesn't address the use case when a user might want to host a shared pool of resources with various ownerships, for example some core objects (entities) that are managed by a core team, with additional feature views and feature services that are owned by different teams.This is hard to achieve with normal
feast apply
workflow as applying a subset of feast objects will lead to the removal of other objects.Describe the solution you'd like
Introduce a concept of a
subproject
(or maybe call this something else, happy to consider alternatives) which will be used to mark feast objects that are managed as a whole from a single git repository. The user should be able to runfeast apply --subproject team-1
that will overwrite only existing objects that were part of this subproject. Any attempt to apply a change that will break the integrity of a registry as a whole (trying to remove an entity that's referenced by a feature view that belongs to another subproject) should lead to an error.Another option is to repurpose the existing
project
label for this, but this might be too big of a breaking change.P.S. Subprojects should eventually also fit into the overall security model #4198.
The text was updated successfully, but these errors were encountered: