fix: Bad feature_servers/multicloud Dockerfile

[bushwhackr]

What this PR does / why we need it:

Multicloud dockerfile is not consistent with the rest of the infra/feature_servers in that it pulls pypi feast package. Whilst others uses the repository code to build feast.

This PR seeks to standardise it so that we are not reliant on the pypi feast package.

NOTE: I am not a user of multicloud feast and do not understand its use case. The Dockerfile I created is based on my observation on what the incumbent was doing.

Which I understood as the following:

1. Install feast into docker image
2. Install runtime dependencies like libarrow-dev

I would need clarification on what is the purpose of this Docker image.

Which issue(s) this PR fixes:

#4135, Related: #3953

Fixes

[bushwhackr]

$ export VERSION=0.37.1
$ export REGISTRY=docker.io
$ make build-feature-server-docker

[+] Building 95.1s (14/14) FINISHED                                                                                                                                                                                                                                                                          docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                                                                                                                                                   0.0s
 => => transferring dockerfile: 1.44kB                                                                                                                                                                                                                                                                                 0.0s
 => [internal] load metadata for docker.io/library/python:3.9-slim                                                                                                                                                                                                                                                     0.9s
    ...
    ...
 => exporting to image                                                                                                                                                                                                                                                                                                 3.6s
 => => exporting layers                                                                                                                                                                                                                                                                                                3.6s
 => => writing image sha256:7cd5076b1023823d01b98297b06544f2ab52964aa6c690ba6b2e8492a841decf                                                                                                                                                                                                                           0.0s
 => => naming to docker.io/library/feature-server:0.37.1
 
$ docker run -it docker.io/library/feature-server:0.37.1 pip show feast | grep Version
Version: 0.37.1.dev16+g0e22da42.d20240423

[bushwhackr]

cc @jeremyary

[jeremyary]

Thanks! We'll take a look. As far as use case goes (as far as I understand), it's a stretch to imagine an end user utilizing every cloud provider we enable, but this checks the box for ensuring whatever variant of subsets a user plugs in are good to go together.

[bushwhackr]

any blockers?

[jeremyary]

@bushwhackr apologies for taking a bit of time. We've had a backlog to work through after resolving our release process issues, so I'm slowly catching us up on PR's. If you wouldn't mind TAL at currrent conflicts, I'll work to bring in your change for our next release. Thanks again for your time spent here & contributions!

[franciscojavierarceo]

i believe this is used during our deployment to verify the build

[shuchu]

I believe the original Dockerfile (with pypi installation) still useful while the users want to test official Feast releases.

[franciscojavierarceo]

was this used at all for deploying any images? Do you want to ask achal or any of the old maintainers?

[bushwhackr]

The only difference in the previous Dockerfile vs Dockerfile.dev was the COPY . . instruction.

The old Dockerfile installs only the pypi available feast package, whereas the old Dockerfile.dev installs the pypi + copies the current codebase into the image.

With the changes I made to the Dockerfile, it does not rely on pypi for the feast package and we would only use the current codebase to install feast. Essentially the same as what old Dockerfile.dev was doing.

[shuchu]

I believe the original Dockerfile (with pypi installation) still useful while the users want to test official Feast releases.

ah, I know the problem. In the document, Development Guide part. The last step of Environment setup is:
docker build -t docker-whale -f ./sdk/python/feast/infra/feature_servers/multicloud/Dockerfile .

As a result, it will call the pypi version....