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

Replace pulling metrics port with using direct config #2856

Merged
merged 5 commits into from
Apr 16, 2024

Conversation

jaronoff97
Copy link
Contributor

@jaronoff97 jaronoff97 commented Apr 15, 2024

Description:
This PR makes it possible to pull the set self-monitoring port from the config directly as opposed to working off interfaces and strings.

NOTE: I'm trying to minimize changes, because the next one is going to be... large... example

Link to tracking Issue(s):
This is the first part of #2603

Testing:
Unit tests

Documentation:
n/a

@jaronoff97 jaronoff97 requested review from a team and swiatekm April 15, 2024 16:25

// GetTelemetry serves as a helper function to access the fields we care about in the underlying telemetry struct.
// This exists to avoid needing to worry extra fields in the telemetry struct.
func (s *Service) GetTelemetry() *Telemetry {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we should have a method on Config to convert it to a more constrained and strictly typed struct containing only information we make use of in the operator. Not a request to do it in this PR, just a thought.

On a separate note, should we cache this to avoid the marshalling and unmarshalling whenever it's accessed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that feels like a good follow up to this – both of those are things we should figure out after we simplify all of the methods that use only maps and strings. Caching would get simpler if we only pass around that constrained struct (because we would probably only create it once)

Comment on lines +169 to +177
jsonData, err := json.Marshal(s.Telemetry)
if err != nil {
return nil
}
t := &Telemetry{}
// Unmarshal JSON into the provided struct
if err := json.Unmarshal(jsonData, t); err != nil {
return nil
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you think we should check this in the admission webhook, so we can be reasonably sure it works? Or is it better to be more permissive and then simply ignore functionality that depends on this value?

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 its better to be permissive IMO, it's much closer to what we do today (i.e. it's fine if someone doesn't set this)... I think we could maybe introduce a "strict" operator mode as part of this issue's resolution

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 thinking about the situation where the parsing fails, that is, the format is inconsistent with what we expect. I think, other than a breaking change in the respective collector core package, this would be safe to do.

With that said, breaking changes in collector core packages can happen, and it'd be unfortunate for us to need to always do a breaking change in the CRD as a result.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I think once everything in the collector is marked stable we could do this... they're working on it!

@jaronoff97 jaronoff97 requested a review from swiatekm April 16, 2024 15:22
@jaronoff97 jaronoff97 merged commit ad0f1f9 into open-telemetry:main Apr 16, 2024
31 checks passed
@jaronoff97 jaronoff97 deleted the 2603-part-one branch April 16, 2024 16:52
ItielOlenick pushed a commit to ItielOlenick/opentelemetry-operator that referenced this pull request May 1, 2024
…#2856)

* checkpoint: with working tests, minimal

* chlog

* issue

* missing change
rubenvp8510 pushed a commit to rubenvp8510/opentelemetry-operator that referenced this pull request May 7, 2024
…#2856)

* checkpoint: with working tests, minimal

* chlog

* issue

* missing change
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.

3 participants