Willingness to contribute

Yes. I can contribute a fix for this bug independently.

Feature Request Proposal

Hi, thanks for your work!

Current Dockerfile FeathrSandbox.Dockerfile for local tests and development looks outdated. It looks like a mono-container with a group of services that needs to be decoupled.

My suggestion is to move FeathrSandbox.Dockerfile into feathr-sandbox and leave only Feathr & JupyterLab in the file.
In addition to the dockerfile, it would be great to have several docker-compose examples with related env-files describing services used together with Feathr.

Also, using .sh-files seems like a redundant step that would be nice to remove. After separating services into independent containers, such files will not be needed.

I made a few examples in the process of studying the project and will be happy to contribute after consulting about the bug i encountered with Feathr&Spark (#1217).

Motivation

What is the use case for this feature?

I studied the repository in some detail so I think that there is a lack of examples with transparent deployment for community. One container does not fully deploy the system on somebody's host. It combines a set of services and the study of them at runtime becomes quite difficult. My suggestion would help increase the community interest in the project and attract more people in its further development.

Details

I have prepared examples that we can work on: Link

What component(s) does this feature request affect?

• Python Client: This is the client users use to interact with most of our API. Mostly written in Python.
• Computation Engine: The computation engine that execute the actual feature join and generation work. Mostly in Scala and Spark.
• Feature Registry API: The frontend API layer supports SQL, Purview(Atlas) as storage. The API layer is in Python(FAST API)
• Feature Registry Web UI: The Web UI for feature registry. Written in React