Skip to content
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

Semi-isolated subprojects #4199

Open
tokoko opened this issue May 13, 2024 · 0 comments
Open

Semi-isolated subprojects #4199

tokoko opened this issue May 13, 2024 · 0 comments
Labels
kind/feature New feature or request

Comments

@tokoko
Copy link
Collaborator

tokoko commented May 13, 2024

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

  1. 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.

  2. 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.

@tokoko tokoko added the kind/feature New feature or request label May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant