-
Notifications
You must be signed in to change notification settings - Fork 30
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
Support for ECR Images #614
Comments
Thanks for reporting @ngoue - I'll investigate what could be done to potentially address this issue |
@pgrzesik - have there been any updates on this front? We'd love to leverage the dashboard, but are currently constrained here. |
Hello @rjay98 - I'm sorry, unfortunately, the issue is still present. I will bring up the issue internally and will let you know. |
Hello, thanks a lot for being patient here. I've brought the issue to the product team and they're aware of the problem, however, there are no immediate plans to address this problem but that might change in the future. Unfortunately, potentially wrapping the code that gets packaged into the docker image is very tricky as the building process inside the image can be wildly different for each of the use cases. If there is any development on that front, I will share the information here. |
I'd like to request (or even work on) adding support for ECR images with the Serverless Dashboard. From what I understand, the issue is that packaging is done strictly by the associated
Dockerfile
and therefore the plugin does not have the ability to build the wrapped handler files (e.g.s_*.py
) at package time.Would it be possible to add a plugin command for generating those files myself so they can be included in my
Dockerfile
. Perhaps something like,sls dashboard wrap my_api.handler
. This would then generate as_my_api.py
file with the wrapped handler to properly support dashboard reporting/monitoring of invocations.I opened an issue in the serverless repo suggesting we work on some tool to still package the code before building the docker image, but this solution would also solve my problem. Then users building their own images can just be responsible for wrapping and including their wrapped handlers.
The text was updated successfully, but these errors were encountered: