EduFrazao opened a new pull request, #13603:
URL: https://github.com/apache/cloudstack/pull/13603
### Description
This PR solves a situation when the management network interface does not
have a defined IP address.
When this interface is a bridge, the management ip can be placed directly in
the bridge (more common) and sometimes in virtual interfaces linked to it.
On this scenarios, the cloudstack agent iterates over all interfaces and
select the first one with a valid ip address.
This brings unpredictable behavior, like choosing wrong interface address,
and publishing this address to management servers, causing problems with
migrations, guest consoles for example.
<!--- Describe your changes in DETAIL - And how has behaviour functionally
changed. -->
I've added two new ways to search for the correct management address:
- First and more "secure" is to explicitly define the management ip address
on agent.properties. The agent will find the interface bound to this address
and configure it as private interface.
- If configuring this address is not desirable, agent will get the
management server addresses, and try to establish a socket (without tcp
overhead) with it. If it suceeds, will possible to collect the source ip
address used to reach management servers. I belive that this is a more
assertive way to find out the host management address.
If the above methods don't work, the actual behavior is used without
changes.
<!-- In case of bug fix, the expected and actual behaviours, steps to
reproduce. -->
1. Setup a Full L3 network design, with management defined as a traffic
label over a "virtual physical address".
2. Create a bridge and setup a vxlan interface with this bridge as master
interface.
3. Define a veth interface and define the bridge as master for this
interface too.
4. Derfine in this veth interface, the IP address that will be used to reach
the management servers.
5. Theres no guarantee that this will be the IP address reported to the
management server.
Fixes: #13519
<!---
*******************************************************************************
-->
<!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE
DOCUMENTATION. -->
<!--- PLEASE PUT AN 'X' in only **ONE** box -->
<!---
*******************************************************************************
-->
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] Build/CI
- [ ] Test (unit or integration test code)
### Feature/Enhancement Scale or Bug Severity
#### Feature/Enhancement Scale
- [ ] Major
- [X] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [X] Major
- [ ] Minor
- [ ] Trivial
### Screenshots (if appropriate):
### How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
I have two hipervisors in production with this changes. Whitout it, I can't
make my cluster to work well, cause I can't do migrations and open guest
instances terminal
To test it I used both the explicit configuration and route based detection
for several days, marking servers for maintenance, rebooting hypervisors and
management servers.
#### How did you try to break this feature and the system with this change?
Configuring an invalid Ip address as management address. The setting was
ignored as expected, because no interface was found with it. System fallback to
another methods.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
