-
Notifications
You must be signed in to change notification settings - Fork 59
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
Basic support for historical & realtime stats #66
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. Comments are mainly around project conventions and awareness of some of the helper packages to make your life easier :)
hitRate = float64((agg.Hits - agg.Miss - agg.Errors)) / float64(agg.Hits) | ||
} | ||
|
||
// TODO: parse the JSON more strictly so this doesn't need to be dynamic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noting the TODO here, do you want to do this as part of this PR or at a later date?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do this later. I need to think about whether we can unify these APIs at all.
1635662
to
428e00f
Compare
Force pushed because I rebased the original commits; there are no changes to those aside from conflict fixes. Everything new is in the four new commits. Edit: and the build is still broken while we wait to roll in a new go-fastly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a major blocker, but It would be good to see some test coverage for these commands. Have a look at some of the other command tests for examples. Some thoughts:
- You can parameterize the realtime client in
app.Run()
which will allow us to inject a mock client to control output, like we do for the main API client. - We favour integration style tests for the commands, i.e given these inputs I want this rendered output and have a collection of test helpers to help with this pattern.
👍 Other than the above - LGTM
428e00f
to
ff80545
Compare
Meeting you halfway: this adds tests for the Force pushed to rebase on master: all of the new code is in the last commit. From here my plan is to minimize churn:
|
@pteichman go-fastly should be up to date now :) |
afa8637
to
ef19aaa
Compare
(another rebase; resolving conflicts with the new trunk) |
pkg/stats/historical.go
Outdated
// Exec implements the command interface. | ||
func (c *HistoricalCommand) Exec(in io.Reader, out io.Writer) error { | ||
service, source := c.manifest.ServiceID() | ||
if source != manifest.SourceUndefined { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would still allow for an empty service ID to be sent in the request. Therefore we should error if none passed and always set the input field.
if source != manifest.SourceUndefined { | |
if source == manifest.SourceUndefined { | |
return errors.ErrNoServiceID | |
} | |
c.Input.Service = service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's intentional, an empty service is a valid request: it will dump all of the services that api token can read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Makes sense, however I now feel uncomfortable that the "dump all services" behaviour is essentially an undocumented side-effect and not a first-class discoverable feature - which it should be.
Also the possibility of source
being undefined is reduced for C@E services as the service-id is always persisted and read from the fastly.toml
, which is why we have this pattern as it allows you to omit the --service-id
flag within your project directory.
So a couple of ideas for the future, but don't need to block this PR being merged:
- We add an additional
--all-services
(or similar) flag, which makes it a first-class feature and allows people to intentionally invoke the behaviour. (my preferred option) - We update the flag description for
--service-id
to document that if left blank will return all services.
This gives a lot more context on what's going wrong with output. cmp is already in the tree, so this isn't a new dependency. Failing test output now looks like: --- FAIL: TestApplication/help_argument_only (0.00s) run_test.go:75: output mismatch (-want +got): []string{ ... // 579 identical elements "-n, --name=NAME The name of the S3 logging object", "", - "stats regions", - "List stats regions", - "", - "", "stats historical [<flags>]", "Query historical stats", ... // 13 identical elements }
* Parse stats command flags directly into input structs * Improve some message strings
cf7b860
to
a40943a
Compare
a40943a
to
1a13e69
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM -
Just had a play with it locally and really pleased with out this has taken shape!
This gives the Fastly CLI a foothold in the stats world. Output is very basic, but roughly matches the old Python CLI.
This requires as-yet unmerged changes to go-fastly, so it's not expected to pass the build test.