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

[receiver/azuremonitor] Return concrete types #31264

Open
nslaughter opened this issue Feb 14, 2024 · 12 comments
Open

[receiver/azuremonitor] Return concrete types #31264

nslaughter opened this issue Feb 14, 2024 · 12 comments
Labels
enhancement New feature or request good first issue Good for newcomers receiver/azuremonitor

Comments

@nslaughter
Copy link
Contributor

nslaughter commented Feb 14, 2024

Component(s)

receiver/azuremonitor

Describe the issue you're reporting

This was raised by @michalpristas as a tangential comment to changes in #30224. I believe that the instance of this receiver's code more idiomatic approach of returning concrete types will make our code more maintainable - likely highlighting where we benefit from the layer of abstraction in interfaces and... where we don't.

@nslaughter nslaughter added the needs triage New item requiring triage label Feb 14, 2024
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@crobert-1
Copy link
Member

Sounds like a good idea to me, removing needs triage.

@crobert-1 crobert-1 removed the needs triage New item requiring triage label Feb 28, 2024
Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Apr 29, 2024
@michalpristas
Copy link
Contributor

This also sounds like a good first issue, do we have a label like that?

@crobert-1 crobert-1 added good first issue Good for newcomers and removed Stale labels Apr 29, 2024
@led0nk
Copy link
Contributor

led0nk commented Jun 10, 2024

@michalpristas
Just to make sure i understood the comment from PR #30224, we're talking about silently failing here:

s.armClientOptions = s.getArmClientOptions()
s.clientResources = s.getArmClient()
s.clientMetricsDefinitions = s.getMetricsDefinitionsClient()
s.clientMetricsValues = s.GetMetricsValuesClient()

is this correct?

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Aug 12, 2024
@michalpristas
Copy link
Contributor

@led0nk sorry for very late reply
i was referring to this line
client, _ := s.armClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)

where we ignore error but we return client, that may be nil, but there's no check for nil client going forward

@led0nk
Copy link
Contributor

led0nk commented Aug 13, 2024

@led0nk sorry for very late reply i was referring to this line client, _ := s.armClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)

where we ignore error but we return client, that may be nil, but there's no check for nil client going forward

@michalpristas no worries

Okay i got that, but shouldn't we implement this for those functions also? Because if something fails there, we wouldn't notice either, that's why i was referring to those lines. What do you think?

func (s *azureScraper) getMetricsDefinitionsClient() metricsDefinitionsClientInterface {
client, _ := s.armMonitorDefinitionsClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)
return client
}

func (s *azureScraper) GetMetricsValuesClient() metricsValuesClient {
client, _ := s.armMonitorMetricsClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)
return client
}

@github-actions github-actions bot removed the Stale label Aug 14, 2024
@led0nk
Copy link
Contributor

led0nk commented Aug 14, 2024

@michalpristas while i was working on this issue i found out, that this seems to be already resolved, so i guess we can close the issue, wdyt?

func (s *azureScraper) getArmClient() (armClient, error) {
client, err := s.armClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)
return client, err
}
type metricsDefinitionsClientInterface interface {
NewListPager(resourceURI string, options *armmonitor.MetricDefinitionsClientListOptions) *runtime.Pager[armmonitor.MetricDefinitionsClientListResponse]
}
func (s *azureScraper) getMetricsDefinitionsClient() (metricsDefinitionsClientInterface, error) {
client, err := s.armMonitorDefinitionsClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)
return client, err
}
type metricsValuesClient interface {
List(ctx context.Context, resourceURI string, options *armmonitor.MetricsClientListOptions) (
armmonitor.MetricsClientListResponse, error,
)
}
func (s *azureScraper) GetMetricsValuesClient() (metricsValuesClient, error) {
client, err := s.armMonitorMetricsClientFunc(s.cfg.SubscriptionID, s.cred, s.armClientOptions)
return client, err
}
func (s *azureScraper) start(_ context.Context, _ component.Host) (err error) {
if err = s.loadCredentials(); err != nil {
return err
}
s.armClientOptions = s.getArmClientOptions()
s.clientResources, err = s.getArmClient()
if err != nil {
return err
}
s.clientMetricsDefinitions, err = s.getMetricsDefinitionsClient()
if err != nil {
return err
}
s.clientMetricsValues, err = s.GetMetricsValuesClient()
if err != nil {
return err
}
s.resources = map[string]*azureResource{}
return
}

@michalpristas
Copy link
Contributor

this was part of the problem, other part was that getArmClient returns armClient that is an interface while Func returns a client,
there's no really a benefit of returning an interface. this issue was about replacing this with concrete type implementation armresources.Client. It should be small refactor. if you evaluate that it is problematic we can close the issue

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Oct 15, 2024
@led0nk
Copy link
Contributor

led0nk commented Oct 25, 2024

@michalpristas
there was a pr to solve this, but it went to inactive state.
I'm not sure if this is needed anymore ?

@github-actions github-actions bot removed the Stale label Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers receiver/azuremonitor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants