Backport #85 and #86 upstream PRs

[sgerag]

Main information

Work Item Reference

XCPNG-3456

Related changes (optional)

N/A

Context & Motivation

• XSFeatureNetworkReset: Allow the user to perform an emergency network reset without renaming the management interface

There are some use cases according to which the user would like to perform an emergency network reset by keeping the management interface's name intact. This PR allows the user to proceed to an emergency network reset by requesting the aforementioned behavior.

• XSFeatureInterface: Reset old management interface configuration when switching to a new one

Fix the following issue from upstream:
xapi-project/xsconsole#8

Essentially, reset the old management interface configuration when switching to a new one, in order to avoid network conflicts

Release Target

• We already defined a release target with the release team.
• I haven't talked with the release team, but I have a proposed target.
• I'm not sure, let's talk about it.

Samuel: 8.3-next

---

Release Notes and Documentation

Explain the change to users

• Add the option not to rename the management interface when performing an emergency network reset
• Reset the old management interface IP configuration when switching to a new interface with the same IP address

ANSWER

Attention points

In case the target conditions are met, the second patch will result in the old management interface to reset its IP address ('0.0.0.0')

Documentation update needed

• Yes
• No
• I'm not sure, help me

EXPLANATIONS

The first patch introduces a new dialogue window that the user has the option to a) rename the management interface or b) keep it intact.

---

Testing and regression avoidance

What tests have you performed?

No automated tests cover xsconsole
Manual testing of the console (before build) with network interface modifications.
koj build: https://koji.xcp-ng.org/taskinfo?taskID=107149
koji build: https://koji.xcp-ng.org/taskinfo?taskID=108041

What manual tests should be performed after the build, and by whom?

• Perform a network reset with a) renaming the interface and b) keeping the name intact
• Switch the management interface to a new NIC with the same IP address as the old one (the latest operation works for static assignment, but the previous one could be both static or DHCP)

What's covered by the xcp-ng-tests test suite?

None

What tests have been or will be added to CI for this change? If none, explain why.

There is a task (XCPNG-3476) created for this in order to create the relevant testing

---

Xen Orchestra Impact

Does this affect existing features in Xen Orchestra, or add new features that could be useful?

• Yes
• No

[last-genius]

The patches and the specfile look good to me.

Could you fill in the PR description? In particular - have you tested this build on a host?

Could you add a link to the scratch build as well?

[sgerag]

The patches and the specfile look good to me.

Could you fill in the PR description? In particular - have you tested this build on a host?

Could you add a link to the scratch build as well?

I have updated it. Most probably the information is incomplete or in the wrong place.

Also, koji build here: https://koji.xcp-ng.org/taskinfo?taskID=107149

[stormi]

Marking with changes requested so to avoid accidental approval+merge before the PR description is sorted out. Actually it would be best to leave such PRs in draft status, then get help to complete the description, and then only ask for review.

[sgerag]

Marking with changes requested so to avoid accidental approval+merge before the PR description is sorted out. Actually it would be best to leave such PRs in draft status, then get help to complete the description, and then only ask for review.

Converted it to draft PR.

[sgerag]

After manual testing, I have spotted a bug in the DHCP operation of changing the management interface. I fixed it, and re-tested it. New scratch build: https://koji.xcp-ng.org/taskinfo?taskID=107308

Converting it to "Ready for review". Let me know if there is something I am missing.

[sgerag]

New scratch build: https://koji.xcp-ng.org/taskinfo?taskID=107308

Fixed the link (wrote a wrong one before).

[stormi]

What tests have been or will be added to CI for this change? If none, explain why.
None

This question is here to help us collectively move towards better test coverage. The if none, explain why is important, as "None" should be the exception, when the previous question established that there's no coverage for this yet.

Here, we should at least say that testing XSconsole would be good to do in our integration tests, and create a task for that. There are ways to test TUIs. And, depending on priorities set by @bleader, maybe start implementing such tests to cover the changes done here.

[stormi]

Now LGTM on packaging side. Patches not reviewed by me. Leaving as "changes requested" regarding the PR description about testing.

Side note: as I was still on the PR I saw the pushes and saw that they fixed my comments. The best process (soon to be documented) in this case is asking for re-review and letting the reviewer resolve the threads they started.

[bleader]

xsconsole offers a xml-rpc interface for testing, no need to go through complex TUI expect based testing. I created XCPNG-3476 to attend to this with more details and an example script using that xml-rpc interface.

This answers the need for a card to track it. @sgerag you can add that there is a task created to for test creation.

We wlll discuss the scheduling of that task, but I think we can merge that one with the manuel tests that were done.

[bleader]

Your DCO does not pass on the specfile update commit.

[sgerag]

@sgerag you can add that there is a task created to for test creation.

done, let me know if anything else is needed.

[sgerag]

Your DCO does not pass on the specfile update commit.

done, let me know if the tags 'Co-authored-by:' and 'Signed-off-by:' are ok.

[stormi]

8.3-next for the milestone.

[sgerag]

Koji build to v8.3-incoming: https://koji.xcp-ng.org/taskinfo?taskID=108041