subcommand for job renames

[problame]

• job names are persisted locally on disk / in zfs abstractions
• job names are not persisted on remote systems

Therefore, a CLI command could do the job.

Requirements:

• be able to render a plan of what it is going to do
• be idempotent (i.e. work even if it crashes in the middle)
  • allowed to make the assumption that the original job name has not yet been reused
• 3-step interaction
  • persist somewhere that the job is being renamed
  • make sure the job is not running in the daemon (and won't run on restart)
    • sufficient to kill the daemon and have some kind of disabled blacklist somewhere
  • do the idempotent rename operation(s)
  • tell the user to
    • rename the job in the zrepl.yml
    • invoke a zrepl rename complete OLDJOB NEWJOB command that
      • un-blacklists the old job name (making it available for a new job definition)
      • re-starts the new job name (pbly ok to just restart the daemon, or tell the user to do it)

Additional thoughts:

• we could also think about having job GUIDs and only aliases to refer to jobs, but those GUIDs would also need to be stored in some kind of database etc
  • design proposals welcome, in the meantime, a rename command is pbly good enough

[helamonster]

i see that job names are used in the zfs CURSOR bookmarks. Are they used anywhere else?

[problame]

They are used in the step holds as well (see 'Overview' in the docs). If I remember correctly, that's about it at this time.

[mdlayher]

I ran into a case today where this would be useful. I'm an experienced Go programmer and wouldn't mind digging in a bit to see if I could contribute. I notice this formerly had a "good first issue" tag but that was removed?

[problame]

Compared to the other issues marked 'good first issue', this one is a little more complicated. But nothing that can't be done.

I guess the file endpoint/endpoint_zfs_abstraction.go is a good place to start. Specifically, search for callers of Abstraction.GetJobID():

zrepl/endpoint/endpoint_zfs_abstraction.go

Line 49 in 1c937e5

GetJobID() *JobID // may return nil if the abstraction does not have a JobID

[problame]

Also, I'm willing to relax the requirements on crash consistency a little:

• only allow the operation to take place when the daemon is not running (best effort check)
• if the rename fails mid-way, require that the user
  • retry the command until it succeeds (=> idempotency)
  • not restart the daemon until then