At first glance it seems that we need is to - shutdown one side - update the vo - restart the one side - shutdown the other side - restart the other side
Somehow this seems to be too simple. the shutdown elements works in a generic way while my use case only applies to the virtual router and not to other providers. In fact the network may have a redundant virtual router and some other providers for which redundant makes no sense or that have their only redundancy mechs, right? On Fri, Oct 24, 2014 at 10:43 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > H, > > I the present code a vr is updates as follows: > > // 1) Shutdown all the elements and cleanup all the rules. > Don't allow to shutdown network in intermediate > // states - Shutdown and Implementing > > // 2) Only after all the elements and rules are shutdown > properly, update the network VO > // get updated network > > // 3) Implement the elements and rules again > > // 4) if network has been upgraded from a non persistent ntwk > offering to a persistent ntwk offering, > // implement the network if its not already > > This means that for a redundant router vm both sides are brought down > before upgrade of the db entries is done. This is not acceptable for > mission critical environments such as our clients at Schuberg Philis > have. I am to concoct a way around this and will have my sweet time at > it. I am also willing to share this time with anyone that has thoughts > and particularly concerns on the issue. > > To get to this point I extracted as much as I could from the > updateNetwork method in NetworkServiceImpl. The results are in > hotfix/CLOUDSTACK-7776. I plan to merge this before working on the > actual fix but after I am convinced that I re-factored it enough and > as much as possible. Please have a look if you dare to/enjoy it. > > -- > Daan -- Daan
