phase2/rig

Graceful Degradation of Rig Commands

Closed this issue · 5 comments

grayside commented

When executing commands on any environment, steps that are not needed for that specific OS should be skipped. No-op commands that do nothing else should log info output that it was a no-op. Commands that skip steps should indicate the no-op steps via verbose logging. Commands should not be removed from rig on different operating systems.

Our goal is to keep all developers regardless of operating system able to use and talk about the same commands, but have the underlying actions vary as needed and be very explicit when that is happening.

  • config.go: Skip on Linux, maybe Windows?
  • data_backup.go: Skip on Linux, maybe Windows?
  • data_restore.go: Skip on Linux, maybe Windows?
  • dns-records.go: Linux/Windows may need to detect if dnsdock is in use and either no-op or implement an alternate approach to pulling a listing of the *.vm records.
  • dns.go: TBD
  • doctor.go: Do not need to check docker-machine version on Linux. (Under point 2)
  • kill.go: Not needed on Linux.
  • machine.go: Not needed on Linux. No change needed.
  • project_config.go: Compatible
  • project_create.go: Errors without docker-machine. Should we fix that here, or circle back and have machine.go report it is running for Linux purposes?
  • project_sync.go: fixed by #73
  • project.go: Remove separate track Windows compatibility
  • prune.go: Compatible
  • remove.go: Not needed on Linux
  • restart.go: We should run stop and start for Linux even if machine does not exist.
  • start.go: Appears compatible, but testing needed.
  • status.go: Not needed on Linux.
  • stop.go: Should this explicitly turn off the dashboard on Linux?
  • upgrade.go: Not needed on Linux
  • watch.go: Not needed on Linux.

Many of the items in this list are simply flagged as "Not needed on Linux". Currently these commands are likely to throw a confusing error about the docker-machine. We should have a Linux-centric error message if this command is attempted.

febbraro commented

One thing to consider. Do we want to remove commands and options from Linux if they are not supported? or have them there and just no-op? I see you think they should remain, but I can see the case for both. Keep them around so that we dont have to have separate sets of commands to be cross-platform, but on the other hand it is confusing to have commands that do nothing

grayside commented

I was arguing that we should keep them, per my description above. I can see it both ways. One thing we might do is use the help category groupings to have "Virtual Docker Host Management" commands more clearly delineated?

febbraro commented

Those would be

  • Data Backup
  • Data Restore
  • Kill
  • Upgrade
  • Remove
  • A portion of Restart
  • A portion of Start
  • Status
grayside commented

I'm working on stop, restart, and related changes in dashboard.

febbraro commented

This was addressed in an earlier release