-
Notifications
You must be signed in to change notification settings - Fork 108
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
Man pages for pbench-agent commands #3442
Man pages for pbench-agent commands #3442
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.
Hi Siddardh,
Thanks for including reviews done earlier on the document.
I always get confused between pbench-results-move and pbench-move-results, can you add explanation their.
pbench-results-move used when pushing results using token.
pbench-move-results with ssh way.
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.
Thanks Siddardh for the update. Looks good to me.
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 is a good start!
I'm not entirely sure we want a combined "man page" for all the agent commands in one file. I could see these in separate files, even building a directory tree for "performance tool management commands", "benchmark commands", and "publish to Pbench Server" commands... or at least a section/subsection hierarchy that makes the command "classes" easier to locate.
I'd like to see a more clear distinction between the 0.69 Server pbench-*-results
commands and the 1.0 Server pbench-results-move
command. I'm tempted to suggest a "Publish results to server" section with "Pbench Server 0.69" and "Pbench Server 1.0" sub-sections to keep them clearly separated and provide more context about why they're separated. E.g., "The Pbench Server 0.69 uses an SSH protocol to push tarballs, requiring that the agent have a private id_rsa
key for the server's pbench
account; the Pbench Server 1.0 uses an encrypted authentication token identifying a specific user account."
But also, if we're including pbench-user-benchmark
why aren't we including pbench-fio
and pbench-uperf
and such?
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 is a good start. However, I have some thoughts:
- First, there should be a table-of-contents at the top, grouped topically, with subsections or annotations pointing out which commands are v0.69 commands (and soon to be deprecated) and which are v1.0 commands.
- Second, there are a bunch of places where we should be using monospaced font (e.g., anything in single quotes should probably be in "back quotes").
- The text around "required" options should probably be reworked, since most of them pull their values from environment variables which are automatically defined for most users, so the options don't actually have to be specified in typical usage.
And, I'm concerned about how we are going to keep this file in sync with the help text produced by the commands. I'm wondering if this file shouldn't be generated automatically from the commands.
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.
seems even better now.
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.
Some "nits", but I think this looks good enough as a base reference that I'm going to approve. It doesn't have to be "perfect" as long as it's not wrong...
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 is looking good, but I think it needs another round of polish.
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.
Thanks Siddardh for enhancing it further.
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.
Sorry about this, Siddardh; I've discovered that the header levels mean more to GitHub than I'd thought, so I think we need to take this a bit more seriously. 😦
Already 131 comments into this PR. |
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 is looking great, but with this latest change there are now places where we've lost the indications of which command options take values. I'm OK with using [OPTIONS]
as a shorthand in the command line synopses, but, if we're going that direction, then the individual option synopses have to indicate when the options take values. Also, there are a few cases where the options were only noted in the command line synopses; we now need to ensure that they aren't missing from option descriptions. And, there is a similar problem with command arguments. (And, I noted a couple of new nits.)
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.
I made a bunch of comments I noticed on re-reading, but assuming that this gets merged soon enough I'll edit it in my --relay
PR anyway and I'd be happy to do additional cleanup then ...
… for some descriptions
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.
OK, I think that last update covers everything. There's one improvement to be made, but Dave says that he will do a clean-up pass in his coming PR, so let's dump that on him. 😉
@@ -45,7 +45,7 @@ | |||
This command clears the results directory from `/var/lib/pbench-agent` directory. | |||
|
|||
**OPTIONS** | |||
`-C`, `--config` PATH | |||
`-C`, `--config PATH` |
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.
The way it was wasn't bad...the thing is, if the user uses -C
, s/he still needs to provide PATH
...so we need some way to convey that -C
and --config
are synonyms, each requiring a value.
Something like
`[-C | --config] <PATH>`
or
`-C <PATH>`, `--config <PATH>`
I've also seen man pages (like du(1)
) which add text like "Mandatory arguments to long options are mandatory for short options too" and then the option synopses look like -B, --block-size=SIZE
.
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.
Yeah, I was moderately happy with the old "-C
, --config
PATH" although something like Webb's more explicit alternation syntax plus a symbolic placeholder would be nicer. Like [-C | --config] <path>
. But that's a detail, and I can clean this up after I rebase when I add the new options.
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.
Yeah; good enough. I'll tweak stuff after I rebase. Thanks a lot for all the work, Siddardh! Despite the volume of comments, this is a great base to work from. (And to misquote a famous agrammatical American movie line, "all your hard work ain't been in vain for nothing." 😆
@@ -45,7 +45,7 @@ | |||
This command clears the results directory from `/var/lib/pbench-agent` directory. | |||
|
|||
**OPTIONS** | |||
`-C`, `--config` PATH | |||
`-C`, `--config PATH` |
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.
Yeah, I was moderately happy with the old "-C
, --config
PATH" although something like Webb's more explicit alternation syntax plus a symbolic placeholder would be nicer. Like [-C | --config] <path>
. But that's a detail, and I can clean this up after I rebase when I add the new options.
PBENCH-1142 This changes the Pbench Agent `results` mechanism to support a new mode, refactoring the `CopyResults` class into a hierarchy with `CopyResultToServer` and `CopyResultToRelay` and an overloaded `push` to do the work. The `--token` option is now required only when `--relay` is not specified. In addition to `--relay <relay>` to push a manifest and tarball to a Relay, I added a `--server <server>` to override the default config file value, which should allow us to deploy a containerized Pbench Agent without needing to map in a customized config file just to set the Pbench Server URI. The agent "man pages" have been updated with the new options, and some general cleanup left over from distributed-system-analysis#3442. _NOTE_: with this change we have a full end-to-end relay mechanism, but it's simplistic. You need to start a relay server manually from the file relay repo at `distributed-system-analysis/file-relay`, and supply that URI to the `pbench-results-move --relay <relay>` command. In the future we'd like to package the relay and allow management and hosting through Pbench Agent commands within a standard container.
PBENCH-1142 This changes the Pbench Agent `results` mechanism to support a new mode, refactoring the `CopyResults` class into a hierarchy with `CopyResultToServer` and `CopyResultToRelay` and an overloaded `push` to do the work. The `--token` option is now required only when `--relay` is not specified. In addition to `--relay <relay>` to push a manifest and tarball to a Relay, I added a `--server <server>` to override the default config file value, which should allow us to deploy a containerized Pbench Agent without needing to map in a customized config file just to set the Pbench Server URI. The agent "man pages" have been updated with the new options, and some general cleanup left over from distributed-system-analysis#3442. _NOTE_: with this change we have a full end-to-end relay mechanism, but it's simplistic. You need to start a relay server manually from the file relay repo at `distributed-system-analysis/file-relay`, and supply that URI to the `pbench-results-move --relay <relay>` command. In the future we'd like to package the relay and allow management and hosting through Pbench Agent commands within a standard container.
PBENCH-1142 This changes the Pbench Agent `results` mechanism to support a new mode, refactoring the `CopyResults` class into a hierarchy with `CopyResultToServer` and `CopyResultToRelay` and an overloaded `push` to do the work. The `--token` option is now required only when `--relay` is not specified. In addition to `--relay <relay>` to push a manifest and tarball to a Relay, I added a `--server <server>` to override the default config file value, which should allow us to deploy a containerized Pbench Agent without needing to map in a customized config file just to set the Pbench Server URI. The agent "man pages" have been updated with the new options, and some general cleanup left over from distributed-system-analysis#3442. _NOTE_: with this change we have a full end-to-end relay mechanism, but it's simplistic. You need to start a relay server manually from the file relay repo at `distributed-system-analysis/file-relay`, and supply that URI to the `pbench-results-move --relay <relay>` command. In the future we'd like to package the relay and allow management and hosting through Pbench Agent commands within a standard container.
PBENCH-1142 This changes the Pbench Agent `results` mechanism to support a new mode, refactoring the `CopyResults` class into a hierarchy with `CopyResultToServer` and `CopyResultToRelay` and an overloaded `push` to do the work. The `--token` option is now required only when `--relay` is not specified. In addition to `--relay <relay>` to push a manifest and tarball to a Relay, I added a `--server <server>` to override the default config file value, which should allow us to deploy a containerized Pbench Agent without needing to map in a customized config file just to set the Pbench Server URI. The agent "man pages" have been updated with the new options, and some general cleanup left over from distributed-system-analysis#3442. _NOTE_: with this change we have a full end-to-end relay mechanism, but it's simplistic. You need to start a relay server manually from the file relay repo at `distributed-system-analysis/file-relay`, and supply that URI to the `pbench-results-move --relay <relay>` command. In the future we'd like to package the relay and allow management and hosting through Pbench Agent commands within a standard container.
PBENCH-1142 This changes the Pbench Agent `results` mechanism to support a new mode, refactoring the `CopyResults` class into a hierarchy with `CopyResultToServer` and `CopyResultToRelay` and an overloaded `push` to do the work. The `--token` option is now required only when `--relay` is not specified. In addition to `--relay <relay>` to push a manifest and tarball to a Relay, I added a `--server <server>` to override the default config file value, which should allow us to deploy a containerized Pbench Agent without needing to map in a customized config file just to set the Pbench Server URI. The agent "man pages" have been updated with the new options, and some general cleanup left over from distributed-system-analysis#3442. _NOTE_: with this change we have a full end-to-end relay mechanism, but it's simplistic. You need to start a relay server manually from the file relay repo at `distributed-system-analysis/file-relay`, and supply that URI to the `pbench-results-move --relay <relay>` command. In the future we'd like to package the relay and allow management and hosting through Pbench Agent commands within a standard container.
* Add basic relay support to Pbench Agent PBENCH-1142 This changes the Pbench Agent `results` mechanism to support a new mode, refactoring the `CopyResults` class into a hierarchy with `CopyResultToServer` and `CopyResultToRelay` and an overloaded `push` to do the work. The `--token` option is now required only when `--relay` is not specified. In addition to `--relay <relay>` to push a manifest and tarball to a Relay, I added a `--server <server>` to override the default config file value, which should allow us to deploy a containerized Pbench Agent without needing to map in a customized config file just to set the Pbench Server URI. The agent "man pages" have been updated with the new options, and some general cleanup left over from #3442. _NOTE_: with this change we have a full end-to-end relay mechanism, but it's simplistic. You need to start a relay server manually from the file relay repo at `distributed-system-analysis/file-relay`, and supply that URI to the `pbench-results-move --relay <relay>` command. In the future we'd like to package the relay and allow management and hosting through Pbench Agent commands within a standard container.
Add man_page.md file for the pbench-agent commands.
Note: This PR doesn't cover all the pbench-agent commands. For the 1st iteration, decided to cover the commonly used pbench-agent commands. If needed we can add more in subsequent iterations