(LangchainCommonDepsLayer): bundling

krokoko commented 3 months ago

Describe the bug

When instantiating the layer for the X_86 architecture, dependencies are not packaged correctly. Extensions modules are not compiled for the correct platform When selecting X_86 as the layer compatible architecture: While it should be:

Expected Behavior

No runtime error

Current Behavior

Runtime error

Reproduction Steps

see the contract analysis sample

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.132.0

Framework Version

No response

Node.js Version

20

OS

MacOs

Language

Python

Language Version

No response

Region experiencing the issue

any

Code modification

no

Other information

No response

Service quota

[X] I have reviewed the service quotas for this construct

scottschreckengaust commented 2 months ago

Status Update:

Attempts to build platform specific libraries on macOS using the documented Docker platform environmental variable, DOCKER_DEFAULT_PLATFORM, produces the local asset with "x86_64", however upon inspection of the deployed lambda layer shows "aarch64".

Here is the output while building the asset:

Collecting orjson<4.0.0,>=3.9.14 (from langsmith<0.2.0,>=0.1.17->langchain==0.2.5->-r requirements.txt (line 1))
  Downloading orjson-3.10.6-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (50 kB)
Downloading orjson-3.10.6-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (141 kB)
...

The above asset's file is: ~/github.com/aws-samples/generative-ai-cdk-constructs-samples/samples/contract-compliance-analysis/back-end/cdk.out/asset.bcfc35ab235043b602bca1e99df11b1dcce6d0bf563f013c7c50797bb8644a21/python/orjson/orjson.cpython-312-x86_64-linux-gnu.so

However the deployed lambda layer upon downloading and expanding does not match: ~/Downloads/python/orjson/orjson.cpython-312-aarch64-linux-gnu.so

NOTE: without the environmental variable, the python requirements uses a different architecture and the local asset file matches the deployment within the layer ./python/orjson/orjson.cpython-312-aarch64-linux-gnu.so:

Collecting orjson<4.0.0,>=3.9.14 (from langsmith<0.2.0,>=0.1.17->langchain==0.2.5->-r requirements.txt (line 1))
  Downloading orjson-3.10.6-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.metadata (50 kB)
Downloading orjson-3.10.6-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (150 kB)
...

Here is an example that should have worked from the contract analysis example (but didn't):

https://github.com/aws-samples/generative-ai-cdk-constructs-samples/blob/a4342e249645c2a59aa1b770eeaf0e9d78a98f78/samples/contract-compliance-analysis/back-end/README.md?plain=1#L91

$ DOCKER_DEFAULT_PLATFORM=linux/amd64 cdk deploy --require-approval=never

scottschreckengaust commented 2 months ago

Removing the initial (incorrect) S3 object from the CDK bootstrapped bucket and then deploying with the environmental variable does correctly update the Lambda layer.

it appears that if the first deployment with the "aarch64" is deployed, subsequent local assets are not deployed and the S3 stored object is used

scottschreckengaust commented 2 months ago

The https://github.com/awslabs/generative-ai-cdk-constructs/blob/main/src/common/helpers/python-lambda-layer-helper.ts#L61 correctly associates the architectures from the properties, so it is in the Docker build process that does not recognize the requested architectures. Will update the documentation at https://github.com/awslabs/generative-ai-cdk-constructs/blob/main/src/patterns/gen-ai/aws-langchain-common-layer/README.md and for the samples contract analysis https://github.com/aws-samples/generative-ai-cdk-constructs-samples/tree/a4342e249645c2a59aa1b770eeaf0e9d78a98f78/samples/contract-compliance-analysis/back-end#local-environment-or-cloud9

scottschreckengaust commented 1 week ago

Reference to AWS CDK issue here https://github.com/aws/aws-cdk/issues/30962

awslabs / generative-ai-cdk-constructs