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

feat: adding influxdb scaler #1326

Merged
merged 9 commits into from
Dec 1, 2020
Merged

Conversation

yquansah
Copy link
Contributor

@yquansah yquansah commented Nov 13, 2020

This PR seeks to add the influxdb scaler and relevant tests. InfluxDB is a time series database, which has a tried-and-true use case for application monitoring supporting a wide range of user defined metrics. The scaler gives the user the flexibility to define a threshold value, and that threshold value is compared against the actual queried value.

Checklist

Relates to #1239

@yquansah yquansah force-pushed the yq-add-influx branch 3 times, most recently from 7d44d5d to d93b82a Compare November 13, 2020 04:29
@yquansah
Copy link
Contributor Author

I will be working to update the docs by submitting a PR

return false, err
}

return value > s.metadata.thresholdValue, nil
Copy link
Contributor

Choose a reason for hiding this comment

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

value >0 ?

Copy link
Contributor

@silenceper silenceper left a comment

Choose a reason for hiding this comment

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

Have questions about the value of IsActive?

targetMetricValue := resource.NewQuantity(int64(s.metadata.thresholdValue), resource.DecimalSI)
externalMetric := &v2beta2.ExternalMetricSource{
Metric: v2beta2.MetricIdentifier{
Name: kedautil.NormalizeString(fmt.Sprintf("%s-%s", "influxdb", s.metadata.organizationName)),
Copy link
Member

Choose a reason for hiding this comment

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

The metric name should be unique enough, to allow specify multiple triggers in one Scaler and it should be possible to distinguish between those individual metric names.

I wonder wheter is s.metadata.organizationName enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that could be enough.

Copy link
Member

Choose a reason for hiding this comment

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

What if I want to create two (or more) triggers that use the same organization name? I am not an InfluxDB expert, but I suppose this could be possible?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zroubalik Yes that definitely could be possible

Copy link
Member

Choose a reason for hiding this comment

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

So in this case (when I define two or more influxdb scalers in ScaledObject, that will use the same organization) the generated metric name will be same, right? And that's not ideal :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zroubalik Agreed. There is no passed in info that would make this name unique enough. Would using a timestamp suffice?

Copy link
Member

@zroubalik zroubalik left a comment

Choose a reason for hiding this comment

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

  1. Could you please add an entry to the Changelog? (Unreleased sectin)
  2. Do you think you can add e2e tests for this scaler? https://github.com/kedacore/keda/tree/main/tests

@yquansah
Copy link
Contributor Author

Thanks for all of the feedback.
Yes @zroubalik I can add both of these.

@yquansah
Copy link
Contributor Author

I want to create a client instance that will write data to my influxdb server in kubernetes. Is it okay if I use my own docker image for a job that will write data to server? Or should I port-forward the service (influxdb server) and run a script that will write data to the server?

This is for the e2e tests.

@zroubalik

@zroubalik
Copy link
Member

@yquansah yeah, it is completely ok to use your Docker image, we have started to collect these kind of client apps in the separate repo https://github.com/kedacore/test-tools/tree/master/e2e/images, but you can start with your client first.

@yquansah
Copy link
Contributor Author

@zroubalik Looks like there is a lot of moving parts here. I think i'd rather wait till influxdb 2.0 becomes released on docker hub to reference a stable version of it. Can the e2e tests wait, or is it a requirement for this to get merged?

@zroubalik
Copy link
Member

@zroubalik Looks like there is a lot of moving parts here. I think i'd rather wait till influxdb 2.0 becomes released on docker hub to reference a stable version of it. Can the e2e tests wait, or is it a requirement for this to get merged?

@yquansah so influxdb 2.0 is not released yet? So you would like to wait with this PR for a stable influxdb version? If so, convert this PR to the draft please.

For the e2e test, it is not a hard requirement, but we would like to see it coming in this PR or in a separate one, but as soon as possible after merging the first one. e2e tests are important and even more with the growing list of supported scalers in KEDA :) Thanks!

@yquansah
Copy link
Contributor Author

@zroubalik I found an official release candidate version I can use of influxdb v2. Will be getting a e2e test out. Sorry for the back and forth!!

@zroubalik
Copy link
Member

@yquansah no worries and thanks for update! :)

@yquansah yquansah force-pushed the yq-add-influx branch 2 times, most recently from 7b34f13 to d4bfcea Compare November 26, 2020 05:51
@yquansah
Copy link
Contributor Author

@zroubalik e2e tests, and changes to CHANGELOG section added 😄

@yquansah yquansah requested a review from zroubalik November 26, 2020 06:00
@tomkerkhove
Copy link
Member

Any news on te docs @yquansah?

@yquansah
Copy link
Contributor Author

yquansah commented Nov 26, 2020

@tomkerkhove Yeah I will get that in. I just wanted to get eyes on these last bits here code-wise.

@yquansah
Copy link
Contributor Author

@tomkerkhove As requested here is the documentation PR: kedacore/keda-docs#315

Copy link
Member

@zroubalik zroubalik left a comment

Choose a reason for hiding this comment

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

Looking good, but still have the concern on metricName uniqueness

targetMetricValue := resource.NewQuantity(int64(s.metadata.thresholdValue), resource.DecimalSI)
externalMetric := &v2beta2.ExternalMetricSource{
Metric: v2beta2.MetricIdentifier{
Name: kedautil.NormalizeString(fmt.Sprintf("%s-%s", "influxdb", s.metadata.organizationName)),
Copy link
Member

Choose a reason for hiding this comment

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

So in this case (when I define two or more influxdb scalers in ScaledObject, that will use the same organization) the generated metric name will be same, right? And that's not ideal :)

@tomkerkhove
Copy link
Member

Added a remark on the docs but moving it here - Is the org name purely for InfluxDB Cloud? If so, can the scaler work with other servers as well?

@yquansah
Copy link
Contributor Author

yquansah commented Nov 26, 2020

@tomkerkhove No, org name is used in open source version as well

@tomkerkhove
Copy link
Member

Ok, thanks!

@yquansah yquansah requested a review from zroubalik November 27, 2020 07:03
@zroubalik
Copy link
Member

zroubalik commented Nov 27, 2020

@yquansah you will need to fix the linter errors in Static Checks, see the errors.

to fix the cyclomatic problem, we can ignore this check for the scale_handler.go, to do so, add this part of the code:

    - path: scale_handler.go
      linters:
        - gocyclo

to this line:

And then there is the other problem, that you need to fix in your code.

@yquansah
Copy link
Contributor Author

@zroubalik Static check errors fixed. Thank you!

@zroubalik Agreed. There is no passed in info that would make this name unique enough. Would using a timestamp suffice?

There is still this issue here. What would you suggest?

@zroubalik
Copy link
Member

@zroubalik Static check errors fixed. Thank you!

@zroubalik Agreed. There is no passed in info that would make this name unique enough. Would using a timestamp suffice?

There is still this issue here. What would you suggest?

We should use the similar approach that's being used for Prometheus and Postgresql (change coming in this PR: #1381).
You can refer to this discussion: #1200 (comment)
ie. do the best effort to generate unique metric name, but add optional metricName parameter to the scaler config.

@yquansah
Copy link
Contributor Author

@zroubalik Awesome. I pushed a commit, let me know if this suffices. d95dccf

Copy link
Member

@zroubalik zroubalik left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for the contribution!

@zroubalik zroubalik merged commit 342136e into kedacore:main Dec 1, 2020
@yquansah yquansah deleted the yq-add-influx branch January 9, 2021 08:04
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.

4 participants