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

Apply validation of attributes to Resource, move attribute related logic to util package #1834

Merged
merged 20 commits into from
May 24, 2021

Conversation

srikanthccv
Copy link
Member

Fixes #1831

@srikanthccv srikanthccv requested a review from a team as a code owner May 10, 2021 15:32
@srikanthccv srikanthccv requested review from codeboten and aabmass and removed request for a team May 10, 2021 15:32
@lzchen
Copy link
Contributor

lzchen commented May 10, 2021

What is being changed specifically that we are lacking from the specs?

@srikanthccv
Copy link
Member Author

srikanthccv commented May 10, 2021

Resource doesn't check the types of attribute values. It either fails at the serialization or skips silently when exporting.

@srikanthccv
Copy link
Member Author

Hmm probably title is misleading but I can't come up with better one.


_logger = logging.getLogger(__name__)


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should all of this logic go into the api?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe if we want to provide this as part of public api package

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can be the first :)

CHANGELOG.md Outdated Show resolved Hide resolved
Co-authored-by: Leighton Chen <lechen@microsoft.com>
@srikanthccv srikanthccv changed the title Update Resource attributes to comply with Attributes specification Apply validation of attributes to Resource, move attribute related logic to util package May 10, 2021
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()))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: please group all the true/false together. makes it easier to read :)


_logger = logging.getLogger(__name__)


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 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.

@owais
Copy link
Contributor

owais commented May 14, 2021

Instead of utils, can we create an attributes package even if all it contains are private functions. "utils" tend to grow over time and eventually defeat the purpose of having modules as nothing is discoverable anymore :)

At least a utils/attributes sub-module would be nice if we don't want to add a root level module.

@lzchen
Copy link
Contributor

lzchen commented May 18, 2021

@lonewolf3739
We can talk about this in the SIG meeting.

@lzchen lzchen self-assigned this May 20, 2021
@srikanthccv
Copy link
Member Author

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.

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update 👍

@lzchen
Copy link
Contributor

lzchen commented May 20, 2021

@lonewolf3739
I believe we wanted this to be in utils/attributes folder right?

Copy link
Contributor

@owais owais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make these functions private for now? I have a couple of in-progress PRs (#1839, #1847) that might need to use or modify these functions. Even though I plan to get them merged before next release, it'd be safer to if we don't make these public in this PR.

@srikanthccv
Copy link
Member Author

srikanthccv commented May 21, 2021

@lonewolf3739
I believe we wanted this to be in utils/attributes folder right?

@owais suggested creating attributes package and it made more sense in terms of discoverability. I am fine with either way. What do you think?

@lzchen
Copy link
Contributor

lzchen commented May 24, 2021

@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?

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?

@srikanthccv
Copy link
Member Author

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.

@lzchen
Copy link
Contributor

lzchen commented May 24, 2021

@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).

@lzchen lzchen merged commit eda57f7 into open-telemetry:main May 24, 2021
@srikanthccv srikanthccv deleted the issue-1831 branch May 24, 2021 23:15
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

Successfully merging this pull request may close these issues.

service.instance.id not working
4 participants