docs: add some networking troubleshooting docs

[squeed]

Perhaps an unnecessary amount of debugging information. But networking is often the canary in the coal mine, issue-wise.

[wking]

I've dropped some minor copy-edits inline.

Stepping back, should this live in the network operator repo where we can link to it?

[wking]

nit: This block has a command with no output. Personally I like:

```console

with a prompt tfor those, but this project hsd an existing patter of:

```sh

with no prompt. More in #27.

[abhinavdahiya]

Stepping back, should this live in the network operator repo where we can link to it?

I think we are going to answering questions on network readiness quite often and this might help us answer some easy questions for users. and then redirect them to SDN team.

[wking]

Stepping back, should this live in the network operator repo where we can link to it?

I think we are going to answering questions on network readiness quite often and this might help us answer some easy questions for users. and then redirect them to SDN team.

But folks might use the network operators outside of OpenShift? Or, maybe more likely, have issues with networking in running OpenShift clusters and then not think to check the installer docs? Basically, if docs are specific to a single operator (like these? I dunno), then I think they should live with that operator, and we can link them from here. Having a link shouldn't make life too much harder for folks who do think of checking the installer docs first, should it?

[squeed]

Updated and repushed.

If the network fails, the installer generally fails (since we never leave the boostrap control plane). So I think its pretty reasonable to have some network troubleshooting tasks. In the future, we'll have to have separate diagnostic tasks for each network type (and that should live in Proper Documentation), but this is more to help people before we ship 4.1.

[wking]

Updated and repushed.

You still need to change console -> sh and drop the $ from fenced blocks that contain just a shell command with no output.

If the network fails, the installer generally fails (since we never leave the boostrap control plane). So I think its pretty reasonable to have some network troubleshooting tasks.

I agree that we should have network troubleshooting docs. I'm just not sold (yet ;) on the installer being the right place for them. Does networking never get through installation but then fail later on? Is everyone with networking trouble at any point going to come looking in in the installer docs? And do installer maintainers understand this well enough to maintain these docs (I don't ;)? Perhaps as a middle ground we could put these in docs/user/troubleshoot-network.md with cross-links between that and the generic troubleshooting.md? Then they'd be easy to reposition if we decide to move them out of the installer later? Or maybe the other maintainers feel like this is a good fit for our troubleshooting.md, in which case I'm fine with it ;).

[squeed]

Fixed the markdown fences.

I'm not gonna lie, I don't care where this goes. Someone asked me to write a troubleshooting doc, so I wrote it. Take it or leave it.

[abhinavdahiya]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, squeed

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [abhinavdahiya]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment