Apply validation of attributes to Resource, move attribute related logic to util package#1834
Conversation
|
What is being changed specifically that we are lacking from the specs? |
|
Resource doesn't check the types of attribute values. It either fails at the serialization or skips silently when exporting. |
|
Hmm probably title is misleading but I can't come up with better one. |
|
|
||
| _logger = logging.getLogger(__name__) | ||
|
|
||
|
|
There was a problem hiding this comment.
Should all of this logic go into the api?
There was a problem hiding this comment.
Maybe if we want to provide this as part of public api package
There was a problem hiding this comment.
🤔 I guess other SDKs could use a method like this to ensure their attributes are all validated and users could potentially use this to validate/filter their attributes before setting them? not sure how likely these scenarios are though. I could go either ways with this.
There was a problem hiding this comment.
I was more referring to the fact that Attributes are an API concept. I don't think they need to be part of the PUBLIC api, simply private methods that exist in the api package.
There was a problem hiding this comment.
Are Attributess an API concept? I am inclined towards keeping them in sdk because all operations are no-op in api package so we will probably never use them there and if we don't want offer them as a part of public api to user/application owners I don't see any benefit in moving to api package?
There was a problem hiding this comment.
Yes Attribute s are defined in the API. Hmm now thinking about it, this is probably valuable and common enough to be exposed in the public api. It is also defined in the specs so I don't mind increasing our api surface for this. For example, this would be useful for instrumentations to leverage (which only have dependencies on the api).
There was a problem hiding this comment.
I can move this to api util package. I just want to make sure we are okay with making these public because of all of util is pretty much private and internal.
Co-authored-by: Leighton Chen <lechen@microsoft.com>
Resource, move attribute related logic to util package
| self.assertTrue(_is_valid_attribute_value([True, False])) | ||
| self.assertTrue(_is_valid_attribute_value(["ss", "dw", "fw"])) | ||
| self.assertTrue(_is_valid_attribute_value([])) | ||
| self.assertFalse(_is_valid_attribute_value(dict())) |
There was a problem hiding this comment.
nit: please group all the true/false together. makes it easier to read :)
|
|
||
| _logger = logging.getLogger(__name__) | ||
|
|
||
|
|
There was a problem hiding this comment.
🤔 I guess other SDKs could use a method like this to ensure their attributes are all validated and users could potentially use this to validate/filter their attributes before setting them? not sure how likely these scenarios are though. I could go either ways with this.
|
Instead of At least a |
|
@lonewolf3739 |
|
Sorry I couldn't talk during the call. I moved the related code to api and to top level attributes package instead of utils. Please review and add any comments. |
codeboten
left a comment
There was a problem hiding this comment.
Thanks for the update 👍
|
@lonewolf3739 |
@owais suggested creating attributes package and it made more sense in terms of discoverability. I am fine with either way. What do you think? |
|
@lonewolf3739
I'm okay with creating a separate package if the functions are going to be public and available to use. However, if we are making them private, I'd prefer to just have a submodule. Thoughts? |
|
We want to make them public right? That was the original discussion here #1834 (comment). Given that we only use it and probably change as need arises (Owais has some changes in other PR) do you still think we want to make them public? If we want to keep them private there is no need to have separate package. |
|
@lonewolf3739 Yup, I'm fine with making them public. I was just thinking about @owais ' comment, so for the interim, leaving them private for now in a module is okay with me (please make the methods private for now). |
Fixes #1831