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

Inconsistency in "Function" "memorySize" data type and property needs clarification of memory unit #27

Open
austinkelleher opened this issue Jul 24, 2020 · 1 comment
Assignees

Comments

@austinkelleher
Copy link
Contributor

See: https://github.com/JupiterOne/data-model/blob/master/src/schemas/Function.json#L24

Problem

Currently, the Function memorySize property has an inconsistent type between the data model and the AWS integration. In the data-model, the type is listed as a "string" and in the AWS integration, the data type is a "number". Additionally, it's unclear from the name of the property what the memory unit is (e.g. mb, gb, etc.).

Proposal

  • Change the data type to a number
  • Rename the property to have unit clarity. I think we should standardize on a memory unit size to make it clear in the property name and description fields what the unit is. Google Cloud makes the property name very distinct: availableMemoryMb. Thoughts on updating the property field to match Google Cloud?
@austinkelleher austinkelleher self-assigned this Jul 24, 2020
@aiwilliams
Copy link
Contributor

I think using number is absolutely the way to go to support math, and I think availableMemoryMb is an excellent name, assuming memorySize isn't an AWS name that we could stick with but move to memorySizeMb.

This proposal will require:

  1. Add new property, keeping old one for now
  2. Find all saved/managed queries that use memorySize and change to use availableMemoryMb
  3. Drop memorySize

What is the effort involved in 2?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants