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

Introduce ability to specify strategies for target allocation #1079

Merged

Conversation

jaronoff97
Copy link
Contributor

Following from #1068 ...

Goals:

  • Introduce a new interface to allow a user of the TA to describe an allocation strategy
    • Allocation strategies are given the changes to the collectors and the target items
    • Allocation strategies can decide how they want to manage state
  • Refactor the allocator's current strategy - least weighted – to be the first strategy

Summary

This PR introduces the Allocator interface, implements it through a refactor of the current allocator, and changes the configuration of the TA to allow for a user to specify an option. The operator's CRDs are also updated to allow the strategy to be specified in the Collector CRD. New tests have been introduced to confirm the strategy works as expected. All previous tests should continue working.

@jaronoff97 jaronoff97 marked this pull request as ready for review September 7, 2022 20:53
@jaronoff97 jaronoff97 requested a review from a team September 7, 2022 20:53
@@ -0,0 +1,91 @@
package strategy
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should move the code in the strategy package back to allocation. CollectorJSON is only used in allocation/http.go and the other JSON structs are also around specifically for the http responses. It would also make naming make more sense (allocation.New() instead of strategy.New()). It feels like we're splitting up code that we don't really need to split up. I think that separating the code in this way makes it a little more difficult to navigate and figure out what's going on.

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 agree, i think a flat strategy here makes more sense for this codebase as it allows us to only export what's necessary

Copy link
Contributor

@kristinapathak kristinapathak left a comment

Choose a reason for hiding this comment

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

Looks great! I left a few minor comments relating to imports and comments.

cmd/otel-allocator/watcher/main.go Outdated Show resolved Hide resolved
cmd/otel-allocator/diff/diff.go Show resolved Hide resolved
cmd/otel-allocator/collector/collector.go Outdated Show resolved Hide resolved
cmd/otel-allocator/discovery/discovery.go Outdated Show resolved Hide resolved
cmd/otel-allocator/discovery/discovery_test.go Outdated Show resolved Hide resolved
cmd/otel-allocator/main.go Outdated Show resolved Hide resolved
@pavolloffay pavolloffay merged commit e4e0cb6 into open-telemetry:main Sep 12, 2022
@jaronoff97 jaronoff97 deleted the pluggable-strategies-take-two branch September 12, 2022 16:23
ItielOlenick pushed a commit to ItielOlenick/opentelemetry-operator that referenced this pull request May 1, 2024
…elemetry#1079)

* Cribbed from another branch

* Refactor part 2

* Fix tests

* Remove deadlocking problem

* Update based on comments

* Unexported some fields, added blocker and comments about invariants

* Comments and imports fixed
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.

5 participants