After upgrading from Cloudstack 4.5.2 to Cloudstack 4.8.0 the following differences have been observed:
- That the networks table has been simplified (there are fewer fields.)
- That there is a new Boolean field in the networks table called "redundant"
- That this field, rather than the network offering, is used by the Network Implementer to determine whether to implement standalone or redundant virtual routers.
The following critical observations has also been made:
- That for an as-of-yet unknown reason, the value of the "redundant" field may be False despite the network having a redundant network offering.
- That many (roughly 50%) of the isolated networks on our Cloudstack 4.8.0 deployment are in this state.
We do not know why the "redundant" field is 0 for some redundant networks and 1 for others. We do not know when this value was assigned to the field. For all of our redundant networks, we do know the following:
- That we have restarted these networks at least twice since upgrading to Cloudstack 4.8.0 and that redundant virtual routers have been implemented.
- That after the "redundant" field is set to 0 any restart of a network results in a single, standalone virtual router.
- That subsequently setting the "redundant" field to 1 and restarting the network results in a pair of redundant virtual routers.
We only noticed this when we arrived unexpectedly at point 2. Later investigation found the "redundant" field and experimentation with that allowed us to resolve the issue for our guests by applying point 3.
What should (probably) happen is either:
- The network implementer should use the network offering to determine how many and what type of router to implement.
- The "redundant" field should always match the network offering and we should discover why this value in some cases does not match the network offering.