Can we get a confirmation on the approach we want to take? 1. We are going to fix the router for the case - " if the router has upgraded its scripts, and then adjust how we call edithosts.sh" ? 2. Going to suggest a reboot (start and stop) of all the system Vms (SSVM,CPVM and routers) as part of Upgrade procedure?
-Thanks Sangeetha -----Original Message----- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Wednesday, March 27, 2013 10:02 PM To: dev@cloudstack.apache.org Cc: Sangeetha Hariharan Subject: Re: [ACS41][QA] Has anyone upgraded from 4.0 to 4.1 Ok, found the issue. The 4.0 script in the system vm that adds DHCP entries parses args like this: # edithosts.sh -- edit the dhcphosts file on the routing domain # $mac : the mac address # $ip : the associated ip address # $host : the hostname # $4 : default router # $5 : nameserver on default nic # $6 : comma separated static routes mac=$1 ip=$2 host=$3 dflt=$4 dns=$5 routes=$6 And the script in 4.1 parses args like this: while getopts 'm:4:h:d:n:s:6:u:N' OPTION do case $OPTION in m) mac="$OPTARG" ;; 4) ipv4="$OPTARG" ;; 6) ipv6="$OPTARG" ;; u) duid="$OPTARG" ;; h) host="$OPTARG" ;; d) dflt="$OPTARG" ;; n) dns="$OPTARG" ;; s) routes="$OPTARG" ;; N) nondefault=1 ;; ?) usage exit 2 ;; esac done So in 4.0 it's looking at flags as though they're arguments, which is why we get garbage in the dhcp file. In the router log we see the results (first line is a working one, second line isn't) Mar 28 04:41:54 r-5-VM cloud: edithosts: update 02:00:2b:58:00:01 10.1.1.6 ff9b5970-d095-4602-aa7d-671e3a7535da to hosts Mar 28 04:48:01 r-5-VM cloud: edithosts: update -4 10.1.1.245 -m to hosts I don't see an easy way around this. We could perhaps detect if the router has upgraded its scripts, and then adjust how we call edithosts.sh accordingly. Anyone want to take that on? Is this the only issue? I'm assuming people will need to reboot their system vms anyway for other features. On Wed, Mar 27, 2013 at 9:27 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > We can look into it, my guess is that an existing script now has new > and/or different parameters. Perhaps it could be adjusted to be > backward compatible so people can reboot at their leisure. All just guesswork. > > On Mar 27, 2013 9:21 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >> >> Hard to say. Sometimes functionality/implementation changes even >> though the feature is the same. >> >> On Mar 27, 2013 9:20 PM, "David Nalley" <da...@gnsa.us> wrote: >>> >>> On Wed, Mar 27, 2013 at 11:13 PM, Marcus Sorensen >>> <shadow...@gmail.com> >>> wrote: >>> > Just to clarify a step further, this should have been the case >>> > with 3.x to >>> > 4.0 as well. We had all of these new vpc scripts that added brand >>> > new functionality that needed to go on the virtual routers. The >>> > system VM template stayed the same, even though new scripts were >>> > added via systemvm.iso. >>> >>> >>> That said, why would new functionality make existing functionality >>> stop working in a system VM. >>> >>> --David
