Re: regarding CLOUDSTACK-9598
It is great that you already fixed the problem. Would you mind opening a Jira ticket for this? Maybe there are other in the same situation as you. On Thu, Jan 12, 2017 at 5:20 AM, Stephan Seitz < s.se...@secretresearchfacility.com> wrote: > Rafael, > > we've noticed the change after upgrading 4.9.0.1 to 4.9.1. The particular > ACS was originally setup as 4.5 and upgraded to 4.6, 4.7, 4.8, 4.9, 4.9.0.1 > and finally 4.9.1. > > Obviously, we relied on a long existing bug ;) as the new behaviour does > make > sense. But most of our vm's are intentionally equipped with multiple > routing tables and require the default-gateway announced from every > attached > network. > > By now, we've patched the CsDhcp.py inside systemvm.iso/cloud-scripts.tgz > as > we didn't find any configuration option. > > cheers, > > - Stephan > > Am Mittwoch, den 11.01.2017, 15:59 -0500 schrieb Rafael Weingärtner: > > Could you provide a little bit of more details of what happened? > > Was this during an upgrade? After an upgrade? what version of ACS? > > > > On Mon, Jan 9, 2017 at 8:41 AM, Stephan Seitz < > > s.se...@secretresearchfacility.com> wrote: > > > > > > > > Hi dev's! > > > > > > The bug fixed in CLOUDSTACK-9598 (VR offering a default route only on > > > "default" networks) did some harm to our deployed hosts. > > > Most of our hosts rely on the behaviour of getting a default route from > > > every network they're attached to. > > > > > > Is there some quick fix or configuration setting, to get the old > behaviour > > > back? > > > > > > Thank's in advance! > > > > > > - Stephan > > > > > > > > -- Rafael Weingärtner
Re: regarding CLOUDSTACK-9598
Rafael, we've noticed the change after upgrading 4.9.0.1 to 4.9.1. The particular ACS was originally setup as 4.5 and upgraded to 4.6, 4.7, 4.8, 4.9, 4.9.0.1 and finally 4.9.1. Obviously, we relied on a long existing bug ;) as the new behaviour does make sense. But most of our vm's are intentionally equipped with multiple routing tables and require the default-gateway announced from every attached network. By now, we've patched the CsDhcp.py inside systemvm.iso/cloud-scripts.tgz as we didn't find any configuration option. cheers, - Stephan Am Mittwoch, den 11.01.2017, 15:59 -0500 schrieb Rafael Weingärtner: > Could you provide a little bit of more details of what happened? > Was this during an upgrade? After an upgrade? what version of ACS? > > On Mon, Jan 9, 2017 at 8:41 AM, Stephan Seitz < > s.se...@secretresearchfacility.com> wrote: > > > > > Hi dev's! > > > > The bug fixed in CLOUDSTACK-9598 (VR offering a default route only on > > "default" networks) did some harm to our deployed hosts. > > Most of our hosts rely on the behaviour of getting a default route from > > every network they're attached to. > > > > Is there some quick fix or configuration setting, to get the old behaviour > > back? > > > > Thank's in advance! > > > > - Stephan > > > >
Re: regarding CLOUDSTACK-9598
Could you provide a little bit of more details of what happened? Was this during an upgrade? After an upgrade? what version of ACS? On Mon, Jan 9, 2017 at 8:41 AM, Stephan Seitz < s.se...@secretresearchfacility.com> wrote: > Hi dev's! > > The bug fixed in CLOUDSTACK-9598 (VR offering a default route only on > "default" networks) did some harm to our deployed hosts. > Most of our hosts rely on the behaviour of getting a default route from > every network they're attached to. > > Is there some quick fix or configuration setting, to get the old behaviour > back? > > Thank's in advance! > > - Stephan > -- Rafael Weingärtner
regarding CLOUDSTACK-9598
Hi dev's! The bug fixed in CLOUDSTACK-9598 (VR offering a default route only on "default" networks) did some harm to our deployed hosts. Most of our hosts rely on the behaviour of getting a default route from every network they're attached to. Is there some quick fix or configuration setting, to get the old behaviour back? Thank's in advance! - Stephan