Found while writing the integration test for schedule (#563). Not fixed there, because it is user-facing help text in files that test does not otherwise touch.
#569 settled that cron is the driver and schedule is the domain, and renamed the URL, the provider directory, the processor and the SDK. The CLI's help text was not renamed with them, so every command under osapi client node schedule describes itself using the old name:
$ grep -rn "cron" cmd/client_node_schedule*.go
cmd/client_node_schedule_create.go:35: Short: "Create a cron entry"
cmd/client_node_schedule_create.go:95: String("name", "", "Name for the cron drop-in entry (required)")
cmd/client_node_schedule_get.go:34: Short: "Get a cron entry by name"
cmd/client_node_schedule_get.go:82: String("name", "", "Name of the cron entry (required)")
cmd/client_node_schedule_delete.go:34: Short: "Delete a cron entry"
cmd/client_node_schedule_delete.go:82: String("name", "", "Name of the cron entry to delete (required)")
cmd/client_node_schedule_list.go:34: Short: "List all cron entries"
cmd/client_node_schedule_update.go:35: Short: "Update a cron entry"
cmd/client_node_schedule_update.go:92: String("name", "", "Name of the cron entry to update (required)")
So osapi client node schedule list --help says it lists cron entries, on a command named schedule, against an endpoint named schedule, served by a domain named schedule. The one name per domain rule is in https://osapi-io.github.io/specs/components/osapi/domains and this is the layer that did not get it.
Not all of these are wrong
Two should stay, because they name the driver rather than the domain:
cmd/client_node_schedule_update.go:96 — "New cron schedule expression". It is a cron expression, in the five-field format the cron_schedule validator parses.
- The leading comments that say "represents the cron create command" are describing a variable, not addressing a user, so they are lower priority but should match the command they describe.
The ones to change are the eight that call the thing a user manages a "cron entry". It is a scheduled entry; whether cron implements it is not the caller's concern, which is the whole reason the URL says schedule.
Also worth a look while there
internal/job/types.go aliases these operations as OperationCron* and pkg/sdk/client/operations.go defines them, and the handlers call job.OperationCronCreate against category "schedule":
$ grep -rn "OperationCron" internal/controller/api/node/schedule/*.go | wc -l
5
Those are internal identifiers rather than anything a user reads, so they are a smaller problem than the help text, but they are the same leftover and renaming both together is one change rather than two.
Found while writing the integration test for
schedule(#563). Not fixed there, because it is user-facing help text in files that test does not otherwise touch.#569 settled that
cronis the driver andscheduleis the domain, and renamed the URL, the provider directory, the processor and the SDK. The CLI's help text was not renamed with them, so every command underosapi client node scheduledescribes itself using the old name:So
osapi client node schedule list --helpsays it lists cron entries, on a command named schedule, against an endpoint named schedule, served by a domain named schedule. The one name per domain rule is in https://osapi-io.github.io/specs/components/osapi/domains and this is the layer that did not get it.Not all of these are wrong
Two should stay, because they name the driver rather than the domain:
cmd/client_node_schedule_update.go:96—"New cron schedule expression". It is a cron expression, in the five-field format thecron_schedulevalidator parses.The ones to change are the eight that call the thing a user manages a "cron entry". It is a scheduled entry; whether cron implements it is not the caller's concern, which is the whole reason the URL says schedule.
Also worth a look while there
internal/job/types.goaliases these operations asOperationCron*andpkg/sdk/client/operations.godefines them, and the handlers calljob.OperationCronCreateagainst category"schedule":Those are internal identifiers rather than anything a user reads, so they are a smaller problem than the help text, but they are the same leftover and renaming both together is one change rather than two.