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(push): add format builder option #540

Merged
merged 2 commits into from
Feb 25, 2019
Merged

feat(push): add format builder option #540

merged 2 commits into from
Feb 25, 2019

Conversation

FrankSpitulski
Copy link
Contributor

@FrankSpitulski FrankSpitulski commented Feb 24, 2019

Allow users to specify which format the pusher should push in.
Also added tests related to changing the format of the pusher.
This does not break existing functionality since the argument
is varadic.

@beorn7

Signed-off-by: Frank Spitulski fspituls@ucsd.edu

@beorn7
Copy link
Member

beorn7 commented Feb 24, 2019

What's your use case?

My first spontaneous reaction was: The PGW wants the protobuf format. Why add the complication?

My second reaction: You probably have another push target. It would be nice to know which. And then I would suggest to explore HTTP content negotiation.

My thirst reaction: This should be dealt with in the same way as the other options, i.e. with another of the "builder pattern" methods, and not with an additional parameter to New.

@FrankSpitulski
Copy link
Contributor Author

FrankSpitulski commented Feb 24, 2019

My use case is a custom push endpoint that only accepts text encoding. I saw content negotiation as a handler in the promhttp.HandleFor method, but it isn't a pusher and I can't find any examples of agent driven/reactive content negotiation in go so it doesn't appear to be the right path. Can you point me at the existing builder methods for other options? The pusher looks like it's pretty hard coded to just do protobuf. I think I figured out what you meant by builder pattern methods, I'll make an update.

Allow users to specify which format the pusher should push in.

Signed-off-by: Frank Spitulski <fspituls@ucsd.edu>
@FrankSpitulski
Copy link
Contributor Author

I think this implementation fits better @beorn7.

@FrankSpitulski FrankSpitulski changed the title feat(push): add optional format parameter feat(push): add format builder option Feb 24, 2019
@beorn7
Copy link
Member

beorn7 commented Feb 24, 2019

Indeed, agent-driven content negotiation in HTTP seems to be quite hard and needed quite a bit of work on both sides. Thus, it's probably a good thing to let the user of the push package choose the format.

I'll review the code ASAP.

Copy link
Member

@beorn7 beorn7 left a comment

Choose a reason for hiding this comment

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

Looks like this is the right approach. See comments for a comment change and an actual fix.

@@ -197,7 +208,7 @@ func (p *Pusher) push(method string) error {
return err
}
buf := &bytes.Buffer{}
enc := expfmt.NewEncoder(buf, expfmt.FmtProtoDelim)
enc := expfmt.NewEncoder(buf, p.expfmt)
Copy link
Member

Choose a reason for hiding this comment

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

p.expfmt has to be used, too, down in line 236, instead of the hardcoded expfmt.FmtProtoDelim.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good catch, updated

@@ -182,6 +185,14 @@ func (p *Pusher) BasicAuth(username, password string) *Pusher {
return p
}

// Format configures the Pusher to use an encoding format given by the
// provided expfmt.Format. For convenience, this method returns a
// pointer to the Pusher itself.
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps add what the default is (expfmt.FmtProtoDelim) and that that's the one most natural for the Prometheus Pushgateway, and that the Pushgateway will understand all the formats, but custom implementations of a push receiver might require a specific one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

Signed-off-by: Frank Spitulski <fspituls@ucsd.edu>
@beorn7
Copy link
Member

beorn7 commented Feb 25, 2019

Looks great. Thank you very much.

@beorn7 beorn7 merged commit 2daed26 into prometheus:master Feb 25, 2019
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.

None yet

2 participants