docs: add troubleshooting how-to for deployment issues

[gatici]

Description

This PR adds a troubleshooting how-to for Charmed Aether SD-Core deployment problems.

Checklist:

• [ ] Documentation follows the Canonical Documentation Style Guide
• [ ] I have performed a self-review of my own code
• [ ] I have made corresponding changes to the documentation
• [ ] I have added tests that validate the behaviour of the software
• [ ] I validated that new and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules
• [ ] I have bumped the version of the library

[gatici]

My general impression is that there's not much actual troubleshooting here. We're either telling the users to create a bug report or to read the manual again. Do we actually need this guide?

What is your proposal that this deployment troubleshooting how-to should include ?

[Gmerold]

My general impression is that there's not much actual troubleshooting here. We're either telling the users to create a bug report or to read the manual again. Do we actually need this guide?

What is your proposal that this deployment troubleshooting how-to should include ?

Personally I think we don't need it.

[gruyaume]

My general impression is that there's not much actual troubleshooting here. We're either telling the users to create a bug report or to read the manual again. Do we actually need this guide?

What is your proposal that this deployment troubleshooting how-to should include ?

Personally I think we don't need it.

My general impression is that there's not much actual troubleshooting here. We're either telling the users to create a bug report or to read the manual again. Do we actually need this guide?

What is your proposal that this deployment troubleshooting how-to should include ?

Personally I think we don't need it.

@Gmerold Is your recommendation to not have any troubleshooting guide at all?

I'd be ok with this if we think they're not useful. I don't want to add more documentation for no reason.

[Gmerold]

My general impression is that there's not much actual troubleshooting here. We're either telling the users to create a bug report or to read the manual again. Do we actually need this guide?

What is your proposal that this deployment troubleshooting how-to should include ?

Personally I think we don't need it.

My general impression is that there's not much actual troubleshooting here. We're either telling the users to create a bug report or to read the manual again. Do we actually need this guide?

What is your proposal that this deployment troubleshooting how-to should include ?

Personally I think we don't need it.

@Gmerold Is your recommendation to not have any troubleshooting guide at all?

I'd be ok with this if we think they're not useful. I don't want to add more documentation for no reason.

I'm not saying we shouldn't have any troubleshooting guides at all. In fact I think that having them can save us some time in the future. I just don't think we need this particular guide.

EDIT: If we want to keep it as a placeholder for describing typical deployment mistakes in the future, I'd reduce it to just the first point - the one about using an existing model name.

[gatici]

I would like to keep below cases as we do not provide enough information in our tutorials.

• Juju model already exists
• Terraform deploy getting i/o timeout

[Gmerold]

I would like to keep below cases as we do not provide enough information in our tutorials.

• Juju model already exists
• Terraform deploy getting i/o timeout

What could be the reason for getting the I/O timeout? Is it possible that after successful bootstrapping it will still fail?

[gatici]

I would like to keep below cases as we do not provide enough information in our tutorials.

• Juju model already exists
• Terraform deploy getting i/o timeout

What could be the reason for getting the I/O timeout? Is it possible that after successful bootstrapping it will still fail?

Yes, it can fail. Bootstrapping is done using a cloud. After a successful bootstrap process, if the cloud become unreachable for some reasons, Juju controller will be inaccessible and I/O timeout issue appears. Some reasons that make the cloud(microk8s) API unreachable:

• changes in the iptables or firewall in the host
• Host is overloaded (does not have enough memory to run K8s cluster pods)
• K8s cluster certificate expiry issues
• hostname resolution issues etc.

[Gmerold]

Created a bunch of suggestions. Feel free to ignore them if you don't like it.

[gatici]

Created a bunch of suggestions. Feel free to ignore them if you don't like it.

I updated the PR and replied on comments.

[gatici]

Last minor comments. Other than that I think it's OK.

These comments are addressed in the latest commit.