Remove Drake's non-Hub Docker instructions

[jwnimmer-tri]

Edit: The original issue title was "CI coverage for Drake's Docker instructions". We have since pivoted to removing the instructions instead.

Our http://drake.mit.edu/docker.html says "Note: This docker image is provided as an experimental feature and is not presently covered by continuous integration" ever since the Docker examples landed in #6196 six months ago. It would be great to have CI coverage so we can keep it working (for fixes like #7653).

Possibly there is some drake-external-examples overlap that makes more sense than doing this directly within the Drake tree itself?

Relates #6315.

/CC @EricCousineau-TRI

[EricCousineau-TRI]

@jamiesnape Should we move Docker build testing to drake-external-examples?
(And only test building a really small portion of Drake?)

[jwnimmer-tri]

Without CI, the Drake Docker documentation has bitrotted, especially with regard to drake-distro vs drake. We should either fix the documentation promptly (and also add CI), or else remove (or maybe just bury) the documentation until someone cares to fix it.

[jamiesnape]

We should bury it or simplify it. Just a Docker container that calls the install_prereqs.sh for now, no graphical, no NVIDIA. When we have resources we can do something more complete.

[EricCousineau-TRI]

It still seems like a useful starting place for others, and provides for a quick local "unprovisioned" test.
Is it possible to run occasional (say once a week or so) CI on the Docker build, if computing resources are expensive? The process could be relatively short, such as building a smaller portion of Drake, possibly running drake_visualizer without pydrake, etc.

Another option is that someone (perhaps myself, if I want to keep it around) just sets a reminder every couple of weeks to run this manually to prevent long-term bitrot.

If none of these are tractable, or the expense is on engineer time setting it up, then yes, I'd be fine with downsizing our Docker instructions, as long as we leave breadcrumbs for easily constructing an NVidia-capable image (as I have found that useful for myself).

[peteflorence]

Hey guys, potentially useful resources to point people to, as I think you guys know, include: (a) Spartan's docker build <https://github.com/RobotLocomotion/spartan/blob/master/setup/docker/README.md> which we use all the time and includes nvidia docker etc (b) Underactuated's <http://underactuated.csail.mit.edu/Spring2018/install_drake_docker.html> Drake docker instructions which are getting used by many students across all nooks and crannies of Windows, Mac, Linux. No nvidia-docker here

…

On Wed, Feb 7, 2018 at 10:49 PM, Eric Cousineau ***@***.***> wrote: It still seems like a useful starting place for others, and provides for a quick local "unprovisioned" test. Is it possible to run occasional (say once a week or so) CI on the Docker build, if computing resources are expensive? The process could be relatively short, such as building a smaller portion of Drake, possibly running drake_visualizer without pydrake, etc. Another option is that someone (perhaps myself, if I want to keep it around) just sets a reminder every couple of weeks to run this manually to prevent long-term bitrot. If none of these are tractable, or the expense is on engineer time setting it up, then yes, I'd be fine with downsizing our Docker instructions, as long as we leave breadcrumbs for easily constructing an NVidia-capable image (as I have found that useful for myself). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7654 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFYQqKRS4RnEMvMeixy_YZRgT3TKuwpyks5tSm7EgaJpZM4RJIoU> .

[jamiesnape]

It is not expensive in terms of AWS costs, it is expensive in terms of infrastructure setup and maintenance. I think we know how to test it in CI, it is not difficult at all, it is just very different from everything else. If it were a high priority, sure we could do it next week, but I personally do not think it should be above release engineering, distribution, and our general lack of testing of the installs.

[jwnimmer-tri]

Another option is that someone (perhaps myself, if I want to keep it around) just sets a reminder every couple of weeks to run this manually to prevent long-term bitrot.

I only care that our docs (and the code they refer to) are correct. If you think manually running some tests can sustain that, and your time is worth spending that way, I'd be satisfied to keep (some variant of) the instructions intact. It just means that PRs are not required to keep those instructions working, but instead you get to repair them by hand after the fact.

[EricCousineau-TRI]

This may be best resolved by provisioning an image on dockerhub, on RobotLocomotion/drake for just Bionic.

Need to decide scope of support:

• Just the packaged Drake, with prereqs + CMake support?
• The full Bazel devel workspace, which can run bazel test //...

[jwnimmer-tri]

@EricCousineau-TRI @jamiesnape I wonder if we can remove https://github.com/RobotLocomotion/drake/tree/master/setup/ubuntu/docker now and update our documentation to point to some of the newer work you've been doing?

[jamiesnape]

I would certainly hope we could. robotlocomotion/drake:latest should be good for all but a small handful of people who might actually want to contribute to Drake yet develop on Docker (and those people should be able to work out what do themselves).

[EricCousineau-TRI]

I'm OK with that.

Along the lines of what @jamiesnape said, it would be nice to still have those commands on record; they're in Git, so yeah, we can remove 'em from master.

[jwnimmer-tri]

I've kicked this to @jamiesnape to work on soon, before apt package work starts. We can open a feature request later to add more hub images for different use cases, etc.