test(network): add behave tests to ensure network errors are handled

[a-dubs]

Why is this needed?

This PR adds functionality that ensures that the various networking exception handling issues that have been raised on various LP bugs, which were resolved during the work for #2647 was completed, are properly caught, handled, and raised.

Test Steps

Run the new behave tests locally:

tox -e behave -- features/network_failures.feature

---

• (un)check this to re-run the checklist action

[github-actions]

PR Checklist

How to use this checklist

How to use this checklist

PR Author

For each section, check a box when it is true.
Uncheck a box if it becomes un-true.
Then check the box at the bottom of the PR description to re-run the action that creates this checklist.
The action that creates and updates this comment will retain your edits.
The action will fail if the checklist is not completed.

PR Reviewer

Check that the PR checklist action did not fail.
Double check that the author filled out the checklist accurately.
If you disagree with a checklist item, start a conversation.
For example, the author may say they don't think integration tests are necessary, but you may disagree.

Bug References

None.

Confirm

• I've properly referenced all bugs that this PR fixes

How to properly reference fixed bugs

• If this PR is related to a Jira item, include an SC-1234 reference in the PR title
• If this PR is fixes a GitHub issue, include a Fixes: #1234 reference in the commit that fixes the issue
• If this PR is fixes a Launchpad bug, include a LP: #12345678 reference in the commit that fixes the issue

Test Updates

Unit Tests

• I have updated or added any unit tests accordingly
• No unit test changes are necessary for this change

Integration Tests

• I have updated or added any integration tests accordingly
• No integration test changes are necessary for this change

Documentation

• Changes here need to be documented and I have referenced the docs PR in the description
• No documentation updates are necessary for this change

Does this PR require review from someone outside the core ubuntu-pro-client team?

• Yes, and I have requested those reviews via GitHub
• No

[dheyay]

Looks good 💯 , some minor nits

[a-dubs]

okay ready for re-review now 🫡 @dheyay

[renanrodrigo]

@a-dubs seems flake8 is not fond of your message strings

[a-dubs]

Tests have been constrained to only xenial and noble since the functionality being tested by this is unlikely to break and only needs tested on the oldest and newest LTS releases.

[dheyay]

Looks good to me, would just need to squash commits before merging

[renanrodrigo]

took the liberty to rebase this after merging #3267 - I'll take a last look and probably merge it

[renanrodrigo]

I think this actually needs to be fixed for us to consider the respective LP bug closed. The problem here is that you don't have internet connection:

• there is no indication that lack of connection was the problem
• how are people supposed to access their dashboard if the network is down?

[renanrodrigo]

@a-dubs if you want, we can land the tests and then you change this message on a next step?

[a-dubs]

Oh shoot yeah you're right. That's not exactly a very useful or specific message. So you're right we definitely need to update the message to consider those bugs closed. As such, I think it would be best if I put this back in draft state and make the changes to the source code such that the source code changes and tests are bundled together into one logical commit, so that when I say "fixes lp #XXXX", I mean fixes

[renanrodrigo]

See how this test is similar to the upper one, except for the service to be disabled?
You can create another column in the table below with "service to disable" so it looks like this:

Suggested change

	Examples: ubuntu release
	| release | machine_type |
	| xenial | lxd-container |
	| noble | lxd-container |
	Examples: ubuntu release
	| release | machine_type | service |
	| xenial | lxd-container | livepatch |
	| xenial | lxd-container | realtime-kernel |
	| noble | lxd-container | livepatch |
	| noble | lxd-container | realtime-kernel |

Feel free to ignore this though - if you think this is good as is, keep it.

[a-dubs]

At first glance, I was initially onboard because i love reducing duplicate code where reasonable, but then I noticed the and stdin 'y\ny' that only exists in the realtime kernel tests and not the livepatch tests.

[renanrodrigo]

good catch forget what I said

[a-dubs]

okay i am unable to forget and got the following working but its a bit jank and not sure how to feel about it:

  Scenario Outline: Network errors for enabling Realtime kernel and Livepatch are handled gracefully
    # This test simulates network failure by disabling internet connection
    # and then trying to enable realtime-kernel or livepatch
    Given a `<release>` `<machine_type>` machine with ubuntu-advantage-tools installed
    When I attach `contract_token` with sudo and options `--no-auto-enable`
    Then the machine is attached
    Then I verify that `<service>` is disabled
    When I disable any internet connection on the machine
    And I verify that running `pro enable <service>` `with sudo` <exit_with_optional_stdin_clause>
    Then stderr contains substring:
      """
      Failed to connect to https://contracts.canonical.com/v1/contracts/
      """
    Then I verify that `<service>` is disabled

    # Realtime kernel is not supported on LXD containers so we must use a VM
    Examples: ubuntu release
      | release | machine_type | service         | exit_with_optional_stdin_clause |
      | xenial  | lxd-vm       | realtime-kernel | and stdin `y\ny` exits `1`      |
      | noble   | lxd-vm       | realtime-kernel | and stdin `y\ny` exits `1`      |
      | xenial  | lxd-vm       | livepatch       | exits `1`                       |
      | noble   | lxd-vm       | livepatch       | exits `1`                       |

[orndorffgrant]

Instead, would using --assume-yes on the enable call allow you to avoid the and stdin so that they can be the same for livepatch and realtime?

[a-dubs]

Oh you can do that??? That would be way better!

[a-dubs]

@dheyay @renanrodrigo this should be ready for review now. let's just get this in and then i'll work on actually improving the exception handling and messaging for networking errors

[renanrodrigo]

testing it good