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

Add docker-compose file with Jupyer notebook #328

Merged
merged 5 commits into from
Dec 8, 2019

Conversation

khorshuheng
Copy link
Collaborator

@khorshuheng khorshuheng commented Nov 26, 2019

This addresses #272.

This PR added a new Jupyter notebook docker image preinstalled with Feast Python SDK. A quick start notebook has also been included for the corresponding docker compose service.

By default, the docker compose file will not rebuild the image. Instead, it will pull images based on the environmental variable defined under infra/docker-compose/.env. Users can either use the default setting, in which the official Feast images are used, or substitute one or more images with their own local image.

Additional settings, such as google credential key, Springboot configurations can be configured via the .env file as well.

Developers who wish to rebuild everything from scratch may run docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d.

Pending tasks before this can be merged:

  • Need to manually build and upload the jupyter docker image to official repository

@feast-ci-bot
Copy link
Collaborator

Hi @khorshuheng. Thanks for your PR.

I'm waiting for a gojek member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@woop
Copy link
Member

woop commented Nov 26, 2019

This is awesome, thanks @khorshuheng.

Did you run any tests to confirm that this was working?

@khorshuheng
Copy link
Collaborator Author

khorshuheng commented Nov 28, 2019

This is awesome, thanks @khorshuheng.

Did you run any tests to confirm that this was working?

The run output is included in the quick start jupyter notebook: https://github.com/gojek/feast/blob/b92602c2af2e5599e20e2a5f7bc72e657974b8e4/infra/docker-compose/jupyter/notebooks/feast-quickstart.ipynb

I don't think i can write any unit test / integration test for this, but i can potentially include more scenarios in the quick start notebook to test different cases. What other scenarios do you think will be useful for the notebook example?

We can also add additional command in the Makefile for starting / stopping the docker compose services, though i am not sure if that is needed for now.

@woop
Copy link
Member

woop commented Nov 28, 2019

This is awesome, thanks @khorshuheng.
Did you run any tests to confirm that this was working?

The run output is included in the quick start jupyter notebook: https://github.com/gojek/feast/blob/b92602c2af2e5599e20e2a5f7bc72e657974b8e4/infra/docker-compose/jupyter/notebooks/feast-quickstart.ipynb

I don't think i can write any unit test / integration test for this, but i can potentially include more scenarios in the quick start notebook to test different cases. What other scenarios do you think will be useful for the notebook example?

We can also add additional command in the Makefile for starting / stopping the docker compose services, though i am not sure if that is needed for now.

Hi @khorshuheng. Yea I dont think its necessary to automate the process. We just need to have a basic script where we can apply, ingest, and retrieve successfully. I just want a way to make sure that the docker compose file and configuration works.

@woop
Copy link
Member

woop commented Nov 29, 2019

/ok-to-test

Copy link
Member

@woop woop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seriously happy about this :)

I think it would be great to add a few lines in a README.md here just to explain how somebody can get up and running (most likely an end user, not a developer)

def pytest_addoption(parser):
parser.addoption("--core_url", action="store", default="core:6565")
parser.addoption("--serving_url", action="store", default="serving:6566")
parser.addoption("--allow_dirty", action="store", default="True")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why you are setting allow-dirty to be true?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intention is to run the e2e test as follows:
docker-compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.e2e.yml run e2e

That way, the e2e test run is entirely self contained. However, the above command will keep the services running even after the e2e test run finished. So for convenience i simply set allow dirty equals to true, otherwise we will need to restart the other services everytime. But i do agree that i should have probably set it to false, for consistency and accuracy of test.

That being say, this e2e test setup will be invalidated once we added test for batch retrieval, because my docker-compose setup has not included batch serving yet, only online serving.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only reason I added that flag was for safety, just in case somebody accidentally runs the test while connected to a production cluster. If you think that situation won't occur, then I guess its fine to make it true.

ADD infra/docker/test-runner/conftest.py ./e2e/
ADD infra/docker/test-runner/run-e2e-test.sh ./
RUN chmod +x run-e2e-test.sh
CMD ["./run-e2e-test.sh"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just running the normal e2e tests?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This is also a way to test the docker compose setup.

@@ -0,0 +1,16 @@
COMPOSE_PROJECT_NAME=feast

FEAST_VERSION=0.3.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we perhaps default to latest and just ensure that we always push the latest tagged docker image?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do.

FEAST_SERVING_STORE_CONFIG_PATH=/etc/feast/feast-serving/store.yaml
FEAST_SERVING_GCP_SERVICE_ACCOUNT_KEY=placeholder

FEAST_JUPYTER_IMAGE=gcr.io/kf-feast/feast-jupyter
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not finding this. Did you end up pushing it, or should I help with that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't pushed it yet. The current dockerfile always build from master branch, which is fine, but for production we should probably install via pip instead. For which versions should the Feast jupyter images be available? All versions after and including 0.3? (0.3.0, 0.3.2)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, ideally all versions.

@khorshuheng
Copy link
Collaborator Author

Seriously happy about this :)

I think it would be great to add a few lines in a README.md here just to explain how somebody can get up and running (most likely an end user, not a developer)

Will add reference link to the Gitbook in the README.md

@khorshuheng
Copy link
Collaborator Author

Add capability for batch serving using Big Query. Other changes:

  • Remove docker-compose.dev. It is probably easier to achieve the same functionality by modifying the .env variable to use a local image instead of the official repository.
  • Remove docker-compose.e2e, as this will be broken once we add batch testing to our e2e test. It is also not user friendly enough. Will fix this using alternative approach in a separate PR.
  • New notebook to demonstrate batch feature retrieval.

@woop
Copy link
Member

woop commented Dec 8, 2019

/test test-golang-sdk

1 similar comment
@woop
Copy link
Member

woop commented Dec 8, 2019

/test test-golang-sdk

@woop
Copy link
Member

woop commented Dec 8, 2019

/approve
/lgtm

@feast-ci-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: khorshuheng, woop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@woop
Copy link
Member

woop commented Dec 8, 2019

/lgtm

@feast-ci-bot feast-ci-bot merged commit 4d1b4f9 into feast-dev:master Dec 8, 2019
@woop woop mentioned this pull request Dec 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants