-
Notifications
You must be signed in to change notification settings - Fork 415
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
[RFC] FaaS Fields - Stage 0 #1518
Conversation
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.
Thanks, @AlexanderWert!
I left a few comments, but overall this is a great start to the proposal. It meets the criteria for stage 0 by summarizing the value these new fields could add to ECS.
Feel free to make changes to the content based on the feedback, but we can also carry those items forward and discuss more in the stage 1 PR.
rfcs/text/0000-faas-fields.md
Outdated
faas.trigger.name | "POST /{proxy+}/Prod" | Human readable name of the trigger instance. | ||
faas.trigger.id | `arn:aws:sqs:us-east-2:123456789012:my-queue` | The ID of the trigger instance (e.g. Api-ID, SQS-queue-ARN, etc.) | ||
faas.trigger.request_id | e.g. `123456789` | The iD of the trigger request , message, event, etc. | ||
faas.trigger.account.name | "SomeAccount" | The name of the account the trigger belongs to. |
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.
For cloud provider, account, and region information, could we re-use the existing cloud.*
fields?
rfcs/text/0000-faas-fields.md
Outdated
|
||
I'm proposing to add the following kind of fields: | ||
|
||
Field | Example | Description |
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.
Not necessary for stage 0, but in later stages, a Type
column listing the proposed data type of each field would be useful.
Co-authored-by: Eric Beahan <ebeahan@gmail.com>
Have you signed the contributor license agreement?
Have you followed the contributor guidelines?
For proposing substantial changes or additions to the schema, have you reviewed the RFC process?
If submitting code/script changes, have you verified all tests pass locally using
make test
?If submitting schema/fields updates, have you generated new artifacts by running
make
and committed those changes?Is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
Have you added an entry to the CHANGELOG.next.md?