-
Notifications
You must be signed in to change notification settings - Fork 98
feat: add AppConfig as a parameter provider #826
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
Conversation
|
I need to add the documentation. |
docs/utilities/parameters.md
Outdated
| - arn:aws:lambda:us-east-1:027255383542:layer:AWS-AppConfig-Extension:68 | ||
| Environment: | ||
| Variables: | ||
| POWERTOOLS_APPCONFIG_EXTENSION: 'true' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From user experience perspective, is there a way we can build this intelligence within the AppConfig Provider? Like figuring it out from function config etc ?
|
I read an env bar for Extension. Is there a RFC to learn more about this
behaviour?
For Python, we offer normal integration with AppConfig via the Parameters
utility. I couldn’t find a related issue or RFC in the PR hence the ask.
Thanks!
…On Sat, 9 Apr 2022 at 12:57, Pankaj Agrawal ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In docs/utilities/parameters.md
<#826 (comment)>
:
> +
+!!! info "Info: Extension ARN"
+ Make sure you use the ARN for the target region. See the [list](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions-versions.html).
+
+=== "SAM configuration"
+```yaml hl_lines="7 10"
+ParametersFunction:
+ Type: AWS::Serverless::Function
+ Properties:
+ CodeUri: Function
+ Handler: org.demo.parameters.ParametersFunction::handleRequest
+ Layers:
+ - arn:aws:lambda:us-east-1:027255383542:layer:AWS-AppConfig-Extension:68
+ Environment:
+ Variables:
+ POWERTOOLS_APPCONFIG_EXTENSION: 'true'
From user experience perspective, is there a way we can build this
intelligence within the AppConfig Provider? Like figuring it out from
function config etc ?
—
Reply to this email directly, view it on GitHub
<#826 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZPQBCNZKOQMT74ULYABJLVEFPBRANCNFSM5S5BVZXQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
Not sure to understand your point @heitorlessa . The aim of this PR is actually to add AppConfig to the Parameters module. There's no RFC, or whatever, just wanted to provide this feature which is available in python. I'm currently looking for another way to detect if the extension is available rather than using this env var. If you know how, let me know... |
docs/utilities/parameters.md
Outdated
| } | ||
| ``` | ||
|
|
||
| ### Using the AppConfig Extension for Lambda |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the part I was referring to @jeromevdl - we don't support this in Python.
That's why I was asking for a RFC to understand the behaviour so it could be assessed for other languages later.
Does that make sense?
Np, I've added a comment on the exact line that suggests Powertools supports AppConfig Lambda Extension - we don't support that in Python today, hence the ask for a RFC. For your question, AppConfig Lambda Extension runs locally on localhost:2772 - if the socket is open the customer is running AppConfig extension. Under "How it works" https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions.html |
|
@heitorlessa @pankajagrawal16 After writing this RFC, I must admit I'm not so sure it's a good idea to provide this option. |
Looking at drawbacks you mentioned in RFC, I would agree as well. So in my eyes, it will add value to support extension bit if we can technically make DX experience like if users adds app config extension to the function and if they were using this module as well, the functionality should just seamlessly switch to get data from cached extension environment. (without need to do any extra config etc via env variable and caching bit within utility) |
this is the best part of writing, it helps us put things in perspective and to perhaps see it from a different angle. I agree too it's best to drop the Lambda Extension part for now. Future wise, this gives you a better chance to hear customer demand, and work with customers that do use the Extension to confirm whether (1) this would be beneficial, and (2) what a good DX looks like (trade-offs included). |
|
Closing (as per the above comments) |
Issue #, if available:
Description of changes:
Add AppConfig in the parameter module.
Checklist
Breaking change checklist
RFC issue #:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.